I’ve contributed code to a number of projects, often as a drive-by bug fix in a GitHub pull request. And, usually, I’ll try to do as the Romans do and follow the local naming and coding conventions. But, sometimes, I’ll fall back to my personal conventions and get dinged in the code review.

For what it’s worth, those personal conventions look something like this:

variable_names_in_snake_case : Variable, a mutable thing. All lower case, words separated by underscores.

CONSTANTS_IN_ALL_CAPS : Constant, an immutable thing. All upper case, words separated by underscores.

functionAndMethodNames : Functions and methods, immutable and callable things. Mixed camel case, first letter always lower case.

StructAndClassNames : Structs and classes, immutable and instantiatable things. Mixed camel case, first letter always upper case.

Of course, given the features of any particular language, these rules yield subtleties. For instance, in JavaScript a variable can be assigned a callable thing, a declared function can be replaced by assignment, and classes & methods are themselves mainly just suggestions. These conventions are more about my intentions than anything literally baked into syntax.

I’ve been using some variant of the above rules for close to 20 years, across probably a dozen languages. On JavaScript projects, I end up with snake_case in undesirable places. On Python projects, I’ll use CamelCase where it’s not wanted.

On the Python side, I know there’s PEP 8. That’s something to point at and claim uniformity, and it has tooling support. On the JavaScript side, I seem to be missing some recent consensus amongst the current wave of browser and nodejs enthusiasts. That, or I’m just contributing to more projects than my own these days (thanks to GitHub) and only running into this now.

But, here’s what always leaves me mildly rankled: Why just one or the other? Why discard the semantic shading available through mixing snake_case and CamelCase, at least by way of consistent rules? I know there’s a such thing as syntax highlighting, but combining that with these conventions has often helped me with highlighting is unavailable. Belt and suspenders, and all that.

Of course, I prefer my rules, because they’re a deeply ingrained habit. I know this is my peeve. But, what I’ve never quite been able to get is a satisfying answer as to why one style is preferred to the exclusion of another. Usually I get responses like “That’s just the way it’s done”, or “The other way is ugly”. So, it’s down to personal whim, project momentum, or cargo cult.

I guess it bothers me to see a perfectly good semantic tool thrown out for no good reason as far as I can tell. Feel free to drop me a comment here, if I’m missing any good reasons. Some additional bits and pieces accumulate below:

• Here are some arguments against CamelCase for accessibility reasons and for non-english speakers.

• The Twisted project uses both CamelCase and snake_case in the same variable names. The bit before the underscore signifies the type of a method, and the bit after is the name – eg. remote_loginAnonymous or test_addDSAIdentityNoComment.

Anyway, this has been bugging me for long enough that here I am finally blogging about it, so that I have an URL to throw into conversations when it comes up.