- Capital Letters and Underscores
- Microsofties
- Brevity
- Dealing with It
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Dealing with It
So what do you do when you encounter code with a strange, ugly, stupid naming convention?
Learn the convention and use it.
Despite all the downsides, and the fact that you'll have to live with knowing you've written some ugly code, there are several reasons to mimic the naming style that you encounter in the code you maintain:
As ugly as the naming convention might be, it'll be even uglier as a hodgepodge of styles.
Violating the naming style leaves "seams" in the code. That is, it becomes obvious that the code was written and maintained by several people. This sets off the programmer's sense of disharmony, which triggers the code as a likely place to look for errors. If the code is actually okay, that can lead to wasted time. Presumably you plan to test the code and ensure that it works; don't leave footprints that flag it as potentially erroneous.
The naming style may be there to prevent identifiers from bumping into each other in the namespace. Failure to follow the naming convention can lead to a clogged namespace, which can lead to compiler errors at best, and bugs at worst.
Every naming convention has at least some merit to it. Naming conventions are a matter of tradeoffs: clarity versus brevity, ease of reading for some people versus others. When you combine naming conventions, you tend to get the worst of both worlds, not the best.
Finally, violating the naming style can confuse the next maintainer. For example, if I expect that all member variables begin with m_ and I encounter a variable without that prefix, I'll assume that it isn't a member variable. That can send me off on a wild goose chase to figure out what it actually is. The inconsistency is worse than not having the convention at all, because it's misleading. If the code never uses the prefix, then I won't make any assumptions about the names, but if it uses the prefix 99% of the time, then the remaining 1% of the cases will confuse the daylights out of me.
Remember the next maintainer to come down the line. If you believe that you're the last maintainer who will ever work on a project, I can assure you that you're wrong.