Re: How to identify incorrect subroutine calls in a perl program

Don't do things like that. You're bypassing the features built-in with strict. Instead of using test::Log(), have test export the Log() function. Then, strict will complain about a bareword, indicating the subroutine isn't defined.

My criteria for good software:

Does it work?
Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Comment on Re: How to identify incorrect subroutine calls in a perl program

Replies are listed 'Best First'.
Re^2: How to identify incorrect subroutine calls in a perl program by ikegami (Patriarch) on May 15, 2006 at 18:19 UTC
`>perl -c -we "use strict; Log('There is an issue')" -e syntax OK` [download] What complaint about a bareword?	[reply] [d/l]
Re^3: How to identify incorrect subroutine calls in a perl program by LanX (Saint) on Dec 16, 2024 at 17:54 UTC
Calls without parens need to go to pre declared subs, hence a compile time error. `perl -c -we" use strict; Log 'There is an issue'" String found where operator expected at -e line 1, near "Log 'There is + an issue'" (Do you need to predeclare Log?)` [download] Cheers Rolf _{(addicted to the Perl Programming Language :) see Wikisyntax for the Monastery}	[reply] [d/l]
Re^4: How to identify incorrect subroutine calls in a perl program by ikegami (Patriarch) on Dec 16, 2024 at 20:12 UTC
I fail to see how that's relevant. dragonchild said that importing would result in a compile-time error. That would only detect a typo in the previously-non-existent import. It wouldn't identify incorrect calls at compile-time. dragonchild didn't suggest omitting the parens. dragonchild even used parens in their post, just like the OP. Hence no compile-time errors would have resulted from their suggestion. Finally, omitting parens wouldn't even have worked well at the time of the post. For best results, `use v5.28;`/`no feature qw( indirect );`/`no indirect;` is required, but the post predates these.	[reply] [d/l] [select]