This post originated from an RSS feed registered with Agile Buzz
by Dominik Wei-Fieg.
Original Post: Less Code
Feed Title: Ars Subtilior
Feed URL: http://typo.ars-subtilior.com/articles.rss
Feed Description: Finest Handmade Code
Random thoughts about agile software development as an art
It is a fact that the code we write today is tomorrows legacy. Have you been working with legacy code? I guess all of us have already refactored, rewritten or translated legacy code in their professional career. It can be painful. It might also open up a new view on programming topics (like when I learned about COBOL for one of the projects I was involved in).
But since our own code, written today, will soon be legacy, what should we consider when we write that code?
For me, the documentation of the code is only a part. I’m a big fan of documenting the interface level contract of code. At the same time I’m all against documenting the body of functions (which imho is a violation of DRY). I mean, where is the sense of:
#Update each item <- stupid comment!!!items.each{|item|item.update}
And that example brings me to this post’s title: writing less code will make life for those who have to deal with the legacy we are producing easier.
Less code can in my opinion be achieved by using the right programming language for the right job. The snippet in ruby above is self explanatory (even for someone who doesn’t know ruby well, all he/she has to learn here is the syntax for passing parameters into blocks). It can get more efficient with DSLs. Rails style of declaring associations is about as succinct as it can get.
For concurrent programs, using a language that supports concurrency on the language level like Erlang will make your code more terse.
I am not claiming that programs written in Ruby or Erlang or Scala or Haskell are easier to read than programs written in C# or Java. But I think that choosing the right language for the job can keep a lot of boilerplate out of your code. Some people claim that about 80% of the legacy code of any given system is boilerplate and infrastructure and only 20% are of business value (I would disagree in the case of COBOL though, my feeling is that it is more like 50/50 there). And exactly this is what makes working with legacy code annoying, tons of infrastructure to step through to find the few business parts your interested in.
Try to keep as much boilerplate and infrastructure out of your code, and the coders coming after you will thank you for this.
P.S.: Sure, you can write Java with that goal as well, keeping classes that contain business logic separated from classes that contain boilerplate, but most people don’t do it, because tha language doesn’t encourage it.
Previous Topic
