Code Readability vs. Number Lines of Code

Last night I read a blog post by Phil Hack. In the post he talks about why do I have to write a commit inside an using statement when working with transaction. He then wrote some nice code to abstract the commit into a reusable function. It was a nice solution and reduced the total number of lines of code.

I was reading through the comments and someone said that by doing this he makes the code less readable. He also pointed out that debugging will also be more challenging since it is an abstraction, but I want to focus on readability. In Phil's example I did not think the readability really changed all that greatly but the person did have a valid point in general.

When writing code there are always trade offs that need to be made. less lines of code could be seen as cleaner and more optimal but at the same time it is harder for understanding what is really going on. Usually when I write code I try to make it readable, and then refactor in areas I feel are to verbose. The reason I like this is because someday someone else will be looking at the code to support it and I might not be around for them to ask me why it is as it is. Heck, I might be around and not remember why did what i did.

Don't get me wrong some abstractions I think are good, and I might use Phil's technique in future coding I do, but developers need to find a balance between abstraction and readability. I really am not a big fan of AOP for this reason. Sure it makes sense but from a practicality side of things it might not be the best solution.

Well rambling on this topic is done for now. If you have comments or want to agree or disagree hit me up.