Why naming conventions matter
Every programming language ecosystem has settled on naming conventions over decades of practice. Python uses snake_case. JavaScript uses camelCase. CSS uses kebab-case. SQL columns use snake_case. These conventions aren't arbitrary — each emerged because the alternative caused real friction with the syntax, tooling, or established libraries of that language.
Following the convention of your language matters more than picking the "best" convention in the abstract. Code that uses camelCase variable names in a Python codebase will pass syntax checks but fail every linter, look wrong to every reviewer, and create cognitive friction every time someone reads it. Convention is a coordination mechanism — its value comes from everyone following the same one.
The eight conventions covered here
This page links to detailed write-ups of the eight conventions that cover roughly 95% of programming naming needs:
- camelCase — variables, methods, parameters in JavaScript, Java, Swift, C#, and most C-family and JVM languages.
- PascalCase — class names, type names, React components, .NET public members, Go exported identifiers.
- snake_case — Python, Ruby, Rust variables and functions; SQL column names; YAML keys.
- kebab-case — CSS classes, HTML attributes, URL paths, CLI flags, Lisp-family identifiers.
- CONSTANT_CASE — environment variables, compile-time constants, C macros, top-level configuration values.
- dot.case — i18n translation keys, configuration namespaces, Java packages, structured logging fields.
- path/case — URL routes, REST endpoints, file paths, S3 keys, container image names.
- URL slugs — the hyphenated, lowercased, ASCII-only URLs that search engines and humans both prefer.
Tokenization is the hard part
Converting between case formats isn't difficult once you have correctly-identified tokens. The difficulty is identifying the tokens in the first place. parseXMLHttpRequest contains four tokens: parse, XML, Http, Request. A naive case converter that splits on every uppercase letter produces five tokens and mangles the acronym.
Our converter recognizes ALLCAPS acronym runs, numeric suffixes, brand-name exceptions (iPhone, eBay), and existing case boundaries. The same engine powers every page on this site — convert parseXMLHttpRequest to snake_case and you get parse_xml_http_request; convert it to kebab-case and you get parse-xml-http-request; convert it to CONSTANT_CASE and you get PARSE_XML_HTTP_REQUEST. The tokenization stays consistent across all output formats.
This matters because real-world inputs are messy. You're usually not converting clean three-word phrases — you're converting existing identifiers from one convention to another. Bad tokenization means a function called getHTMLContent ends up as get_h_t_m_l_content instead of the correct get_html_content. The acronym detection isn't optional.
Choosing between conventions
For new code, follow your language's standard. Python: snake_case. JavaScript: camelCase. CSS: kebab-case. Rust: snake_case for functions, PascalCase for types. The choice is made for you; just match it.
For new conventions in a polyglot codebase — say, JSON keys that flow between a Python backend and a JavaScript frontend — pick one and apply it everywhere. snake_case is the more common choice for JSON APIs because case-folding is less destructive than camelCase boundary detection. But camelCase is fine too if your team prefers it. What matters is consistency.
For identifiers that don't have a strong language convention — file names, directory structure, branch names in version control — kebab-case is the conservative default. It works everywhere, plays nicely with shells, and matches URL conventions.