Naming Conventions: camelCase, snake_case, PascalCase and kebab-case

Naming conventions are pure convention — there is no technical reason Python uses snake_case and JavaScript uses camelCase. What matters is that code which follows its ecosystem's convention is readable by everyone in it, and code that does not is a small tax on every future reader. So the useful knowledge is not which case is best but which case each context expects.

There are really only a handful of shapes, distinguished by how word boundaries are marked: a capital letter, an underscore, a hyphen, or nothing at all. The names for them are informal but widely understood, and the table below fixes the vocabulary.

One of these choices does have a consequence beyond taste. In URLs, Google has long treated a hyphen as a word separator and an underscore as a word joiner, which means `blue-widgets` reads as two words and `blue_widgets` reads as one. That makes kebab-case the correct choice for any URL slug, and it is the only item in this guide where the decision is not simply stylistic.

These are the forms in common use, with the names most developers will recognise. The last few are novelty transformations rather than conventions anyone codes in, but they turn up in tooling and in text manipulation.

Most languages have a documented style guide, and following it is the whole game. Where a language has an official one — Python's PEP 8, Rust's naming guidelines, Go's own conventions enforced by its tooling — that document wins over any personal preference, because everyone else in that ecosystem is following it.

Note how often one language uses several conventions at once, differentiated by what is being named. JavaScript uses camelCase for variables, PascalCase for classes and components, and CONSTANT_CASE for module-level constants. That is not inconsistency; the convention carries information about the kind of thing you are looking at.

Go is the interesting case because its convention is load-bearing rather than cosmetic: an identifier starting with a capital letter is exported from its package and one starting lowercase is not. There, changing the case changes the program.

Google's guidance on URL structure is explicit that hyphens are the separator to use and underscores are not recommended. The mechanism is straightforward: a hyphen is treated as a word break, so `/image-compressor` is understood as two words that can each match a query, while `/image_compressor` tends to be read as one token that matches neither well.

So URL slugs are kebab-case, lowercase, and made of real words. That is why every route on this site looks the way it does — `background-remover` rather than `bgremove`, which is also why the tool registry keeps a terse internal identifier separate from the descriptive slug a visitor and a crawler see.

Two related points. Keep slugs lowercase, because paths are case-sensitive on most servers and a mixed-case URL invites duplicate-content problems when something links to a different capitalisation. And avoid changing a live slug at all — if you must, it needs a redirect, or you discard whatever ranking the old URL had accumulated.

Outside source code, three contexts have conventions worth knowing because breaking them causes real bugs rather than stylistic complaints.

Filenames are safest in kebab-case or snake_case, lowercase. The reason is that macOS and Windows filesystems are case-insensitive by default while Linux is case-sensitive, so a project that refers to `MyComponent.tsx` as `mycomponent.tsx` somewhere works on a developer's laptop and fails in a Linux build. Spaces are worth avoiding for the same class of reason — they need quoting in every shell command that touches them.

Environment variables are CONSTANT_CASE by universal convention. This is close to a hard requirement: shells treat variable names with hyphens as invalid, and lowercase names risk colliding with shell-internal variables. Anything reading configuration from the environment should expect uppercase with underscores.

HTTP header names are conventionally Train-Case, as in `Content-Type`. In practice they are case-insensitive per the specification, and HTTP/2 requires them lowercase on the wire, so the convention is for human readability rather than correctness.

Automated case conversion works by finding word boundaries and re-marking them, and that first step is genuinely ambiguous in two situations. Knowing them prevents a surprising class of bug when converting a whole codebase or a set of database columns.

Acronyms are the main one. Converting `HTTPServer` to snake_case could reasonably give `http_server` or `h_t_t_p_server`, depending on whether consecutive capitals are treated as one word or many. Converting back gives `HttpServer`, not the original. This is why style guides for languages like Go and Swift take an explicit position on acronym casing, and why a round trip through two conversions should never be assumed safe.

Digits are the other. In `user2Id` or `oauth2Token`, whether a boundary exists before or after the digit is a judgement call, and different tools make it differently. Where identifiers mix letters and digits, check the output rather than trusting it.

The practical rule is to convert in one direction, review the result, and commit that — never convert back and forth expecting to arrive where you started.