A meditation concerning layout style by a novice. Maybe a partial answer to the musings of others concerning the readability of Perl.

Preamble

As a new member of the brotherhood I guess it is expected that there will be a few things I don't understand and that I will bring a little baggage from the world at large. I will try not to disturb the sanctity and serenity within the walls of the Monastery and I appologise if I fail in this. However the matter I wish to discuss often raises the ire of the unenlightened in the outside world. I hope that you who have more experience in the realms of Perl will ponder my humble musings and reply with your wisdom and enlightenment, but without the angst so often encountered in less enlightened society.

Having come from a background in other languages (which will not be mentioned, but may become evident), and having thought deeply from time to time about matters of style in the manner of laying out program code, I have a few observations I wish to make concerning programming style in Perl.

The meat

The first observation is that the lamentable K&R block indentation style is pervasive in this community (as in many *NIX aligned communities). Can we do better? There are a number of points that occur to me when formulating a style for block layout:

  1. is the block structure obvious even to someone who may prefer a different style?
  2. is the relationship between blocks (and statements) obvious?
  3. is it easy to check that brackets match?
  4. are the brackets that delimit the block part of the block?
  5. is editing facilitated by the indentation style?

Points 1 and 2 are related. They are about readability and understanding by some else such as your maintenance programmer.

Point 3 is for you. When the fumble fingered compiler miscounts the brackets, how quickly can you prove it wrong by rubbing its nose in your carefully laid out code?

Point 4 is part of a justification for particular style decisions. If the brackets are part of the block they should be at the same indentation. After all, they are part of that which is being indented.

Point 5 is entirely pragmatic. If you can't edit the thing or it takes too much effort it ain't no use nohow.

Ok, having pondered that lot, how can we improve on K&R? Try this:

if ($SomeTest) {# Brief opening comment to describe this block ... } elsif ($AnotherTest) {# Brief comment for this block ... } else {# Ditto ... } ...

Note that the brackets are indented to the same level as the rest of the block (now you know that I think the brackets are part of the block). If the brackets weren't part of the block then most likely the block would be indented inside the indented brackets.

if ($SomeTest) {# Brief opening comment to describe this block ... } elsif ($AnotherTest) {# Brief comment for this block ... } else {# Ditto ... } ...
That variant meets most of my criteria, but does require more effort editing and consumes horizontal space at a furious rate.

Why is my suggested layout so much better than K&R?

if ($SomeTest) { # Brief opening comment to describe this block ... } elsif ($AnotherTest) { # Brief comment for this block ... } else { # Ditto ... } ...
The block structure isn't obvious to me. All those trailing } obscure the important stuff like the elsif and else. The {'s hidden on the end of lines can't be matched with their closing }'s without some effort, and no editor that I use puts the closing }'s in the right place for me (not that I've tried real hard :-)).

Ok, there's enough to get you going about indentation. How about white space usage? Its a little more subtle, and perhaps a lot more important. Until we started to learn Perl (and for some of us, even after) by far the majority of reading we did was English text (if you're reading this that's likely the case). There are conventions on use of white space in written english( this is unconventional for example ). So, where possible, why not apply those same conventions to our coding style?

Written English is structured as a hierarchy (words, phrases, sentences, paragraphs and chapters ...) to help reading and understanding. Well, what do you know, so is Perl! Maybe we can use something like the same structure to leverage our well trained written English parser (yer brain!) for use in parsing code?

How does that work? Well, for a start white space goes outside brackets (like this), not inside( like this ). There is white space after punctuation, like this, not omitted,like this.Why do we do that? Well, it helps us tokenise the strings that we are dealing with. Compilers don't need that sort of help, but they don't have to do a whole lot of pattern recognition either; we do.

Summary

Is any of this important? Actually, I think it is. Perhaps indentation is a little less important with Perl where often a problem solution is very short and its life time may also be short. But with larger projects (say, more than 40 lines) and projects that may have a long life time, writing for later understanding is much more important than saving a few keystrokes in the short term. In any case judicious use of white space helps make meaning clear for programs of any size.

And figuring out you own reason for doing something is much more important than just following along the rut worn by everyone who went before you.


Food for thought, not fuel for flames.

In reply to A Question of style. by GrandFather

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.