Usually, I am quite pleased with my coding methodology. But, lately, I have run into a situation that is just driving me absolutely bananas and I think it might be a sign that I need to drastically change a part of my coding methodology - specifically, my naming conventions. Right now, I have the following rules surrounding my variable naming conventions:
All scopes are uppercase (ex. APPLICATION, REQUEST, THIS, CALLER).
All keys on scopes / structs are uppercase camel-case (ex. Struct.Key). The exception to this is the URL and FORM scopes which follow under-score notation (a carry-over from my pre-ColdFusion days).
All non-scoped keys are camel-case, starting with a notation that affords insight into the data type itself (ex. arrContactrs, strName, intCount).
Whether or not you agree with these particular rules, I think we can all agree that rules are required to create coding consistency. Furthermore, I think we can all agree that code that is not consistent is hard to read, follow, and ultimately, maintain. That said, the rules that I follow have been working well until recently.
When I started to work with more advanced ColdFusion custom tags, specifically with tags that inter-communicate, I've found that my rules have created very inconsistent looking code. For example, if I have a child tag that get's access to its parent tag using this notation:
<cfset objParent = GetBaseTagData( "cf_parent" ) />
... I might easily end up with variable chains that look like this:
... or even worse:
This is disgusting and it's driving me crazy. In the first line, we have conflicting naming conventions. In the defining context (parent tag), "objConfig" is the proper notation as it is an un-scoped variable. However, when it is referenced from the child tag, it is a scoped variable, which should dictate that it uses capital camel-case. These two are directly conflicting, and I certainly can't have rules that dictate notation based on context!
The second line is even worse! I have a scope that is now the key of another struct. In one line, I use all three naming conventions chained is a crazy order. I see that line and my stomach gets upset. Coding it actually made me feel dirty.
While this situation makes up only a tiny portion of my coding experience, it is enough to convince me that my rules are bunk. If I can't be consistent with my rules, well then, I don't want those rules. So, what rules do I want?
Ironically, and I'm sure many of you will get a chuckle out of this, it seems that I should be following more "traditional" naming conventions as they seem to cover this kind of situation nicely. For example, using a more standard notation, the above lines would look like this:
What I've done here is removed the Hungarian Notation and reverted back to a headless camel-case format across the board. This is nice because it affords consistency across all areas of code (that I can foresee). I'll probably miss the uppercase SCOPES because they offered excellent visual differentiation; but, in reality, that is not a great rule to begin with because in ColdFusion, there is no true separation between scopes and standard structs: Some objects are scopes; others are specialized scopes (ex. CGI, ARGUMENTS); others are really just structs (ex. THIS is a member of VARIABLES inside CFCs). Plus, when you can arbitrarily add structs to the list of objects that ColdFusion implicitly searches for variable references, the line blurs even more.
I'm not going to change my coding style this very second - I'm gonna let this idea simmer for a bit; but, something clearly needs to be done. That nested ColdFusion custom tag example is disturbing and cannot be allowed to exist. Perhaps this is something that I'll just have to start on my next project so that my existing projects don't become inconsistent.
Want to use code from this post? Check out the license.