If you have ever stared at a codebase and wondered who named that variable my_var_but_like_weird, you are not alone. Naming is less glamorous than refactoring but more useful than a thousand bike sheds. This guide walks through the sane naming conventions for Java, Python, JavaScript, Rust and Mojo with real examples and small amounts of fruity sarcasm.

Quick summary for the impatient

• Java uses camelCase for variables and methods, PascalCase for classes, and UPPER_SNAKE for constants
• Python prefers snake_case for variables and functions, PascalCase for classes, and UPPER_SNAKE for constants
• JavaScript tends to use camelCase for variables and functions, PascalCase for constructors, and UPPER_SNAKE or const style for constants
• Rust likes snake_case for variables and functions, CamelCase for types, and SHOUTY_SNAKE for constants
• Mojo follows Python style for many things, with PascalCase for structs and types

Why you should care

Consistency matters more than your clever acronyms. Consistent names make code readable, tooling predictable, and code reviews less like gladiator fights. Linters and formatters are your friends. Yes they will force you to rename your favorite variable. You survive.

Java naming rules

Java culture likes camelCase and a clear distinction between values and types. Use camelCase for variables and methods, PascalCase for class and interface names, and UPPER_SNAKE for constants. Example names that will make your teammates nod:

• myVariable for a variable
• calculateTotal for a method
• MyClass for a class
• MAX_SIZE for a constant

Python naming rules

Python leans into readability with snake_case for variables and functions. Classes use PascalCase and constants use UPPER_SNAKE. PEP 8 exists for a reason. Follow it unless you enjoy arguing in pull requests.

• my_variable for a variable or function
• MyClass for a class
• MAX_SIZE for a constant

JavaScript naming rules

JavaScript is pragmatic. Most code uses camelCase for variables and functions, PascalCase for constructor functions and types, and constants either UPPER_SNAKE or just const names in camelCase depending on team taste. Be consistent within the project so your public API does not look indecisive.

• myVariable for variables
• createElement for functions
• MyComponent for a constructor or component
• MAX_SIZE or defaultTimeout for constants depending on style

Rust naming rules

Rust has strong opinions and they make sense. Use snake_case for variables and functions, CamelCase for types, and SHOUTY_SNAKE for constants. The compiler is strict and the community expects readable names.

• my_variable for a variable
• do_work for a function
• MyType for a struct or enum
• MAX_SIZE for a constant

Mojo naming rules

Mojo follows Python style in many places. Use snake_case for functions and variables, PascalCase for structs and types, and UPPER_SNAKE for constants. If you work with Python and Mojo side by side you get the blessed bonus of fewer naming fights.

• my_variable for variables and functions
• MyStruct for structs and types
• MAX_SIZE for constants

Practical tips that stop flame wars

• Pick the convention that matches the language and the repo, and stick with it
• Use meaningful names. x is OK in tiny loops, not in business logic
• Enable a linter and a formatter and add a precommit check to enforce rules automatically
• When exposing public APIs think about the consumers in other languages and pick names that play well with bindings and tooling
• Avoid cryptic abbreviations that require archeology to decode

Interoperability and migration

When you bridge languages remember that naming expectations impact users. A JavaScript API exposed to Python users should consider snake_case wrappers or clear docs. Bindings and code generation often assume certain casing so pick names that survive translation.

Final words

Names are cheap and valuable. Be boringly consistent and mercilessly clear. Your future self and your team will thank you, and code reviews will spend less time arguing about capitalization and more time fixing real problems.