Stories
Slash Boxes
Comments
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I have two opposing examples of languages that are more likely to need comments than others: regexps and T-SQL (Sybase/SQL Server). One is extremely terse, one is extremely verbose.

    Regexps are usually very compact and opaque. Your comment about whitespace is spot on, so /x should obviously be encouraged. But even with a sanely laid out regexp, the pattern of a regexp usually needs comments to indicate exactly what (\w+-\d) means in the context of a program. The regexp syntax itself doesn't allow us to do that. And coming back to a regexp a year later, I find it immensly useful to have a sample line of text of what the regexp is supposed to match.

    Stored procedure code in T-SQL on the other hand is ridiculously fluffy. The syntax requires you to express your ideas in so many lines of code that sometimes you need a comment on top of each code block in order to summarize what it does. Kind of what a descriptive method name does in a sane langauge. The verbose syntax actually obscures the meaning of the code because of the low semantic density (wow, new word!).

    When it comes to Perl, I find that using implicit $_ often obscures the code. Not using an explicit variable means a missed opportunity to self-document the code by naming the variable properly.

    The bad rap Perl gets is probably mostly due to:
    • Special variables like $| . If you're not used to reading code with sigils, the special variables will totally throw you.
    • Regexps. Which was inherited because they were so useful, but perhaps mostly intended for one-offs in shell script situations.
    • The abundance of ugly {} when dereferencing references from sub routine calls.
    • When it comes to Perl, I find that using implicit $_ often obscures the code. Not using an explicit variable means a missed opportunity to self-document the code by naming the variable properly.

      I think the exact opposite. $_ has a meaning in Perl: “the current ‘thing’ being operated on”. That's a well-defined convention, and it has the advantage of being the same in every program.

      In other languages when people want a temporary variable they often use i or n or s, but they aren'

      • Using $i as a loop variable doesn't increase readability unless it is to communicate that "it's just a loop variable" and that's seldom the case since the Perl foreach is so much more useful than the C-style for loop.

        If the code block is very brief, like in

        dostuff($_) for(@servers);

        then I agree that it isn't necessary to alias it to a new name. But if the code block is longer than a few lines, it's indeed very useful to have an actual name connected to the entity you're dealing with.

        Consider the followi