Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

potyl (8582)

  (email not shown publicly)

Journal of potyl (8582)

Sunday October 18, 2009
03:44 AM

Declarations and Scope followup on Chromatic's post

[ #39767 ]

Chromatic as a good post on Declarations and Scope. I'm glad to see that I'm not the only one that follows this best practice. Which by the way I was surprised to not see in Damian Conway's Perl Best Practices.

What I find the most strange is that I get constantly asked why I'm wrapping all my scripts into functions and that I don't have just plain executable code from the beginning. One of my posts in StackOverflow raised a lot of critics just by following this simple best practice: Scope bashing.

I think that all conscious perl programmers always employ use strict; and use warnigns. So I find that localizing all our code in scoped blocks (let it be a do {};, a function or even a simple code block {}) is just too practical to be overlooked. I don't think that doing this adds too much noise nor distractions to the original source code. Yet the benefits gain are huge!

Not only does this technique protects your variables from becoming global but it also helps when the code needs to be refactored. There's nothing more annoying that having a monolithic script without functions that can't be refactored easily because the code assumes each single variable to be a global!

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Calling my comment on SO "scope bashing" is unfair. I'm all in favor of scoping everything as tightly as possible. Indeed, I agree with everything in chromatic's post. But I still think the practice of wrapping a Perl script in a main subroutine is not "best" or even good. I maintain it's an antipattern that indicates the author is a C programmer, not a Perl programmer. In chromatic's example, $sth has tighter scope than the other variables, but in the first case, it's declared along with the rest. Wrappin
    • You're right that I haven't chosen my words properly. I should have said scope discussion.

      Please accept my apologies.

  • This certainly is covered in Damian Conway's PBP []:

    "5.1. Lexical Variables
    Avoid using non-lexical variables."

    And preferred use of my (or local for certain built-ins) is repeated in a dozen or more specific contexts like filehandeles, builtin vars, ....

    # I had a sig when sigs were cool
    use Sig;
    • This certainly is covered in Damian Conway's PBP: "5.1. Lexical Variables Avoid using non-lexical variables."

      I'm not referring to lexical variables (my), as you pointed out that part is covered by the best practices. I was referring to writing a single script from the top to the bottom with out localizing all variables. Remember that my only declares the variable for the life time of the current block. If the variable is not declared in a block then the file is the block scope, making the variable global.

      • hear hear!

        Whenever I encounter a substantial (>100 lines) perl script with no main sub I get nervous.

        A quick, one-off script may not require the extra structure and discipline, but we all know how easily a one-off can become mission-critical... and quickly grow in size scope and function.

        In my opinion, file-scoped vars are nearly as bad as true globals, and packaged-scoped vars less-so, but still best to avoid, unless the alternative is sufficiently more complicated code somewhere else.

        By using a main bl