First of all methods don't have signatures in plain Perl 5, so there's no way a code checker could actually know arguments a sub expects. It could guess, though.

Second, variables don't have type annotations, so you'd have to introduce these first.

Thirdly, methods can be added at run time. In the simplest case it's something like *methodname = sub { ... }, in the most general (and thus hardest) case something like that would happen in a string eval, completely undetectable at compile time.

All of those can be ignored to some extend, and you can still try to write some static checker, which would be more heuristically than correct.

So you want a Perl with explicit signatures, type annotations and no eval. Luckily there's something that provides the first two of these criteria - Perl 6. It can't do complete, reliable checking at compile time, but at least it allows for much better introspection, and much better compile time detection if you ignore that an eval() might add methods.

In general no. Perl is a little bit too dynamic for that: many modules create methods at runtime (usually using AUTOLOAD, but there are other ways...), and all methods and functions in Perl take exactly one argument: A list, which will be put in the @_ array. (Even prototyped functions take a list. They just define what's in the list.)

So the problem is that none of the above is known until runtime, when a specific method call is made. It may be possible to answer those questions for a fair number of simple cases, but default arguments and AUTOLOADed methods are both fairly common practice.

Even prototyped functions take a list. They just define what's in the list.

While that may be technically true (Perl uses a stack), I'm not sure that's helpful. Prototyped functions parse differently from regular Perl functions, so the apparent behavior of these functions may not make it apparent that they take lists of arguments.

Agreed. I just wanted to indicate I was aware of prototypes. (I didn't feel a more in-depth discussion on them was needed to answer the question given.)

But yeah, prototypes cause the function to apply different contexts to their arguments (except when they don't) and so they can appear to take something other than a list. Unless you ignore the prototype. Or work around it some way. Or...

End result, for this discussion: Prototypes in Perl don't actually help all that much with static code analysis. They can help a bit, but not enough to make code analysis really useful.

Using Params::Validate, you can check a sub's parameters at run time. After that, a test suite with good code coverage should ensure pretty well that you didn't fat finger a method name.