Inspection for repeated/multiple usage of pure functions with identical arguments

[ThunderFrame]

Repeated calls to a pure function like RGB, with identical inputs, could be better assigned to a variable, and then re-used.

Identifying pure functions in type libraries might require some TLB-specific rules.

In special cases, the result could be assigned to a constant, and the function call removed altogether

Eg:

ActiveCell.Interior.Color = RGB(255,0,0)
ActiveCell.Offset(2,2).Interior.Color = RGB(255,0,0)

Could become:

Const COLOR_WARNING As Long = 255
ActiveCell.Interior.Color = COLOR_WARNING
ActiveCell.Offset(2,2).Interior.Color = COLOR_WARNING

Or :

Dim WarningColor As Long
WarningColor =RGB(255, 0, 0)
ActiveCell.Interior.Color = WarningColor
ActiveCell.Offset(2,2).Interior.Color = WarningColor

[retailcoder]

How do we identify a pure function that isn't user code?

[Vogel612]

how do we Identify a pure function that is user code? Basically the only way to know that a function is pure is to check in the source code, whether it calls an impure function. All I/O is impure by definition. That's about it. There's some things like collection updating that are also impure depending on how they are implemented

[comintern]

This would be difficult for user code. It would require knowing that the function is both purely deterministic and has no side-effects.

[ThunderFrame]

Identifying a pure function that isn't user code would require hard-coding in Rubberduck.

Many of the VBA functions are pure, and we already special case many VBA functions.

[retailcoder]

@comintern wouldn't that simply be a function that doesn't access state outside of its scope?

[comintern]

@retailcoder - The best example would be a random number generator:

Public Function Foo() As Double
    Foo = Rnd()  'Your favorite PRNG here.
End Function 

Others would be functions that retain their own state...

Public Function Foo() As Long
    Static bar As Long
    bar = bar + 1
    Foo = bar
End Function

...anything ByRef...

Public Function Foo(ByRef bar As Long) As Long
    bar = bar + 1
    Foo = bar
End Function

...and anything that touches anything like it in it's execution graph.

[Vogel612]

actually we don't need a full execution graph for it. It should be sufficient to successively mark IdentifierReferences as "impure". Start with Variable Class Members, then add ByRef and Static References in their own context. Additionally there's things like MsgBox, FSO usage and all the like and then just propagate backwards through the call graph we already have (called-by that is)

[retailcoder]

ref. #236