pages tagged styleyakkinghttp://yakking.branchable.com/tags/style/yakkingikiwiki2013-12-31T12:00:58ZCoding styles and standardshttp://yakking.branchable.com/posts/coding-style/Daniel Silverstone2013-12-31T12:00:58Z2013-12-31T12:00:18Z
<h1>What is a coding style or standard</h1>
<p>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.</p>
<h1>What do they cover</h1>
<p>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.</p>
<h1>Some examples</h1>
<p>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 <a href="http://www.gnu.org/prep/standards/standards.html">GNU style</a>. Almost all Python software in existence
(excluding Python and its standard library) at least pretends to follow the
Python <a href="http://www.python.org/dev/peps/pep-0008/">PEP8</a> coding standard. A large number of C based projects follow the
<a href="https://www.kernel.org/doc/Documentation/CodingStyle">Linux Kernel coding style</a>. Some projects have less dry documents explaining
how to write code in their style - for example, the <a href="http://www.netsurf-browser.org/developers/StyleGuide.pdf">NetSurf Style Guide</a> is a
PDF.</p>
<h1>Benefits they convey</h1>
<p>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
<a href="https://cryptocoding.net/index.php/Cryptography_Coding_Standard">Cryptography Coding Standard</a> were written to help prevent security holes in
cryptographic code.</p>
<h1>How can they handicap you</h1>
<p>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.</p>
<p>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.</p>