Discover Case Styles or Naming Conventions in Software

Naming conventions and case styles might seem like small details, but they shape how readable and maintainable code feels across an entire project. By choosing a clear way to write multi-word identifiers —whether that is camelCase, PascalCase, snake_case, SCREAMING_SNAKE_CASE, or kebab-case— you give every variable, function, method, class, and constant a consistent visual identity that developers can recognize at a glance.

Different languages and ecosystems favor different patterns, so the goal is not to find a single “perfect” style but to understand the common options and apply the ones that fit your language and team consistently. In this post, the focus is on what these styles look like, where they are typically used, and why a shared set of naming rules is such an important part of writing clean, collaborative code.

What are case styles?

Naming conventions (or case styles) define how multi‑word identifiers are written: whether words are separated by underscores or dashes, and which letters are capitalized.​

In this context, an identifier is simply the name you give to something in code, such as a variable, function, class, method, constant, or module. When talking about “multi-word identifiers,” it means those names are made from more than one word glued together because most languages do not allow spaces in identifiers, for example firstName, total_price_with_tax, or MainViewController.

The main goal is readability and consistency so developers can quickly recognize the role of an identifier (for example, variables vs classes).

Most common styles

Across many languages and style guides, the most widely used case styles are:​

• camelCase (lower camel case)
• PascalCase (UpperCamelCase)
• snake_case
• SCREAMING_SNAKE_CASE (for constants, a variant of snake case)
• kebab-case (very common in URLs, CSS classes, and file names on the web)

The most popular ones are camelCase, PascalCase, and snake_case, although there are many used widely used.

camelCase and PascalCase rely on capitalization of the first letter in each word to make multi-word identifiers easily readable, whereas snake_case, SCREAMING_SNAKE_CASE, and kebab-case rely on underscores or hyphens to separate words.

camelCase

• Definition: In camelCase, the first word starts with a lowercase letter, and each subsequent word starts with an uppercase letter; there are no spaces or separators. Example: firstName, totalPriceWithTax.​
• Typical usage:
  • Variables and functions in languages like Java, JavaScript, TypeScript, and often Python and C#.​
  • Object properties and method names in many C‑style languages.​

Here are a couple of examples of the camelCase case style usage:

// In JavaScript
let firstName = "Ada";
let lastName = "Lovelace";

function calculateTotalPrice(orderItems) {
  // ...
}

// In JavaScript
let firstName = "Ada";
let lastName = "Lovelace";

function calculateTotalPrice(orderItems) {
  // ...
}

// In Java
int maxRetries = 3;

boolean isValidUser(String userName) {
    // ...
}

// In Java
int maxRetries = 3;

boolean isValidUser(String userName) {
    // ...
}

PascalCase

• Definition: In PascalCase (also called UpperCamelCase), every word, including the first, starts with an uppercase letter; no separators. Examples: UserService, MainViewController.​
• Typical usage:
  • Class, interface, and enum names in languages like C#, Java, C++, and TypeScript.​
  • Component names in frameworks like React and Vue, and exported types in some languages

Example snippets:

// In C#
public class UserService {
    public void createUser(string firstName, string lastName) {
        // ...
    }
}

// In C#
public class UserService {
    public void createUser(string firstName, string lastName) {
        // ...
    }
}

// In TypeScript
class MainViewController {
  startApp(): void {
    // ...
  }
}

// In TypeScript
class MainViewController {
  startApp(): void {
    // ...
  }
}

The naming convention for camelCase and PascalCase share the same idea, but PascalCase capitalizes the very first letter too.

snake_case and SCREAMING_SNAKE_CASE

• Definition (snake_case): All letters are usually lowercase, with words separated by underscores. Example: user_name, total_price_with_tax.​
• Definition (SCREAMING_SNAKE_CASE): Same as snake_case, but all letters are uppercase, often used for constants. Example: MAX_CONNECTIONS, DEFAULT_TIMEOUT_SECONDS.​
• Typical usage:
  • Variables and functions in Python and Ruby (my_variable, process_data).​
  • Constants and environment variables in many languages using SCREAMING_SNAKE_CASE.

Example snippets:

# In Python
MAX_CONNECTIONS = 10
DEFAULT_TIMEOUT_SECONDS = 30
user_name = "ada_lovelace"
total_price_with_tax = calculate_total(price, tax_rate)

# In Python
MAX_CONNECTIONS = 10
DEFAULT_TIMEOUT_SECONDS = 30
user_name = "ada_lovelace"
total_price_with_tax = calculate_total(price, tax_rate)

The underscores in the snake_case and SCREAMING_SNAKE_CASE naming conventions provide a very clear visual separation, which is why snake_case is popular in Python’s official style guide.

kebab-case

• Definition: All letters are typically lowercase and words are separated by hyphens: main-content, user-profile-page.​
• Typical usage:
  • URLs, file names, and CSS class names in web development.​

Example snippet in CSS:

.main-content {
  padding: 2rem;
}

.user-profile-card {
  border-radius: 8px;
}

.main-content {
  padding: 2rem;
}

.user-profile-card {
  border-radius: 8px;
}

Summary table: case styles or naming convetions

Conclusion

Consistent naming conventions and case styles are a quiet but powerful foundation for readable code. They make it easier for anyone on the team to scan a file and instantly recognize what is a class, what is a function, and what is a constant, without stopping to decipher each name.

There is no single “best” style because different languages and ecosystems have evolved their own norms, and those norms are often encoded in official style guides, formatters, linters, and frameworks. What matters most is choosing the conventions that fit the language and project, documenting them, and applying them consistently so the codebase feels like it was written by one coherent mind. This shared discipline reduces bugs caused by misunderstandings, speeds up onboarding for new developers, and lets everyone focus more on solving problems than on arguing about where to put capital letters