Curious to know if there was a consensus/resolution for ByRef/ByVal default for object thread. We have some code that always inserts ByRef (regardless of type) when generating an argument list.
I thought I was seeing 'ByVal' was best for objects.
> The `IIf` function is easily a beginner trap that can cause unexpected side-effects given non-constant arguments, since the expressions need to be evaluated before their result is passed to the function. The commonly accepted "IIF evaluates both arguments" explanation is simplistic and puts the blame on `IIf`, when `IIf` is in fact not guilty of anything - it's just simple basic language mechanics at play here.
Let's make an inspection that flags arguments that involve any kind of member ca
This isn't about performance. With is actually pure laziness here. When any expression is duplicated in code, the solution is to extract it into a local variable - the fact that it's an object in this case makes With legal, but you'd get the exact same "benefits" with Set target = ActiveSheet.Range("A1") and then working off target. The With block only serves to hide a local object reference - in any case, either way is better than dereferencing the very same object for every statement you need to run against it. — Mathieu Guindon48 secs ago
I tested with this routine:
Sub UseWith()
Dim oCell As Range
Dim sName As String
Dim lColorIndex As Long
Dim bItalic As Boolean
Dim sSize As Single
Dim bStrikethrough As Boolean
TimerStart "1"
For Each oCell In Sheet2.UsedRange
sName = oCell.Font.Name
lColorIndex = oCell.Font.ColorIndex...
While the results bear out the obvious conclusion that option 1 makes less calls to the Range indexer, you can't get any reasonable benchmark with only one iteration, especially when you are re-using variables between the 2 sections of code under test. — Comintern6 secs ago
The conclusion is anecdotal. Multiple runs arrive to different conclusions, and inverting the two tests produces different results. — Mathieu Guindon9 secs ago
Regardless of the speed difference, the statement "the same code construct with different emphasis inside can be optimized once in one way and second time in the other" is incorrect in this specific case. Calling a method repeatedly (which is what Range("A1") is doing) when it deterministically can't change is always an optimization, regardless of how you achieve that goal. — Comintern11 secs ago
^ That answer still rubs me the wrong way. And yes, that is my down-vote.
The attitude that VBA is merely a scripting toy is incredibly demeaning to the programmers that use it. The fact that you're solving a problem in Excel using a programming language that is integrated into the environment doesn't imply that you shouldn't care about a 2% performance gain. It certainly doesn't mean that you should take license to do something stupid like repeatedly call a function that returns the same thing. If less VBA developers behaved like script-kiddies and more behaved like programmers, there wouldn't be such a proliferation of crap VBA code on the web... — Comintern6 secs ago
scare quotes used because im glossing over things. But if you understand why header files exist you understand how automation solves that particular problem
You don't need header files in C# because the C# compiler does two passes. The first one essentially generates the header files, and the second one does the main compilation.
true but even so, if you need to interoperate with components not yours and not written in same language, you still need a way to expose the custom types for code use.
and it's not like the code isn't broken... there's just enough duct tape on enough different places and enough happy-pathing in meatbag testing that it appears to work
> Related to the now closed #4349 but in RD build .4244, I'm getting a false positive `'item' conflicts with an existing name.` warning.
Starting with this code:
```VBA Private Sub PrintDataRow(ByRef Report As Worksheet, ByVal clinicList As ProcessClinic, ByVal theClinic As String, ByVal reportSettings As SatAndLoyaltySettings)
@Vogel612 I did that when I first started. Not a good feeling realizing the 4+ hours you spent tidying up code was dead code that shouldn't have been there in the first place.
> Semi-related, should there be a refactoring for inlining With statements? Or an(other?) inspection to flag With blocks that work off an existing local variable?
> The main problem that I would see with inlining `With` statements is that the expression that captures the `With` variable might have side effects. For example:
``` With ThisWorkbook.Worksheets.Add .Name = "NewSheet" ' ... End With ``` In that case, the refactoring would need to introduce a local variable. The problem with that, is that `End With` can *also* have side effects.
With DefaultInstance .Foo = 42 .Bar = "bar" End With
> The first case is trivially solved though; the With expression is just brought to RHS of the new variable's assignment (assuming we can correctly get the Set keyword requirement for it... which is a whole other issue). As for default instances... snap.
> Just bring back Visual Basic 6.0. Save Microsoft by putting this programming language by default on Windows. You really do not have good programmers anymore?
I tested with this routine:
Sub UseWith()
Dim oCell As Range
Dim sName As String
Dim lColorIndex As Long
Dim bItalic As Boolean
Dim sSize As Single
Dim bStrikethrough As Boolean
TimerStart "1"
For Each oCell In Sheet2.UsedRange
sName = oCell.Font.Name
lColorIndex = oCell.Font.ColorIndex...
VBA Rubberducking
VBA Rubberducking