1.13.f — Naming Conventions & Clean Code

In one sentence: Good names and small, clear programs reduce bugs — JavaScript’s dominant style is camelCase for variables and functions, PascalCase for constructors/classes, and SCREAMING_SNAKE_CASE for true constants.

Navigation: ← 1.13.e — Variables · 1.13.g — Data Types →

---

1. Identifiers: what you can name

Rules (simplified):

• Start with letter, _, or $ (not a digit).
• After that: letters, digits, _, $.
• Reserved words (if, class, return, …) cannot be variable names.

Use ASCII letters for public learning code; teams may allow Unicode identifiers — be consistent with your style guide.

---

2. camelCase (default for variables & functions)

const firstName = "Grace";
function calculateTotal() {
  return 0;
}

camelCase — first word lowercase, later words capitalized. This is the de facto standard in browser APIs and most JS codebases.

---

3. PascalCase (constructors / classes / React components)

class UserAccount {}

Use PascalCase when the name represents a type or component that you construct with new or treat as a “thing with a capital letter” in frameworks.

---

4. SCREAMING_SNAKE_CASE (fixed configuration)

const API_BASE_URL = "https://api.example.com";
const MAX_UPLOAD_MB = 10;

Signals “treat as immutable configuration” — still const, but the name shouts do not tweak casually.

---

5. Clean code practices (beginner level)

Practice	Why
Avoid x, tmp, data2 unless scope is tiny	Names should answer what and sometimes why
One purpose per variable	priceWithTax beats reusing price for three meanings
Keep functions short	Easier to test and read — extract when a block does two jobs
Prefer early returns in if chains	Flattens nesting
Comments explain “why,” not “what”	i++ does not need a comment; non-obvious business rules do

---

6. Naming booleans

Prefix with is, has, should, can:

const isLoggedIn = true;
const hasDiscount = false;

---

7. Key takeaways

1. camelCase for most bindings; PascalCase for classes/components; SCREAMING_SNAKE_CASE for config-like constants.
2. Names are documentation — invest a few seconds to avoid hours of confusion.
3. Clean code at this stage means: clarity, small steps, meaningful names, and honest comments.

---

Explain-It Challenge

Explain without notes:

1. When would you choose PascalCase over camelCase?
2. Why is const d = 86400000 a weaker name than const MILLISECONDS_PER_DAY = 86400000?
3. What is wrong with a comment that says // increment i by 1 above i++?

---

Navigation: ← 1.13.e — Variables · 1.13.g — Data Types →