In terms of books relating to software engineering, I normally prefer slim books over weighty tomes but found this one - which belongs to the former category - by and large a bit too laconic. In fact, one could probably argue that it is not a lot more than merely a very good introduction to programming in Java.
Nevertheless, I had a good time reading it and here are the key points that I'm taking with me:
- Much more time is spent reading code than writing it.
- Code that's easy to understand is more maintainable.
- Try extremely hard to come up with concise and meaningful names for classes, methods and variables.
- First and foremost, optimise code for readability not performance.
- Don't restrict yourself to a specific case if you can easily be more generic (e.g. use Collection instead of List if your code doesn't require index-based element access).
- Don't make members more visible than they absolutely need to.
- Keep data and logic as close together as possible (i.e. encapsulate).
- Don't flinch from creating one-line methods if they increase readability (e.g. write void setLoadedFlat(); instead of loaded |= LOADED_BIT;).
- [Probably my favourite part in the book:] Don't "thoughtlessly obey programming folklore" (e.g. don't always stubbornly use only one return statement if you can use guard statements such as:
void compute() {
Client client = getClient();
if (client == null)
return;
Request request = client.getRequest();
if (client.getRequest == null)
return;
process(request);
} - Implementation strategy is the extraneous information most often included in method names (e.g. use Poll.vote() instead of Poll.incrementCounter()).
- Express as much information as possible through code and structure rather than comments.