Naming & Readability

Easy

In plain terms

Variables, functions, and classes should have names that say what they are or what they do. count instead of c, getUserById instead of get. Avoid abbreviations unless they are universal (id, url).

Readable code is easier to debug and change. Use consistent naming (e.g. camelCase for variables, PascalCase for classes). Boolean names often start with is, has, or can. Long names are fine if they are clear. "The code should read like well-written prose" is a good goal.

What you need to know

•Names reveal intent
•Avoid abbreviations (unless standard)
•Consistent style

Example

Code is language-agnostic in spirit; adapt the idea to your language:

// Clear names
const isLoggedIn = true;
const userCount = 0;
function calculateTotalPrice(items) { /* ... */ }

// Avoid
const x = true;
const n = 0;
function calc(i) { /* ... */ }

Why this matters

Readable code is a sign of professionalism. Interviewers may ask about naming conventions, code review criteria, or how you make code self-documenting.

How it connects

Good names reduce the need for comments and make SRP and intent obvious. In OOP, class and method names should reveal purpose; in SOLID, interface names (IEmailService) document the contract.

Interview focus

Be ready to explain these; they come up often.

▸Names should reveal intent; avoid abbreviations except standard ones (id, url).
▸Booleans: is/has/can prefix; functions: verb + noun (getUserById, calculateTotal).
▸"Code is read more than written"; optimize for readability.

Learn more

Dive deeper with these resources:

W3Schools