Re: Coding superstitions

[mstone]

That's not superstition. It's called 'defensive programming', and it's the kind of habit programmers tend to aquire after a few trips down the razor blade of life. You're adding information the compiler doesn't need, but so what? Programming languages aren't for computers anyway.. they're for humans.

If you want to talk about something we could eliminate, let's talk about whitespace. The compiler ignores it, except in very special cases like searching for the closing delimiter of a here document. Yet programmers wage holy wars about whether to indent braces like so:

    if (&condition) {
        &yes;
    } else {
        &no;
    }

or like so:

    if (&condition) 
    {
        &yes;
    }
    else 
    {
        &no;
    }

when all the compiler sees is:

    if(&condition){&yes;}else{&no;}

And technically, those semicolons aren't necessary either (nor are the braces, now that I think about it). I always use them, though, because experience has shown that I may want to put another statement into one of those blocks, and it's easier to terminate the expression now than to go back and do it later. I always use a trailing comma in list definitions:

    @list = (
        'item one',
        'item two',
        'item three',   ## <- unnecessary punctuation
    );

for exactly the same reason.

High-level code is for humans. If it wasn't, we'd still be using machine code. Redundant information, which the compiler ignores, can still convey information to humans. Conventions like 'always quote string literals' and 'use meaningful variable names' make code more useful for humans, even if they don't do anything for the compiler.

Instead of worrying about whether such things are necessary, ask yourself how much they cost. So the compiler optimizes out a few tokens while it's building the syntax tree. Big deal. It's not worth retraining a habit just to save that dozen clock cycles or so. And if you personally find the code slightly more stable or readable, the payoff is worth the cost.

[VSarkiss]

...those semicolons aren't necessary either (nor are the braces, now that I think about it).

You're correct about the semicolons, but the braces are necessary. The if-else construct in Perl controls BLOCKs, not statements. Take a look at perldoc:perlsyn. This avoids the dangling-else ambiguity.

Don't confuse this with the if modifier, which comes at the end of statements, not BLOCKs.

I'll let good brother tilly take you to task for (probably inadvertently) passing your current @_ when calling yes and no. ;-)

[mstone]

-- edit: adding an interjection: D'oh!

Well spotted..

That's another reason to code defensively. Idioms don't necessarily port between languages, and even silence can mean something in the right place.

FWIW, passing the current @_ is at least syntactically valid, and like so much of Perl, can be used for good or evil at one's own discretion.

[tilly]

There is no need. Brother VSarkiss already did it for me. :-)

[mrbbking]

where mstone does this...

    @list = (
        'item one',
        'item two',
        'item three',   ## <- unnecessary punctuation
    );

mrbbking does this...

    @list = (
         'item one'
        ,'item two'
        ,'item three'
    );

I picked up this particular habit from some IBM Mainframe DBAs. With the comma on the same line as the thing that comes after it, I can comment out any line of the array assignment and the whole thing is still syntactically valid. I like to keep things as clean as I can.
...in my code anyhow. My office is a pig sty.

...wait a minute... if mstone can get away with an extra trailing comma, then I guess I could comment out the last line of the assigment, and the trailing comma wouldn't cause a problem...
...so this is all in my head... Oh, boy...

[tilly]

The trailing comma is good. It means you don't have to worry about it if you add some new lines to the array.

[NoobJW]

Unless, of course, someone decides to comment out this line:

@list = (
#    'item one'
    ,'item two'
    ,'item three'
);

To be fair, I've never had to comment out the first line of a list in any language. Of course, since you are allowed to have trailing commas, mstone's solution allows you to truly comment out any line. This feature was probably added for this explicit purpose.