Art of formatting code

Programs must be written for people to read, and only incidentally for machines to execute

Hal Abelson

Programmers commit a lot of sins wrt writing code on a regular basis but perhaps none of them is worse than writing ill-formatted code. Ill-formatted code not only makes the code look ugly but also makes it tough for anyone to follow and adds more stress to a person trying to understand the piece of code. It is like asking a person to aim for a bullseye in a game of dart on a wobbly surface, making his difficult task much more difficult.

Formatting and spellings to me is such a big deal that I have rejected potential candidates at my workplace for the same reason. I personally do not want to work with ill-formatted code and code with typos all over and think that a good developer will keep his code well formatted and without typos even if he knows that he doesn’t have to work on it later or maintain it in the future.

Its important to understand what well formatted code means.

• Code follows consistent formatting rules and doesn’t mix them
• Enough white space. Like spaces between operators and values. eg: x = y + z is more readable than x=y+Z any given day
• Not too much white space. 1 space/new line character is more often that not sufficient in the context of code, anything more is a overkill and can piss people off
• Maintains correct level of indentation. Indentation is a visual cue to the reader to understand code blocks faster, but if this is messed up this might cause nightmares to the reader
• Follows code prose. Writing code is like poetry and one must learn to group logical parts of the code and separate such groups with a single white line. One should be able to summarize such a logical group in a single line.
• Logical separation and minimal code duplication
• Zero typos