The Value of Code Clarity

Programming is a “read-mostly” endeavor. Source code should easy to read. Source code should emphasize code that “does stuff”, not “busy work” code or “code noise”.

Get/setters are “busy work”. They’re frequently over-used for the sake of adherence to the Java beans convention.

I recently spoke with Andrew Myers, a Cornell professor whos specialty is programming languages (among other things). I spoke with him about writing a small bit of syntactic sugar for Java to allow getters and setters to be generated automatically at compile time for class attributes for which no getter or setter existed. His response was insightful.

I typically need getters and setters to access private class attributes. Professor Myers basically told me that it sounded like I wasn’t properly designing my classes. Instead of declaring private attributes and allowing access to these attributes via get/set methods, I should be just declaring the attributes with the appropriate scope. This seems like a perfectly obvious answer. So why didn’t I do that in the first place?

I use the Spring Framework a lot. Spring provides aspect-enabled dependency injection. This is a great facility to have. It allows for code that can be simply reconfigured via xml descriptors. The alternative would be to require that the code itself be modified and recompiled to produce a new executable. Overall this isn’t a very flexible option. So Spring provides a great deal of value in this regard.

The downside to the way Spring does dependency injection is that it requires public setter methods for each attribute that can be injected. This is an easy enough thing to do. But, it encourages a very sloppy paradigm of having setters in order to provide the hook that Spring needs.

For Java, Spring does a good job. The Java language, being compiled and statically typed just requires more verbosity than a language like Ruby.

I personally find the Ruby syntax for declaring class attributes to be much less verbose and much more clear.