A recent employment which has us busy cranking out a fair amount of PHP got us thinking about code style. We've always been proponents of consistency and ample documentation and commenting, but it is interesting to note how our own style has changed, and why.

When new to programming, most programmers naturally concentrate more on the function of their code and less on form... probably most often instinctively absorbing the conventions and form they encounter in books and examples. After all, the prettiest code in the world is useless if it does not complete the intended task.

Later, we may start to incorporate other style conventions that we personally gravitate to as we encounter them. Few programmers probably give this much thought as they settle into a style (and of course, this can lead to the perpetuation of undesirable habits).

Wikipedia has an interesting article on Indent Style which, as self-taught programmers who indeed absorbed the style around us as we learned, was rather enlightening. Looking back at PHP we generated long ago, it seems we originally fell into a Banner Style (which many PHP authors use):

function1 () {
   dostuff
   do more stuff
   }
function2 () {
   etc
   }

In the last few years (probably due to our exposure to some examples in C# written this way), we've moved to a Whitesmiths Style, which we find to be supremely readable:

while (x == y)
   {
   something();
   somethingelse();
   }
finalthing();

But we never truly considered why we wanted to code this way. (Indeed, we didn't even know what it was called.) Wikipedia explains:

...blocks are clearly set apart from control statements. However with Whitesmiths style, the block is still visually connected to its control statement instead of looking like an unrelated block of code surrounded by whitespace. Another advantage is that the alignment of the braces with the block emphasizes the fact that the entire block is conceptually (as well as programmatically) a single compound statement. Furthermore, indenting the braces emphasizes that they are subordinate to the control statement.

Digging deeper into code style... we've discovered several code style guides, a thorough example of which is iMarc.net Code Standards (which is derived from Horde's Standards). Of course, we don't personally agree with everything in these standards documents (like for instance the indent style), but they are excellent frameworks for generating clean standard code. The significant word here is standard... all programmers generally agree that what style you choose is less important than your unwavering adherence to it.

A truly beneficial exercise for any programmer would be to generate a standards document for themselves. This could be a simple document covering the major conventions (such as indent style and naming conventions), or it could cover secondary subjects too (such as maximum line-lengths and a standard form for page header comments). Sure, some like us, may have been handed a similar document where we work, but actually putting together a document like this (perhaps incorporating or building upon your workplace or project standards), will encourage you to understand and take ownership of a standard code style.