Why Use Naming Conventions?

One of the benefits of working in a company that embraces the cutting edge of technology is the opportunity to work with the very latest in programming languages.  While this drastically improves the cool factor of my job, it also means that I get to deal with some of the normal community problems that one encounters when developing in a new or immature language.  Most recently, I have been working in Apex, the proprietary on-demand development language for building software as a service (SaaS) applications for the relatively new (and very cool) SalesForce.com.  I commented to one of my fellow developers that I was surprised by the amount of code I was seeing that didn’t follow naming conventions.  Her response was even more surprising… “What’s the big deal with naming conventions?”

Maybe it is my Java background, but that question shocked me.  In Java, very strong conventions were established from the beginning requiring classes and variables to be capitalized differently. Thus, to a Java programmer, widget.expand() and Widget.expand() imply significantly different behavior, even without prior knowledge of the Widget class and despite the fact that the compiler enforces no such rules.  Apex, to be fair to the development platform, directs developers to use the same conventions as Java.  So the lack of use is a community issue, not a language one.  But it is still an issue none the less.

At first glance, naming conventions really don’t seem all that important.  After all, most naming conventions, including those in Apex, are not enforced either at compile time or run time - so the code is still functionally correct.  However, following them makes it significantly easier for subsequent generations of analysts and developers to understand what the system is doing and how to fix or extend the source code for new business needs.

There are other reason of course (like keeping overly long or “cute” names out of applications.  But the maintenance aspect of it is especially close to my heart.  When I am looking at someone else’s code (or even my own code that I haven’t touched in a while), it helps to have certain expectations about what an identifier is and does from first glance.  Considering that a software application spends the majority of its life in the maintenance phase, every little thing to make said maintenance easier helps.  Especially when it is something as easy as following a few naming conventions.