I feel like I’ll never understand why isn’t snake_case the de facto way of naming things in high-level programming languages. I didn’t really research what made camelCase popular in the first place, but I believe it’s just a matter of some historical reasons that somehow brought us into this mess, much like the qwerty keyboard layout.
We are used to change the casing style when moving from one language to another in order to fit the language’s conventions, which is a form of standardizing things inside that language, but by doing so we are increasing friction when we already have to worry about other language speficities. Have you ever write a sql query that has a bunch of column renaming to convert the camel_case database columns into camelCase names just because the language you’re working in enforces this style? Yeah, me too.
One might say it’s a negligible cost, but I’d argue that defining a standard among all languages would be beneficial for every part involved in the process of writing and reading source code, from programmers to tooling.
The reasoning behind going with camel_case is simple: our native language separator is a space character, which is mimicked by the underscore, thus satisfying our natural reading/writing way better than camelCase. The only downside is that we’re introducing more characters to our names, making them longer, but since very long names don’t represent a big portion of common code it seems like a good trade-off.
That being said, I’ll try to enforce camel_case style in all my personal projects for now on, unless I discover something I don’t currently know. I may also update this article in the future to present my findings through this experience. I forsee issues like using linters, formatters, code generation and some other tools, but let’s see how it goes.