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.