The SANS Institute has published a list of the top 25 most dangerous programming errors and reading through the list was pretty much like meeting a bunch of old friends. Such lists may seem self evident to some but that doesn’t stop development teams falling into the same traps today that were being fallen into ten, twenty or even thirty years ago.
The first thing that struck me was that the list talks specifically about internet application development. Now some younger commentators have pointed out that ‘all this was covered in my degree’. However for anybody who’s been in work for ten years or more, such courses would not have covered preservation of web page structure or cross-site scripting issues because the internet was so young that it was not an issue. It also got me thinking about the wider issues around coding standards and reviews, and why we are so bad at creating and adhering to standards, performing reviews. In short, development teams are still woefully ineffective at learning from the mistakes of others.
In the absence of defacto standards (more on that in a minute), companies, and even individual programming teams, are still reinventing the wheel when it comes to even the basics around design and coding standards. To some degree it is the problem of ‘not invented here’ syndrome, but equally there is no high profile, comprehensive source where a team can go to pick up a ready made suite of standards, review checklists and development tools and configuration to match; this appears to apply regardless of the language that development is taking place in.
At this point I’m going to move away from the language independent nature of the post so far and focus on Java, as is my wont. Java is a language with a defacto programming style, that is to say, Sun provide very clear direction on many aspects of how Java code should be written. While it is not comprehensive – to which anybody who has used it as a basis for their own coding standard will attest – it is a good starting point. In general, standards should be:
- As brief as possible. Long-winded standards are harder to digest and implement.
- In plain English. Make sure people can easily understand them.
- Written and supported to make compliance easier than non-compliance.
In short the Sun standard is an excellent starting point as not only does it cover 90% of any mainstream coding standard you are likely to develop, but it is also the defacto standard used on training courses and in programming books.