Naming Conventions in Programming Languages: A Practical Overview

Why naming conventions exist

The compiler does not care whether you write userName, user_name or UserName. People care. A naming convention tells a reader at a glance whether a name refers to a variable, a function, a class or a constant, and it removes arguments about style from code reviews. In large projects, the convention is usually written down in a style guide and checked by a tool called a linter.

Conventions differ between languages, and a few of them are not conventions at all, because the language itself gives meaning to the case. In Go, a name that starts with a capital letter is exported from its package, and a name that starts with a lowercase letter is private to it. In Python, a leading underscore marks a name as internal by convention.

Python: PEP 8

Python's style guide, PEP 8, recommends lowercase names with words separated by underscores for functions, variables and methods. Class names use CapWords, which is another name for PascalCase. Constants are written in capital letters with underscores. Modules should have short, lowercase names, and packages should use lowercase names without underscores if possible.

Python follows these rules in its standard library, with a few historical exceptions. A name with a single leading underscore is meant for internal use, and names with two leading underscores trigger name mangling inside classes. Most Python teams enforce PEP 8 with a tool such as flake8, pycodestyle or Ruff, so deviations are flagged automatically.

JavaScript and TypeScript

JavaScript uses camelCase for variables, functions and object properties, PascalCase for classes and constructors, and capital letters with underscores for constants that are truly fixed. TypeScript adds PascalCase for interfaces, type aliases and enums. In React, the name of a component must start with a capital letter, otherwise the compiler treats it as an HTML element.

The built-in objects Math and JSON are capitalized because they act like namespaces, not like ordinary variables. Style guides such as Google's JavaScript guide and the Airbnb guide describe the usual practice in detail, and tools such as ESLint can enforce it.

Java, C# and Kotlin

Java uses camelCase for methods and variables, PascalCase for classes and interfaces, lowercase names without separators for packages, and capital letters with underscores for constants. These rules are laid down in the Java code conventions and have been followed for decades. Kotlin uses almost the same rules, and Android developers follow them too.

C# differs in one way: methods, properties and public fields use PascalCase, while parameters and local variables use camelCase. Interfaces start with a capital I, as in IDisposable, which is a convention carried over from older Microsoft practice. In both languages, the case of the first letter tells the reader what kind of name it is.

Rust, Go and Swift

Rust enforces its style with compiler warnings. Functions, variables and modules use snake_case, types and traits use UpperCamelCase, and constants and statics use SCREAMING_SNAKE_CASE. If you break the pattern, the compiler suggests the right form. The tool rustfmt formats the code, and clippy checks for further style problems.

Go uses MixedCaps, which is the Go name for PascalCase and camelCase, and avoids underscores in names. The case of the first letter controls visibility, so ExportedName is public and unexportedName is private. Swift uses camelCase for functions, properties and variables, and PascalCase for types and protocols, and its API design guidelines ask for names that read like English sentences at the call site.

CSS, HTML, SQL and files

CSS class names and custom properties use kebab-case in most projects, because hyphens are allowed in CSS identifiers. HTML attribute names are written in lowercase, and custom data attributes follow the data- prefix with lowercase words separated by hyphens. SQL keywords are traditionally written in capital letters, while table and column names usually use snake_case, although this is a convention and not a rule.

File names deserve their own rule. Because Windows and macOS file systems are usually case-insensitive and Linux file systems are case-sensitive, a project that is developed on one and run on another can fail on a difference such as Logo.png and logo.png. Using lowercase kebab-case or snake_case for all file names avoids that problem.

Applying conventions with tools

Do not rely on memory: use a linter and a formatter. Tools such as ESLint, Ruff, Checkstyle, rustfmt and gofmt check names or formatting automatically, and many of them can fix problems. For one-off tasks, such as turning a list of column names from a spreadsheet into identifiers, the converter on this page can switch a list between camelCase, PascalCase, snake_case, kebab-case and CONSTANT_CASE.

When you join an existing project, follow its conventions even if you prefer another style. A consistent codebase in a style you dislike is easier to work with than a mixture of styles that you do like. If you start a new project, adopt the style guide of the language community, write it down in the README and let a tool enforce it.