Friday, June 27, 2008

Meaningful names in code.

Ever have to read someone else's code only to find out that it is unreadable? The biggest issue I find when reading other people's code is the names they have chosen. To have trouble understanding the reasoning behind a given piece of code does not require you to sift through the entire project, tracing every invocation back to the code you are looking at. All it takes is a few poorly chosen names.

It actually takes a lot of effort to create bad names in code. Say, for instance, you create a variable named x in a method you are currently implementing. This works well at first because it is easy to type and you don't need to spend any time thinking about what this value represents. However, further down the line, you are going to need to use x in some way. So, now what? What am I going to do with x? I can't possibly guess what the value of x is. It could be anything. So now go into retreat mode and find where x was initialized to check what the value could be. But it does not end there.

Chances are that if a developer is willing to use a name such as x for a variable name, the names chosen for classes, methods, and functions are not likely to be any better. So, what if x was initialized with y(). What if this same coding practice is being implemented throughout the entire project. It becomes a perpetually unreadable monstrosity.

All this could have been avoided simply be replacing x=y() with page_result=getPages(). This will allow other developers and, most importantly, yourself to infer the contents of software objects and put that saved time toward higher-level architectural objectives.