What is a coding style or standard

When you look at open source projects (and closed-source ones for that matter) you may often notice that the code within the project is all written in a particular way. This is a coding style. If it is written down for the project they may even refer to it as a coding standard. Some coding standards then get used in other projects than the one they were written for. No coding style is intrinsically better than any other (discounting styles explicitly designed to obfuscate the code or confuse the reader), but personal taste will affect the style you use. It's important if you contribute to an existing project that you try and stick to their coding style if you can.

What do they cover

Coding standards can cover many things from simply how to name files and where to put them all the way up to what parts of the language you're allowed to use and where. Common things covered by coding standards are things like how and where to capitalise words, how to indent control structures, how to document the codebase, what whitespace is required and where, and how long a line is allowed to be before it must be broken into parts. Obviously not every aspect of the style will be codified in any given standard since there's an infinity of possibilities, but the above will be quite commonly found.

Some examples

There are a number of popular coding standards in use in the open source world. For example, many applications written for GNOME or GTK+ (even unofficial ones) will follow the GNU style. Almost all Python software in existence (excluding Python and its standard library) at least pretends to follow the Python PEP8 coding standard. A large number of C based projects follow the Linux Kernel coding style. Some projects have less dry documents explaining how to write code in their style - for example, the NetSurf Style Guide is a PDF.

Benefits they convey

The primary goal of most coding styles is to provide a level of consistency in the codebase which can lead to easier identification of systematic problems in the code. Sometimes unusual requirements are there to prevent issues which have been encountered in the past and corrected only by systematic use of a style. Consistently styled code also reduces the chance of spurious formatting changes during otherwise unrelated commits, making revision control history cleaner and more easily followed. In some cases, coding styles such as the Cryptography Coding Standard were written to help prevent security holes in cryptographic code.

How can they handicap you

While coding styles are usually in place to improve readability, there are times when you need to break the coding style in order to make something legible to others. It is important that coders, and projects, recognise this as something which happens and don't use the coding style as a hammer and refuse patches where sticking to style would reduce readability or making the patch match the coding style can easily be done during merge.

As with all situations which are standardised, there are so many coding standards to choose from that they often cause impedance mismatches at library boundaries. As such, it's critical that coding styles (while programmatically checkable) are not programmatically enforced without some kind of escape mechanism.