Re: Compile-time checking for undef subroutines?

This kind of question indicates a serious lack of coding quality at the site. The best way to deal with this is to inspect your code. If your code is large, make it smaller. If it's messy, make it clean. If it's ... you get the idea. Who knows, maybe you'll find the solution to those other 47 bugs that have been annoying you, too.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

Comment on Re: Compile-time checking for undef subroutines?

Replies are listed 'Best First'.
Re: Re: Compile-time checking for undef subroutines? by paulbort (Hermit) on May 06, 2003 at 17:03 UTC
There's More Than One Way To Do It.The problem might be in the local development culture, which is not so easily changed. For example, at our office, coding standards enforcement was so lax it had to be automated with a Perl script that reads the code and e-mails the programmer if any of our rules are broken. This may be an environment where they can't enforce a particular style. The alternative might be to disallow use of some language features, in this case, dynamically created subs. If all the programmers can agree not to do that, a script could be written (probably using Parse::RecDescent and the Perl BNF) to accumulate declared subs and used subs, and list anything used but not declared. In this case, it might be easier to give the programmer a tool to solve the problem than to change development style. -- Spring: Forces, Coiled Again!	[reply]
Re3: Compile-time checking for undef subroutines? by dragonchild (Archbishop) on May 06, 2003 at 17:26 UTC
If all the programmers can agree not to do that, ... However, that seems to be the problem, doesn't it? I mean, the programmers are (seemingly) refusing to agree on much of anything! For example, at our office, coding standards enforcement was so lax it had to be automated with a Perl script that reads the code and e-mails the programmer if any of our rules are broken. Far be it from me to pontificate, but unless the development culture is updated, the root cause will persist and this exercise will have to be done again, and again, and again, and ... ad nauseum. Additionally, the developers will become lazy and depend on automated tools to do their development for them. Now, tools aren't a bad thing, but they are less than ... optimal ... when they substitute for developer care. Now, I wouldn't care at all if those developers would only ever work in shops I won't be working in. But, that isn't a guarantee, is it? I most definitely do NOT want to work with a developer who is so full of themselves that they will obstinately do their thing, even if it means that their coworker's efforts are stomped upon. I find developers like that to be worse than no developer at all. Furthermore, lax standards enforcement indicate that there's lax ... other enforcement, too. For example, if you hvae lax standards enforcement, you probably have lax requirements analysis, lax design walkthroughs, and lax testing efforts. Sounds like you have a lax product, too! ------ We are the carpenters and bricklayers of the Information Age. Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement. Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.	[reply]