Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

•Re: Perl Programming guidlines/rules

by merlyn (Sage)
on Nov 21, 2002 at 11:48 UTC ( #214745=note: print w/ replies, xml ) Need Help??


in reply to Perl Programming guidelines/rules

I've been researching this problem in upgrading our code review course and code review services recently.

The biggest problem with your list is that you have very little that can be objectively tested. A checklist item is useful if everyone could agree that you are following it, but otherwise it simply becomes a way to butt heads in a code review session.

On one of our slides, I bring up the example "you should generally 'use strict'" as a sample bad rule. It's bad because it can't be tested. Is this one of the times that you avoid use strict, or not?

I also have problems with some of your specific rules. For example, "Do not use $_". That's ludicrous. How will you do a grep or map? Or are you proposing coding everything in babybaby Perl?

A reasonable standard for presumption of the skill level of your maintenance programmer is:

  • Has read Learning Perl
  • Has read all the applicable tutorial series in the core docs
  • Knows how to type "perldoc Module::Name"
Anything beyond that should be documented if used, giving a literature reference if needed. Yes, this even goes for the Schwartzian Transform, since that's not in a tutorial doc or Learning Perl, only a FAQ item.

But the biggest point I hope you're seeing is that you should write native Perl when you are writing Perl. Don't constrain Perl to just the parts that are C-like or Shell-like. You miss the point of programming in Perl.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.


Comment on •Re: Perl Programming guidlines/rules
Re: •Re: Perl Programming guidlines/rules
by hakkr (Chaplain) on Nov 21, 2002 at 17:21 UTC
    :) I thought the $_ thing would be a bit controversial.

    Sometimes it makes code harder to read so I say never use it unless it's a perlish function like map where it is obvious what it refers to.

      I agree. I only use $_ in places like map where it is required.
      That's stupid. Sometimes regexes make code harder to read. Same comments, OO, subroutines or arrays make code harder to read. But only PHBs use such arguments to outlaw them via a coding standard.

      Abigail

        yes but you can improve those things there is not much you can do to improve the readability of $_.

        For non perl programmers it can be new concept so also increases learning curve of maintaining the code

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://214745]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (11)
As of 2014-12-22 19:33 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (126 votes), past polls