• Search

• Recently Written

  • Economy or Agony?
  • Darnit! Basecamp did it again!
  • Document Templates for Entrepreneurs
  • Evans Codeworks is Hiring!
  • The easy way to learn .NET
  • Cornell entrepreneurship on MySpace
  • Speed up Rails apps with RPM
  • Inbound marketing
  • Excellent screencasts available on .NET MVC
  • Entrepreneurship videos from Stanford

• Categories

  • .NET
  • Cornell
  • Entrepreneurship
  • Evans Codeworks
  • Fitness
  • Fun
  • Online marketing
  • Productivity
  • Programming
  • Puzzles
  • Ruby on Rails
  • Software Performance Tuning
  • Uncategorized
  • Web Development

• Archives

  • September 2008
  • August 2008
  • July 2008
  • June 2008
  • May 2008
  • December 2007
  • November 2007
  • October 2007
  • September 2007
  • August 2007

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.

This is one of the hardest things for me to do. I think it’s probably hard for many, many programmers and is the root of over-engineering.

It’s interesting and engaging to write code that does something interesting. But being able to just simply switch off that jones for all things clever in order to write code that does things which aren’t very clever, but are nonetheless absolutely necessary, is something I find difficult at times. When I’m unable to do it I find I make things more complicated than they should be. I find myself down a rabbit hole, unable to clearly see the next step. This is because there isn’t another step to be taken in the forward direction. It’s time to turn around, rethink the problem I’m trying to solve, and simplify the code in order to solve the problem quickly and with clarity.

I’m not big into writing programmer manifestos, sets of commandments or treatises on how to be a great programmer. But this is one observation that I think can save a lot of programmers a lot of time.