Code style debates can get heated. Tabs vs. spaces, curly braces on the same line or next line, and of course, how to name variables. For years, our team followed the traditional CamelCase convention. It was familiar, widely used, and came with the aura of being professional and standard.

But over time, we noticed that CamelCase is not always the most readable, especially in data projects where table names, column names, and long descriptive identifiers are common. That is when we made a conscious switch to lower snake_case.

Why lower snake_case felt more natural

Readability first

When identifiers get long (and they often do in data projects), orderItemProcessedDate is harder to scan than order_item_processed_date. The underscores break the words into clear chunks, like spaces do in regular text.

No need for abbreviations

In CamelCase, long names often encourage shortcuts: ordItmProcDt. With snake case, there are less pressure to cram words together, so you can write it out in full: order_item_processed_date. Full words beat cryptic abbreviations every time.

Consistency across systems

Many databases, APIs, and configuration files already favour lowercase naming. Using lower_snake_case across the board avoids odd clashes where some systems downcase names automatically, or where mixed-case identifiers require quoting.

Easier on the eyes

When scanning large codebases or schemas, underscores pop visually in a way that capital letters do not. They give the eye natural breaks, which makes it easier to spot what you are looking for.

Its a preference, not a rule

We are not claiming lower_snake_case is universally better. Plenty of teams thrive on CamelCase, and thats fine. Style is about team productivity, not dogma. What matters is:

• The convention is consistent.
• Everyone can read and write code comfortably.
• The style reduces rather than adds to cognitive load.

For us, lower_snake_case ticked those boxes.

Closing thoughts

Changing naming conventions isnt about being trendy or contrarian. Its about asking: does this make life easier for the people writing and reading code every day?

For our team, the answer was yes. Lower snake_case gave us readable, descriptive, and consistent identifiers. It reduced the urge for abbreviations, made schemas easier to scan, and aligned better with the systems we work with.

Ultimately, it’s not about right or wrong - it’s about what works best for our team.