Programming Case Style Reference
Naming conventions are one of the most debated topics in programming — and for good reason. Consistent case styles make code more readable, reduce bugs, and help teams collaborate effectively. This reference covers all major case styles: camelCase, PascalCase, snake_case, kebab-case, SCREAMING_SNAKE_CASE, and more, with guidance on when to use each one based on language conventions and context.
When You Need This Table
- Starting a new project and establishing naming conventions
- Switching between languages with different conventions
- Writing code style guides for your team
- Converting identifiers between different formats
- Understanding why a linter is flagging naming issues
| Case Style | Example | Common Usage | Languages/Contexts |
|---|---|---|---|
| camelCase | myVariableName | JavaScript/TypeScript variables, object properties | JavaScript, Java, TypeScript, C# |
| PascalCase | MyClassName | Classes, React components, types, interfaces | C#, TypeScript, Pascal, React |
| snake_case | my_variable_name | Variables, functions, database columns | Python, Ruby, Rust, SQL |
| SCREAMING_SNAKE_CASE | MAX_VALUE | Constants, environment variables | Most languages for constants |
| kebab-case | my-component-name | URLs, CSS classes, HTML attributes | HTML, CSS, URLs, Lisp |
| COBOL-CASE | MY-VARIABLE-NAME | Legacy COBOL code | COBOL |
| flatcase | myvariablename | Package names, some URLs | Java packages, Go packages |
| Train-Case | My-Variable-Name | HTTP headers | HTTP headers (Content-Type) |
Language Conventions
- JavaScript/TypeScript: camelCase for variables
- Python: snake_case for everything
- React: PascalCase for components
- CSS: kebab-case for classes
- SQL: snake_case for columns and tables
Common Patterns
- Constants: SCREAMING_SNAKE_CASE
- Private properties: _underscorePrefix
- Boolean variables: isActive, hasPermission
- Event handlers: handleClick, onSubmit
- URLs: kebab-case slugs
Why Case Conventions Matter
Consistent naming conventions aren't just about aesthetics — they prevent bugs. In JavaScript, mixing camelCase and snake_case leads to undefined properties and hard-to-track errors. In React, using lowercase for component names causes them to be treated as DOM elements instead of components.
When working with APIs, case conversion becomes critical. A JavaScript frontend using camelCase communicating with a Python backend using snake_case needs consistent transformation. Many teams use libraries like lodash's _.camelCase() and _.snakeCase() to automate this conversion.
The key principle is consistency within context. Your JavaScript variables should all be camelCase. Your Python functions should all be snake_case. Use our Case Converter tool to quickly transform text between any case style.
Best Practices for Choosing Case Styles
Selecting the right case style isn’t just about personal preference—it’s about aligning with community standards, language conventions, and team workflows. In large codebases, inconsistent naming can lead to confusion, integration errors, and longer onboarding times. For example, using kebab-case in JavaScript variables (e.g. my-variable-name) will cause syntax errors, while snake_case in React component names (e.g. my_component) violates JSX expectations and harms readability. A good strategy is to adopt the dominant convention of the language or framework you’re using: camelCase for JavaScript/TypeScript, snake_case for Python, and PascalCase for React components. When working across stacks (e.g., frontend and backend), consider establishing a mapping convention (e.g. snake_case in APIs, camelCase in frontend code) and use automated transforms (like naming convention plugins or build-time transformers) to maintain consistency without manual effort.
Common Pitfalls and How to Avoid Them
One of the most frequent issues developers face is accidentally mixing case styles within the same scope—such as using snake_case for function names in a JavaScript codebase that otherwise follows camelCase. This inconsistency not only breaks the visual rhythm of the code but can also trip up linters and automated tools that enforce naming standards. Another common mistake is overusing SCREAMING_SNAKE_CASE outside of true constants, leading to confusion about what values are truly immutable. To avoid these issues, teams should document their naming standards in a shared style guide and integrate linting tools (like ESLint, Pylint, or Stylelint) with custom rules. Pre-commit hooks (e.g., with Husky or lint-staged) can automatically catch violations before code reaches review. Additionally, when refactoring legacy code, consider using IDE-level rename refactoring with global search and replace to ensure consistency across files and dependencies.
Case Style Converters and Tools
Manually converting between case styles is error-prone—especially for long identifiers or when handling acronyms (e.g. 'API' vs 'Api' vs 'api'). TextTools includes several converters to help: the Case Converter tool can automatically transform strings between camelCase, PascalCase, snake_case, kebab-case, and more, while respecting acronyms and numbers. For developers working with APIs, the JSON Key Case Converter ensures consistent key formatting across request/response payloads. You can also batch-convert CSV columns or code snippets directly in the browser without installing additional tools. These utilities are especially useful when migrating between frameworks (e.g. from Python to Go) or integrating third-party services with differing naming conventions. To further reduce manual effort, consider integrating such converters into your editor (e.g. VS Code extensions like 'Change Case' or 'String Case') or CI pipelines for automated formatting.