Escaping the Identifier Casing Orthodoxy

My initial programming experience was with Ruby and Python, for both of which there exists a strong convention regarding identifier casing:

Later when I began to use Rust, things stayed pretty much the same:

Once I started to explore C, casing wasn’t as clear cut. C doesn’t have any official guidelines as to how you should go about naming identifiers, so every project is free to choose its own style.

As far as I can tell, the C standard library seems to stick to the following conventions:

Some examples:

• struct iovec
• clock_gettime()
• struct sockaddr_storage
• errno
• O_RDONLY
• readdir()

This opened me to the possibility of using lowercase types, something I’d never seen before. To me, lowercase types give off a vibe I can’t quite put into words: there’s some kind of low-level feeling to them, as if the types you’re defining are just plain data structures and not “objects” or “classes”. Of course, it is entirely likely that I have this association because I’ve only ever seen the style in C.

At one point I began to look through the redis source code, and took note of their casing style:

Now this was something I’d never seen before: using a different style for functions and variables. This same distinction is made in Zig:

I find this idea interesting. There’s something about camelCase which feels more “proper” to me, while snake_case feels “lower level”, all of which somehow fits to using camelCase for functions and snake_case for variables.

Next, I began watching Handmade Hero, which uses the following:

This really threw me for a loop. Capitalizing variable names, are you nuts?! After I got over the initial shock, I tried programming in this style for a bit; it took a while to get used to, especially with single-letter variable names like I and X. It was certainly an interesting experience.

As another data point, Google’s C++ code uses the following style:

Again, I kind of like the increased emphasis on functions here; especially in plain C code, there’s something special about them. They let you abstract over behavior in a way that nothing else in the language does; they provide a vital, fundamental abstraction boundary.

u/robertmeta in r/vim — 14 August 2017

[On which elements of code should be emphasized in syntax highlighting:]

I am not 100% sure on preprocessor stuff – maybe in the case it is mixed into code, else feels very separate. But functions are a very special high level thing, even having their own brace style in the linux kernel for example.

And finally, Go uses camelCase and PascalCase for everything; public identifiers get PascalCase, while private identifiers get camelCase. Using case to determine visibility on a language level is certainly an interesting choice, though I’m not sure if I agree with it.

On the whole, I’m unsure what casing style I prefer. I’m just glad to have escaped homogeneity, and to have my eyes open to all the possibilities.

Luna Razzaghipour
16 February 2023