A meditation concerning layout style by a novice. Maybe a partial answer to the musings of others concerning the readability of Perl.
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 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:
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 ... } ...
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 ... } ...
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.
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.
In reply to A Question of style. by GrandFather
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |