Coding Style and Standards

The style and alignment of code is a deeply personal and functional choice for developers. The styles and rules that I use are not going to be to everybody's taste, but there are very good reasons for them.

All of these rules are designed to improve readability and comprehension of code, thus improving reliability and maintainability. There will always be exceptions – bits of code that I've not tidied up, or taken shortcuts on. But my aim is to apply these as best I can, where I can, to all the code I write, whether it be C, VB, PHP, JavaScript, or even Assembler.

Rules

In Detail

Structured programming

There are two fundamental concepts that are critical to writing structured code. They are key to producing code that is easier to understand and less prone to error.

1. Single entry/exit point for functions

No early returns. There should be one and only one return from a function. It should be at the end of the function, not competing with others tucked away in the middle.

Less relevant to most languages is that there should be only one entry point to a function, and that should be at the start. Occasionally in assembler there are very good reasons why this is not the case. If so, the entry points should be very clearly highlighted.

2. No abnormal flow control

Don't use break or continue (or goto). What you write should be what you want. Don't change your mind later in the code or take shortcuts to terminate a loop. Obviously using break in a switch statement is allowed, as is sometimes (unfortunately) the early termination of a foreach loop if it is needed. But there are no exceptions for for or while loops. Don't be lazy – code what you actually want the loop to do. If it terminates on finding an item, include that termination condition in the for or while condition. Don't bodge it with a break, continue or return inside the loop.

Whitesmiths indentation

If Whitesmiths is used consistently with braces aligning vertically, it becomes visually obvious how braces match and if they are missing. That helps with code readability and comprehension, and can be the difference between seeing and missing a bug.

The Whitesmiths style (and also the Allman style), where the opening and closing braces share the exact same column, makes scanning a large file vastly easier on the eyes compared to styles like K&R or 1TBS (One True Brace Style), where the opening brace is tucked away at the end of a line. Alternatives like K&R/1TBS/Linux were designed to prioritize vertical screen real estate on early 24-line Unix terminals, cramming as much code onto the screen as possible, and are not conducive to readability.

I actually prefer a slightly modified version of Whitesmiths where the braces of top-level function blocks start flush against the left margin to clearly demarcate them. Whichever you choose, you misalign your braces at your peril.

Hungarian notation/camelCase for variable names

For example intCount or $strMyName. Critics often dismiss Hungarian notation as a legacy relic, arguing that modern IDEs display types on mouse-over. But relying on tooling turns reading code into an active, friction-heavy interactive exercise rather than passive comprehension. This is doubly true for weakly typed languages like PHP and JavaScript, where variables can mutate or accept ambiguous values fluidly. Even in strictly typed languages, embedding the intended type directly into the variable name ensures that anyone reading the code – whether in an advanced IDE, a raw terminal diff, or a printed code review – immediately grasps the developer's intent at a glance, bypassing the need to hunt through distant declarations. Rejecting type prefixes because of an IDE feature or potential code evolution is simply an excuse for lazy programming and poor discipline.

I'm not completely hung up about Hungarian notation where structures and complex variable types are concerned, or where a variable scope only lasts over two or three lines. But helping variables to self-document their type will always assist with understanding.

PascalCase for function names

For example DoSomething(). Using Pascal case keeps function names sufficiently differentiated from variable names. Snake case does the same, but to my eyes looks worse. Using Pascal case often also helps to differentiate your functions from built-in language functions.

Single-line brace-less blocks

Single-line brace-less blocks are part of the definition of the language syntax, so learn to love them. They should always be indented on the line following the control statement. And if Whitesmiths (or Allman) indentation is used consistently, then there is absolutely no confusion over single-line blocks after an if, while or for statement. It is abundantly obvious if the braces are missing. Critics often point to catastrophic vulnerabilities like Apple's infamous 2014 "goto fail" bug to argue that omitting braces invites human error if code is edited hastily. However, that risk entirely presumes sloppy maintenance or an undisciplined layout. When paired with strict Whitesmiths or Allman alignment, omitting redundant braces keeps code clean and tightly coupled without sacrificing structural intent.

UPPER case for fixed constants

Using upper case for any fixed constant – defined symbolic constants, type definitions, etc – helps to highlight that they are fixed, and again to improve readability and comprehension.

Final word

These rules are not up for debate. After nearly half a century of writing code, these are the standards I try to adhere to because they fundamentally optimize reading, reliability, and maintainability for my workflow. I invite you instead to reflect on your own habits, and how they might assist you (or otherwise) with reading, reliability, and maintenance in your own coding.