writing meaningful code
I work in the travel industry. Those of you who have ever had experience with air travel, you may know that this industry is full of complex business rules, exceptions, exceptions to exceptions, and general mayhem. Couple this with the nature of our product: a switch between airlines and travel agencies, and you get a whole lot of code that does lots of little complex manipulations on our domain model to get it to dance to this cacophany. The net result is a lot of unreadable code that can’t really be made more readable—or can it?
I find that whenever there are even four or five lines of code that I cannot understand at first glance, they’re a good candidate for refactoring into a method. I will even go so far as to say that any _one_ line of code that cannot be easily understood should be encapsulated in a well named method. The reason for this is your code then starts looking like doSomethingGroovyAndComplicatedWith(Someobject). This acts as an automatic description for what’s going on without any extra comments. Instead of writing a thirty line method of messy code, break it up into six little methods and give each step a careful name. Now your thirty lines of junk has turned into six lines of meaningful code, with the details hidden. This may be obvious until you look around the codebase and realize how rarely this is done.
5 Comments