in reply to perl check style

Easy solution: tell your programmers to run their perl-scripts through PerlTidy before they check-in their code. It will thus become automatically "reformatted" as per the style rules.

As the programmers will next time start working on their newly checked-out scripts (which are now in the canonical style format) after a while adhering to the style rules will become second-nature.

Don't go the way of checking whether your programmers adhere to the style rules (and be some sort of a style-police) and chewing them out if they don't follow the rules.

What is more important? Happy programmers who write working code in whatever way they can and transform it then easily into stylish perl or unhappy programmers who dread the moment their work is scrutinized by some "Big Brother"?

CountZero

"If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

Replies are listed 'Best First'.
Re^2: perl check style
by InfiniteLoop (Hermit) on Sep 16, 2004 at 04:16 UTC
    You are right, although I did'nt mean to be some 'Big Brother'. There are more than one way to look at the problem.
    Im tired of telling people to indent their code. I guess perltidy does that, neatly too.
    Since Im lazy, I will stick to perltidy for the time being ;).

      With a little engenuity, you can keep everybody happy.

      Perltidy is configurable. If some of your programmers prefer to code in a style that does not match the "house style", they can set up a configuration that matches their preferred style. If their editor is sufficiently flexible, they can arrange to have whatever file they load converted to their style on loading, and back to the house style when they save it.

      That way, everyone has the potential to work in whatever style they find most productive or readable. From experience, there is nothing worse that trying to code to someone elses style--especially if you find the rules governing that style to be stupid or ill-conceived as I do with several of the common "style guides" available for C for example.

      One place I worked they required that C code be coded as:

      return type func ( par1type par1, par2type par2, ) { // line of code if (condition) { // line of code } else { while (((condition1 && condition2) || condition3)) { // do something; } } return (something); }

      Note: All the parenthesis were mandatory regardless of whether they were required for precedence.

      The idea they claimed was:

      1. readability through whitespace usage
      2. a complete lack of ambiguity
      3. productivity through consistancy.

      Poppycock I say. I'm a great believer in consistancy, and the use of whitespace, but every line I type to these coding standards erked. Greatly. I would find myself coding my own way, the having to go back over the code to change it to the coding standards.

      But then I would have (or be requested) to make another change, so I had the choice. Load up the house copy, re-format it so as I could understand it, modify it, and convert it back. Or risk starting with my local copy and hope that noone else had modified it in the interim. Of course, either is unacceptable.

      Using cbeaut file.c @mystyle on GET and cbeaut file.c @housestyle on PUT kept everyone happy.

      The only reservation I have with this is I have found that it is possible for PerlTidy to get confused; but it is a rare thing I think. The couple of times it happened, I think I was trying to deobfusicate one of the obfu's posted here.

      perl -MO=Deparse obfu.pl is much more reliable for those.


      Examine what is said, not who speaks.
      "Efficiency is intelligent laziness." -David Dunham
      "Think for yourself!" - Abigail
      "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon