I’ve always been a big believer in using a robust naming convention.  I’ve used a modified, slimmed down version of Hungarian Notation for years now, and I swear by it.  I love having all the information I need immediately available in the variable’s name.  No need to leave the code I’m working on, no need to hover the mouse on the variable, it is there for me to reference at my leisure.  That’s why I’ve relied on a naming convention for so long.

However, there are huge problems with naming conventions as well.  First off, naming conventions break the DRY (Don’t Repeat Yourself) principle.  If, for example, you need to change a variable from a char to a String, you run the risk of forgetting to refactor the variable’s name, making the variable provide faulty information to other programmers relying on the naming convention.

Another point against it, if a team does not define a naming convention, or even if they do have a naming convention but don’t actively enforce it, several sub-naming convention will sprout.  Some classes will use one naming convention, others will use a different one.  It will create a confusing mess of conflicting standards.

There’s probably other issues as well, but the biggest problem you face with upholding a standard such as this is how it becomes exponentially harder to manage as the codebase and the number of programmers working on the codebase grows.  My notation was used strictly at a small start-up, that’s why it was manageable.  But, when you have multiple teams, working in multiple locations, all with their own sub-policies and procedures, you’re facing a optimal situation for any standard to fail.

However, in this instance I do believe there is a remedy, at least in theory, and I don’t believe abandoning naming conventions is the answer.  I return to an idea talked about in a previous post of mine, Standard Style.  Every day programmers waste time deciphering unfamiliar syntax and are constantly back referencing variables that don’t immediately provide feedback of their purpose.  These are wasted cycles that could easily be avoided.  The thing is, as stated in the post on standardizing style, you have to take the burden of upholding a standard or procedure out of the programmer’s hands.  It’s time to throw the burden on the computer, more specifically the compiler.

If you don’t agree with the above statement, that’s fine.  Let’s digress for a moment.  I’m sure we can all at least agree that we should be writing code in a way that some other programmer, two years after you have left the company, is able to understand what it is that you did, what the code does.  We break shit into different classes, avoid letting our functions get unwieldy, provide informative names for our variables; we do our best to organize code in a workable structure.  This stuff is common practice, used  to make code more maintainable.  But, why is it that we rarely look lower than that to increase our efficiency?  Why don’t we examine the raw nature, the meat and potatoes of writing code (actually, I’m sure IDE developers do a lot of this)?  You could do all the things mentioned earlier in this paragraph in order to create a maintainable application, but if you and the programmer two years from now don’t code in the exact same format, don’t use the exact same naming convention, a ton of time is going to be spent adapting to a new way of viewing the same old thing.  It’s wasteful, it’s inefficient and it forces us to venture outside the problem domain.

Trivial differences are time consuming.  Syntax formatting, naming conventions (though not the actual descriptive part of the variable name), these are trivial in my opinion.  I really don’t care what naming convention is used (as long as it’s informative), or how my code is formatted, as long as these things are consistent.  And that’s the key point, that’s the magic word that basically ties this blasphemy all together…consistency.  There’s just too many programmers for consistency to be a possibility if the task is left in programmer’s hands.  It needs to be something built-in to the compiler.  Any other method, scripts, peer-review, anything that does not 100% force our hands will not work.  It’s time to make more robust compilers, compilers that don’t just make code readable for the computer, but also makes code readable and consistently formatted for us.