Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things

poor quality perl code

by pwagyi (Monk)
on Mar 22, 2018 at 06:01 UTC ( [id://1211484] : perlquestion . print w/replies, xml ) Need Help??

pwagyi has asked for the wisdom of the Perl Monks concerning the following question:

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 ( 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?

Replies are listed 'Best First'.
Re: poor quality perl code
by Corion (Patriarch) on Mar 22, 2018 at 08:56 UTC

    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.

      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.
Re: poor quality perl code
by Laurent_R (Canon) on Mar 22, 2018 at 11:26 UTC
    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.

Re: poor quality perl code
by dsheroh (Monsignor) on Mar 22, 2018 at 08:45 UTC
    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.

      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!

Re: poor quality perl code
by Anonymous Monk on Mar 22, 2018 at 07:56 UTC
    Know your audience?
A reply falls below the community's threshold of quality. You may see it by logging in.