in reply to PBP: Code Layout

I can't say anything about that book or about "good style". I just can say: I don't want to be forced by whatever policy to use a certain code style. To me it's nonsense. Simply a waste of time concentrating on formatting the code instead of developing it. It's something that should be done by a program not by a programmer.

When I learned Pascal at university back in 1984 or so, we had to follow a certain style. Do you think anyone followed the rule of UPPERCASING all keywords?

NO ONE! Everyone wrote his one "keyword-uppercaser". Everyone immediately noticed, that focussing on formating is a waste of time.

s$$([},&%#}/&/]+}%&{})*;#$&&s&&$^X.($'^"%]=\&(|?*{%
+.+=%;.#_}\&"^"-+%*).}%:##%}={~=~:.")&e&&s""`$''`"e

Replies are listed 'Best First'.
Re^2: PBP: Code Layout
by saberworks (Curate) on Oct 19, 2005 at 22:14 UTC
    I have actually recommended that we make a nice perltidy config and apply it to all files when they are checked into CVS. The problem here is that there is now a disconnect between what you just wrote yesterday and what you are editing today. I think coding standards are important in the context of a development team because people tend to get more done when they don't have to spend extra time deciphering yet another individual coding style. For example, we've got numerous styles running rampant: 
    if($this) {
    do_that(); # Pretend this is indented with a tab
}

if ( $this ) {
    do_that(); # another tab
}

if($this)
{
do_that();
}

if($this)
{
    do_that();
}

if($this)
    {
    do_that();
    }

if($this)
    {
        do_that();
    }

    [download]
    And that's only the if statements! And some people use 4 spaces and some use 2. Of course, they become harder to read with more complex statements: 
    if($this)
    {
    do_that();
    eval {
        do_something();
    };

    if($something_else)
        {
        here_we_go();
        }
    }

    [download]
[reply]
[d/l]
[select]

      The problem here is that there is now a disconnect between what you just wrote yesterday and what you are editing today

      Personally I wouldn't care! If the formatting is there so that everyone understands the code more easily, then fine! I should understand my code also. If not, I programmed something so obfuscated, I should rethink it ;-) and that's a positive side effect of the tidy process, don't you agree?

      I'd still (even if I get downvoted more) prefer my own "style" over any company dictated one because I don't want to focus un bureaucraccy ;-) (I'm exaggerating). Let the perltidy do it's work and I will be happy.

      s$$([},&%#}/&/]+}%&{})*;#$&&s&&$^X.($'^"%]=\&(|?*{%
      +.+=%;.#_}\&"^"-+%*).}%:##%}={~=~:.")&e&&s""`$''`"e
[reply]
[d/l]
[select]
        I'd still (even if I get downvoted more) prefer my own "style" over any company dictated one because I don't want to focus un bureaucraccy

        I didn't downvote you, but I find it pretty shocking that you would rather go your own way than follow team guidelines. No matter how well he or she codes, I wouldn't want someone with that kind of attitude on my team.

[reply]
      Howdy!

      That's a risky suggestion. Far safer is to insist the people run that standard perltidy pass, and then make sure their code still passes its tests.

      It is possible that perltidy could break code when it reformats it, so ensuring that it still passes all its tests (or at least all the tests it passed before) is important, and having it happen automagically on check-in runs the risk of overlooking that effect while it is easy to undo.

      yours,
      Michael
[reply]

In Section Seekers of Perl Wisdom