By Gerald Mücke | August 4, 2017
Coding Style for high productivity and lesser bugs
In this year’s JCrete unconference I attended a very interesting session about Bugs and Coding style led by Cliff Click (The full discussion can be found here). He started about his experience as a high-performance high-professional coder, about development speed and ratios of bugs in new code, refactored code and bug-fixed code and the implication of this to the code style.
Speed of Coding and Rate of Bugs
His views and experience are especially interesting as he wrote huge parts of the HotSpot JVM, i.e. most (if not all) of its concurrency-related code. He run a statistical analysis of the JVM source code and the bugs written by him and other developers. His main observations were
- He produced 2x more code (in the same time) as the second fastest developer (measured in lines-of-code / time unit)
- The 2nd fastest developer wrote 2x more code than the 3rd.
- The 3rd … you get the picture
So he wrote as much code as all other developers combined. This was not only because he is fast but also because he wrote a lot of new code with new features, where the code grows in more explorative way and is therefore probably not yet minimized regarding LoC.
Independent from the speed, he found out that
- New Code introduces 10x more bugs than refactored code
- Refactored Code introduces 10x more bugs than bug-fixed code
- Bug-Fixed Code introduces bugs (no surprise there :)
As a direct consequence, he added, he wrote not only most of the code but naturally also introduced most of the bugs.
Natural Coding Style
During his career as developer he – as me and most of the developers do – evolved his own coding style by watching other developers code, reading other developer’s code and finding out what works best for him and what not. He states that his coding style works best for him but might probably not work best for others. But he can work fastest – or most productively – when he can write in his own coding style.
So, similar to a handwriting style every good developer develops his own coding style over time where he or she can work most productively. The remaining discussion revolved around the impact of the coding style for introducing or preventing bugs – to which I return in a minute. But before a short interlude about the
Values and Non-Values of Coding Style
The main question regarding coding style is the one about value. According to Wikipedia the main goal for code conventions is to reduce maintenance cost. This is because
- The readability and understandability is improved and therefore reduces time to read and understand it. This has an effect on maintenance but also development.
- Reduce time to read the history of changes of the code, which is often part of maintenance activity (or code archeology)
- Reduce bug rate as bugs become easier to spot
On the contrast, the following arguments are sometimes brought up as reason for code convention, but they are not very supportive as these arguments alone don’t serve a business goal.
Consistency. In the article “Why Coding Style Matters” the author wrote, that code style is for consistent code, without mentioning why this is needed. Consistency itself is not a business value. If consistency leads to reduced development or maintenance cost, the argument would be valid. But that’s certainly not always the case. Nevertheless, consistency might be a valid reason depending on the contexts. For example Apache Software Foundation projects value community most. This also means that the community has not only ownership of code but also that a lot of people contribute to the codebase. To remain open to the community a common coding style to achieve consistency is important while the productivity of each individual developer has lower priority. Nevertheless, there is no common rule that all ASF projects have to stick to the same code convention, most project communities develop their own style, while sticking to a common set of base rules, that are derived from Sun’s Code Conventions for the Java Programming Language. For example: Apache Commons, Apache Felix
Coding Style and Bugs
In his session, Cliff’s was concentrating on the 3rd above-mentioned value , the effect it has on the bug rate and his main argument was, that you spot bugs more easily in code that is faster to read and understand, while the rate of bugs per statement remains the same.
For this topic I can recommend the article Coding Style: Terse vs Verbose for a deeper understanding of the differences and effects of terse and verbose code.
But I think it’s less of a strict rule but more of a guideline which developers should follow but allowed to make exceptions to this rule, based on the context. If a method requires 12 line instead of 10 while the still has high cohesion, then do it.
So from my experience I can recommend
- Keep the methods short and concise for better and faster understanding (Martin’s Hand Rule)
- Keep the cohesion of the method high
- Each method can have as many lines as required, but not more.
For me the session was extremely valuable and insightful. I’ve seen various coding styles in my career. Some of these were easy to follow and didn’t slow me down, others I found more than once a real burden, for example: no empty lines, auto-removal of unused fields (don’t Ctrl+Save unfinished work!), no inline comments, no ternary operators, comments only in German (seriously!?), Exception class names in German, and many more. In my code I try to be as concise as possible and I prefer a more terse than verbose style.
My recommendation for a coding convention is, that it should most of all be a guideline to support developers and not restrict them.
- Terse Code: better to understand at a glance, easier to spot conceptual errors
- Verbose Code: take more time to read and understand, decreases productivity
- Control Flow: make the control flow obvious and well readable
Avoid discussions about:
- tabs vs spaces: they don’t add bugs, don’t discuss at all
- comments: they don’t add bugs, only useful if providing extra information, leave out otherwise
- empty lines: they don’t add bugs, are a good mean to separate concepts
I won’t argue, that teams should not have a common coding style. My take on this is, that a team should not spend too much time negotiating a common denominator or enforce rules that slow down half of the developers, but instead should take apply the Principle of Least Constraint and use some common sense.