Coding Style

Wow, you could fill a book on this subject. And some people do.

The guidelines for coding in Java, my language of choice, are fairly fluid but there is usually a general consensus of opinion on most topics. Here are a few:

Always declare variables as final.
I only explained this one last night so it’s still fresh, and yes, in a sense it’s not a variable if it’s final.

The idea is that if a variable can have its value changed it can be confusing and lead to bugs. If every variable is final you have only to know what value it was initialized with. There is a peculiarity when this style is adopted (and eclipse will do this for you if you configure it) – anything non-final appears like a warning, particularly useful for parameters which should remain constant through a method invocation. Imagine a function working on width and height that changes the height halfway through.

Making all variables final used to be tough as some people believed in having only one return point in a method. This argument has been answered in the Java world by Kent Beck, one of the founders of XP / Agile and creator of the JUnit framework. Single Entry Single Exit, he says,

was to prevent the confusion possible when jumping into and out of many locations in the same routine. It made good sense when applied to FORTRAN or assembly language programs written with lots of global data where even understanding which statements were executed was hard work … with small methods and mostly local data, it is needlessly conservative.

Use static methods sparingly.
This didn’t matter a great deal in the past and in projects without unit tests will be less important. If you don’t have unit tests but do have business logic then you may have bigger problems.

Originally, static methods were ok as they indicated a stateless method or function. This sounds good because you don’t need to create an object to provide you some functionality – just call a method on a class. The problem with this approach is that you cannot override static methods. It’s not very ‘object oriented’ – there is no object doing the work, just a hard-coded reference to the implementing method. No abstraction – this is the implementation. Always. Well, you can override this using some mocking frameworks with functionality generally considered for ‘legacy code.’ This should tell you all you need to know. If you are hard-wiring this method into your production code but need different behavior (in tests) and achieve it with compiler tricks instead of polymorphism, some would consider this to be missing the point. I’ve seen people do very elaborate things and get into very long arguments about how to avoid using polymorphism. This seems to be missing the point on purpose. The same people will prefer untested private methods over tested package-private methods and good luck with that.

Software Development Analogies

Software development is full of analogies, e.g. creating software is like making such-and-such. None of the analogies I’ve come across get too close – each just serves a small purpose. Here are some analogies I’ve used or come across in software development:

Building software is like building houses in a time before they knew how to build houses.
This is my own, which is why I put it first 🙂 By this I mean that a lot of the way software is written is wrong or inefficient. In the software development community we are very capable of writing systems that look like they work but are seriously lacking in ‘non-functional requirements.’ Following the house analogy it would be like having a building that from the outside looks like a house but just isn’t quite right – and ‘not quite right’ enough to the point of needing replacing within a few years. Houses aren’t typically built like that anymore as far as I know. Well, that’s the house-building analogy gone then.

A software development team needs a foreman.
This one was made famous in 2014 when it was made by Uncle Bob Martin. An example of this idea was “He’d do the same thing he does on a construction project. He’d make sure everything was done, done right, and done on time. He’d be the only one with commit rights.” Rather than trying to find anything useful in the analogy, I think a lot of people just picked holes. Code reviews are important on most projects and the most experienced developer checking all code could be very beneficial. Once I remember seeing someone had completely misunderstood Hibernate and, unless the code reviewer understood Hibernate, this code would make its way into the codebase.

The software development team as a surgical team – F.P. Brooks.
This is an idea Brooks relates in his famous book “The Mythical Man-Month” which I’d recommend to any programmer who can read. He actually credits the idea to Harlan Mills. The thing that captures my imagination about this idea is the notion of having a ‘toolsmith’ – my earliest development role evolved into managing an API which I’d implemented in PHP, Java and Visual Basic. I kind of fancied myself as this toolsmith. Where Bob Martin has an idea of a foreman checking everyone’s work, Brooks / Mills have a chief programmer and co-pilot.