camelCase Is Illegitimate
I spend the overwhelming majority of my time programming not actually writing useful code, but instead staring in melancholy despair at the ugliness of the code I’ve already written. Computer Science is literally a (sub)field of Mathematics, and Mathematics is about the Structure of Things. Code is the textual harnessing of structure—up to and including a direct reflection of the Lambda Calculus. Code is supposed to be beautiful.
Of course, code (at least of any real scope) is not beautiful, it seems, no matter how much we try. I like to think that my recent code is among the cleanest and elegant that exists (and such useless time-wasting creating such is why I am still fairly unaccomplished as a programmer, even after decades of coding). Yet I also like to think that my “coding standard” (such as I have a formal one written up), is highly evolved.
Let’s talk about naming. There is:
UPPERCASE_WITH_UNDERSCORES
lowercase_aka_snake_case
TitleCaseWhereAllWordsAreCapitalizedAndThenConcatenated
camelCaseWhereEveryWordExceptTheFirstIsCapitalizedFor a long time, I tried to make use of all four (for maximum contrast). Uppercase and lowercase are (generally) the obviously correct choices for macros and variable names, respectively (no dissent is tolerated on this point; you are objectively wrong if you disagree). Title case is a good choice for structure types and namespaces because it stands out compared to the variables—albeit the C++ standard library’s pointed lack of this convention is either a bug (where’s my consistency?!) or a feature (title case denotes custom structure types; the lowercase stuff is what’s built into the language . . . I guess).
That leaves camel-case for . . . well, for what?
I learned Java in undergrad, and camel-case was encouraged for methods (in better languages, like C++, read that as ‘member functions’, and optionally also ‘functions’, ‘routines’, or ‘lambdas’). I’ve also seen it used for enums, and even for structure types. This all seems to work okay for a little bit, but it all ultimately comes crashing down. I finally pinned down why:
You see, camel-case is illegitimate.
Camel-case is a fundamentally broken idea, and it took me more than a decade of programming to finally (care enough to) pin down quite why. It ultimately comes down to the camel-case capitalization rules leading to inconsistency (albeit there are a few different flavors of camel-case, so this argument demands some elaboration).
Consider how we handle a routine for initializing OpenGL (for which the tokens we are wanting to use are init and OpenGL). Lowercase is great:
void init_opengl();It’s perfectly clear what’s going on here. Sure, OpenGL got decapitatedtalized, but we expected that, and it doesn’t impact readability.
Contrast that with camel-case:
void initOpengl();This is a bit awkward—now, OpenGL, which is a proper name, is capitalized, but the GL, an abbreviation, is not? The capitalization Opengl looks like a clueless tech journalist, writing about concepts he has never touched and cannot possibly appreciate. A variant would be:
void initOpenGL();This is also bad because it suggests the tokens were init+open+g+l (of uncertain original capitalization), which is not really right either.
It gets even worse if there are more tokens. Consider:
void initOpenGLXServer();Is this initializing / opening a GLX server? Or is it initializing an OpenGL X-Windows server?
Granted, title case doesn’t have a good answer for these questions, either—but title case was not on the table for function calls in the first place. If you use it for structures, as I do, then you’re naming nouns instead of verbs, which I anecdotally find are more amenable to fixing, or at least avoiding, these issues (by renaming or cheating with an underscore). In any case, structure names are (should be) less common in your code than function calls, so it’s less of an issue that way as well.
What does this all mean? It means what I said—camel-case is a fundamentally broken naming convention. Never use it.