What is Good Code?

There are lots of conflicting opinions on what makes code good, so one of the first things we must do if we wish to improve quality is agree on what good looks like.

In other words we need some sort of coding standard. Depending on your experience with them in the past you probably either love or hate coding standards.

At their best they help us reach agreement on the points that matter and share what we have learnt from our earlier mistakes. At their worst they’re full of outdated ideas or act as mechanism for some-one to try and impose their personal beliefs on brace placement on as large a group of people as possible.

A few months ago we got together with developers from each of DI’s offices and talked about what we would like from a coding standard. We decided we didn’t want the second sort.

In fact one of the first things we realised was that we didn’t want a standard at all. What we wanted was guidance. What’s the difference between a standard and guidance?

While a standard is something that is imposed and checked against, guidance is something that is listened to out of choice. We also didn’t want a one way broadcast. We wanted something that is easy for people to provide their own input into – the more experience we can capture the better guidance we can provide.

And so, we ended up with “Java for small teams” – an open book that is continually updated. You may have already got your hands on a paper copy, if not don’t worry you can always read the latest version online at https://www.gitbook.com/book/ncrcoe/java-for-small-teams/details. If you have read it and didn’t like something in it please create an issue or pull request. Nothing in the book is fixed, if you disagree with something and can argue your point the book will be changed and everyone will benefit from your wisdom.

So, what does the definition of good captured in the book look like?

The best way to find out is to read it, but we’ll provide a short summary here.

• A good codebase provides ways to get reliable, fast, high quality feedback on code changes. For a project of any size this means feedback at multiple levels – static analysis, unit tests, integration tests, system tests, performance tests and more.
• Modified code can be built and launched locally, with a single command, on any machine with the build tool installed and no manual steps.
• Good code contains only the code that is needed. Code that is not needed is never written or deleted when it becomes unnecessary.
• Good code is designed to be testable, and is tested by clear readable tests that support refactoring
• Good code is modular and well designed. Known anti-patterns such as singletons and global state are avoided except in exceptional circumstances.
• Good code is built from small well named methods that do one thing only. Comments are used to provide context that the code cannot, but the preferred method of documenting the code is by making the code itself clear.
• Good code is designed to not use null, except where it must interface with third party code that must consider it.

Henry Coles
Tags: java code quality
October 12th 2016