Rubberduck: Late bound WorksheetFunction call.

[SystemsModelling]

eg Application.Sum(array)

Calling Worksheetfunction directly can raise the runtime error, It's a bit more subtle than that -
You need to catch the result in a Variant and test that for an error value, to be like Excel.
Otherwise if you try to catch in say a Double you could get a type mismatch error which is a runtime error but not perhaps the one you wanted.
What's odd is a I got 10 occurrences of this on the one use of Application.Sum.
and 5 for Application.Transpose

Application.Trim( has different behaviour from VBA Trim$ so its use is intentional.
and I got 4 warnings for that.

[ThunderFrame]

To be like Excel 95?

In the case of Excel, the extended members of Application, are all kludges for Excel 95 compatibility. The only behavioral difference between using Application.Pi and Application.WorksheetFunctions.Pi is the way that errors are handled. Maybe the inspection Meta should warn about these differences?

Have you got specific example of functions that don't benefit from using the WorksheetFunction member?

[SystemsModelling]

"The only behavioral difference between using Application.Pi and Application.WorksheetFunctions.Pi is the way that errors are handled. "
To me, that's a design choice. I may use both ways. As I recall, I use Application.XXX when I expect an error and test the variant returned rather than throwing a RTE. Otherwise, I'd encapsulate it in a one-line function with On Error Resume Next, which I do for say Range.Find

[comintern]

The rationale for the inspection isn't really to _enforce_ a specific design decision, and is probably more useful for the user that isn't familiar with the distinction. Suggesting the use of VBA error handling rather than Excel error handling is the probably the right direction - the coding error it warns about are things like this:

Public Sub Foo()
    Dim result As Variant
    result = Application.Sum(Me.Range("A1:A2"))
    Debug.Print 100 / result
End Sub

If the Application.Sum returns an error, the line Debug.Print 100 / result is a type mismatch because you can't divide by "Error". The example above is trivial, but in more complicated or involved code it introduces a situation that can be incredibly difficult to debug if the root cause of the error isn't anywhere near the call site that produced it.

For the coder that knows what they are doing and understands the _implication_ of that, the inspection can be ignored or turned off.

[Vogel612]

IMO the inspection meta sufficiently explains this... closing for now. Specific wording improvements of the meta are welcome 👍