poor quality perl code

[pwagyi]

In my team, there are a few programmers who do not follow any coding style guide. I am talking about using ALL CAPS variable/subroutine names(including local variables), overuse of global variables, manually re-inventing stuff (like parsing command line argument,), no design, no concern for DRY (a lot of repetition of code), stringly typed (http://wiki.c2.com/?StringlyTyped) way of doing things.

I've been observing this for some time. I am afraid that it will only get worse. It also got me thinking such kind of code are what gives perl bad reputation as read only language. What should I do? should I just tell them quietly?

[Corion]

What you have seems to me to be mostly a management problem. If the management can't set up and enforce code guidelines, all your efforts will be in vain.

If you think that there are modules that should be used, make the case that they should be used within the programming guidelines.

Your perceived lack of concern for DRY might well be you overarchitecting things and trying to eliminate perceived repetition where the similiarity is just in the code but not in the business that originated the code to be written.

Such code can be used to give any language a bad reputation, but the problem is not the language but the programmers, and the management that lets those programmers be. My recommendation is to either find an angle with management to improve the programmers, or to adjust your stance on things so you can live with the situation or to leave.

[pwagyi]

It is exactly management problem. I have learnt from senior guy who left that our team used to be mainly system admin guys and then somehow evolved into development department. And whenever there's issue caused by our programs, management just fix the problems at the surface.

[Laurent_R]

I agree with the previous comments that it is a matter of management and human relations at least as much as a technical problem. However, I would suggest that, for some at least of the technical problems you report, you might get some help from the Perl::Critic module, at least if you succeed in convincing your team to use it.

You might also want to buy and make available to your team Damian Conway's Perl Best Practices book. Really an excellent book. I might not necessarily agree with every single one of Damian's recommendations, but, by far, most are very useful and the rationale for them is very well explained.

[dsheroh]

What exactly do you mean to be the Perl equivalent of "stringly typed" coding? Passing comma-delimited strings instead of arrays? Because "passing a string where you should use a float instead" doesn't really apply to a language where "a scalar is a scalar is a scalar", regardless of whether that scalar is a string or a number or even both at the same time.

As for the actual question, my approach to similar situations is to try to show better ways of doing it (TIMTOWTDI, but not all ways are equally good!) and explain why they're better. That doesn't really work with typographical conventions for names, though, so I think you'll just have to go for the "this is the standard convention" angle and hope for the best.

[pwagyi]

It's the former case, passing '|' delimited string instead of returning hash. (eg. apple|red|3.0 instead of ( fruit => 'apple', color => 'red', weight => 3.0) Using datetime as string in the whole code. Oh and I have witnessed a subroutine with 22 (positional) arguments!

[Anonymous Monk]

Know your audience?