Identifiers

In short: The names given to variables, methods, classes, etc. in code — have to follow certain rules (no spaces, can’t start with a digit, no reserved keywords).

In more detail: Every language has its own rules for what counts as a valid identifier (usually: letters, digits, underscore, not starting with a digit) and its own naming conventions, which aren’t enforced but are standard (e.g. camelCase for variables in Java/JavaScript, PascalCase for class names).

In Depth

The formal rules are usually minimal (no spaces, can’t start with a digit, no reserved keywords like class or if as a name), but good code lives on the unwritten conventions beyond that: meaningful instead of cryptic names (customerList instead of cl), consistency within a project, and language-specific capitalisation styles:

int age;                 // camelCase - variables/methods in Java
class CustomerManagement { // PascalCase - classes in Java
}
final int MAX_ATTEMPTS = 3; // SCREAMING_SNAKE_CASE - constants

Some languages even enforce conventions at the compiler level: in Go, the capitalisation of the first letter decides visibility (public vs. package-internal); in Python, a leading underscore signals “private” by convention, without being technically enforced. Poor identifier choice is one of the most common reasons someone else’s (or your own, older) code is hard to understand — ideally the name should already explain what the variable stands for, without needing a comment.

Reserved keywords

Every language has a fixed list of reserved words that MAY NOT be used as identifiers, because they already have a fixed meaning in the language’s syntax (if, for, class, return, etc.). If you try to name a variable class anyway, the compiler aborts with a syntax error. Some languages allow escaping for special cases — in Kotlin, for example, a keyword can be used as an identifier with backticks (`class`), which is occasionally necessary when interoperating with Java libraries that use a name allowed there but reserved in Kotlin.

Naming conventions compared across languages

The specific conventions differ noticeably between ecosystems: Python and Ruby prefer snake_case (customer_list) for variables and functions, Java/JavaScript/C# camelCase (customerList), while constants in almost all C-like languages traditionally get SCREAMING_SNAKE_CASE. These conventions aren’t arbitrary, but have historically become established in the respective language communities, and are today usually enforced by automated linters (ESLint, Checkstyle, Pylint), so a team doesn’t have to rely on manual code reviews for simple style questions.

Avoiding namespace collisions

In larger projects with many developers, the uniqueness of identifiers becomes its own problem: two independently developed libraries could both define a class User. Languages solve this via namespaces (namespaces in C++/C#, packages in Java, modules in Python/JavaScript) — the full, unambiguous identifier then becomes something like com.company.User or auth.User, while local code usually just uses the short name, as long as there’s no ambiguity.

See also: Declaring Variables, Constants (final)