What naming conventions tell you about a codebase's intent

Names Are the First Documentation

Experienced developers encode intent into names. Learning to read naming conventions lets you predict what code does before reading a single line of its body.

Prefix Patterns and What They Mean

// Boolean state: is/has/can/should prefixes
const isLoading = true;
const hasPermission = checkAccess(user);
const canEdit = user.role === 'admin';

// Data access: get = read, set = write, fetch = async read
function getUsername(user) { return user.name; }     // sync, no side effects
async function fetchUserProfile(id) { ... }           // network call
function setActiveUser(user) { state.active = user; } // mutation

// Constants: ALL_CAPS signals immutable config values
const MAX_RETRY_ATTEMPTS = 3;
const API_BASE_URL = 'https://api.example.com';

// Private by convention: leading underscore
class AuthService {
  _tokenCache = new Map(); // internal, don't access from outside
  validateToken(token) { ... } // public API
}

When Naming Lies

Naming conventions are promises. When a function named getUser also sends an analytics event, that's a broken promise — a sign of code that evolved without refactoring. When you spot a mismatch between a name and behavior, flag it. These are the spots most likely to contain bugs or cause confusion for the next developer.