I still remember the first production bug I shipped as a junior developer: a checkout page that sometimes charged $0. The root cause wasn’t a missing API call or a broken database. It was a simple condition that silently evaluated to false because I trusted a value to be numeric and it was actually a string. Conditional statements look deceptively simple, yet they are the backbone of every decision your application makes. In my day-to-day work, almost every feature I build—permissions, feature flags, input validation, error handling—boils down to conditions that must behave exactly as intended.
If you write JavaScript for any meaningful system, you are designing decision logic. That means you need more than syntax; you need a reliable mental model of truthy and falsy values, you need patterns that keep logic readable, and you need guardrails for the edge cases that quietly derail production. I’ll walk you through the core statement types, explain the subtle semantics I wish I had learned earlier, and share practical patterns I use in modern codebases. By the end, you should be able to choose the right conditional structure for each situation and confidently handle the tricky parts.
How JavaScript evaluates conditions
Every conditional statement relies on the same engine: a condition is coerced to a boolean. JavaScript has two real boolean values—true and false—but many other values can act like them in conditions. This is where things get slippery.
Here is my rule of thumb: if a value is “empty,” it usually behaves as false. That includes false, 0, -0, 0n, ‘‘ (empty string), null, undefined, and NaN. Everything else is truthy, including ‘0‘, ‘false‘, empty arrays [], and empty objects {}. That last bit trips people up constantly.
I like to think of conditions as a bouncer at a door: they don’t check your whole backstory, they just ask, “Do you look like true?” If you look truthy, you get in. If not, you’re out. That mental model helps me predict behavior quickly.
Another essential piece: comparison and logical operators create the conditions you test. === checks value and type, !== does the opposite, and the relational operators (>, <, >=, <=) are straightforward as long as you compare values of the same type. Logical operators (&&, ||, !) are not just booleans; they return one of their operands. I use this fact for concise defaults, but I keep it readable by avoiding deep chains.
Finally, remember short-circuiting: A && B won’t evaluate B if A is falsy, and A || B won’t evaluate B if A is truthy. Short-circuiting is a powerful tool for safe access and efficient checks, yet it can hide side effects if you are not intentional.
The basic if statement: the cleanest gate you have
The if statement is a single gate. It runs a block only when the condition is truthy. I use it for guard conditions and early exits because it reads like plain English.
const cartTotal = 42;
if (cartTotal === 0) {
console.log(‘Cart is empty‘);
}
That’s clear, and it scales well for simple decisions. In production code, I often use if to block invalid states quickly so the rest of the function stays clean.
function submitOrder(order) {
if (!order) {
throw new Error(‘Order is required‘);
}
// Safe to proceed
processPayment(order);
notifyWarehouse(order);
}
Notice the guard style: I check for the problem first, then proceed. This approach reduces nesting, lowers cognitive load, and keeps the happy path visible.
When to use a plain if
- You need to block an invalid case early.
- You are checking a single condition without alternatives.
- You want a readable precondition at the top of a function.
When not to use it
If you are selecting among multiple branches, a single if followed by more if statements can be ambiguous. In that case, you should use if...else if...else or switch to make the mutually exclusive intent explicit.
if…else: a clear fork in the road
The if...else statement guarantees that exactly one of two paths runs. I use it when a decision is binary, such as access allowed vs denied, or UI visible vs hidden.
const isAuthenticated = session.user !== null;
if (isAuthenticated) {
console.log(‘Show account dashboard‘);
} else {
console.log(‘Show sign-in screen‘);
}
When your condition reads clearly, this is as maintainable as it gets. I recommend keeping the condition simple and moving complex logic into a well-named helper function.
function canEditPost(user, post) {
return user.role === ‘admin‘ || user.id === post.authorId;
}
if (canEditPost(user, post)) {
enableEditor();
} else {
showReadOnlyView();
}
I prefer that structure because it makes the intent obvious. The condition is a question, and the two blocks are the answers.
else if ladders: multiple paths, one winner
The else if ladder is a sequence of checks that run from top to bottom. The first true condition wins, and the rest are skipped. That means order matters a lot.
const score = 87;
let grade;
if (score >= 90) {
grade = ‘A‘;
} else if (score >= 80) {
grade = ‘B‘;
} else if (score >= 70) {
grade = ‘C‘;
} else {
grade = ‘D‘;
}
console.log(grade);
I place the most specific conditions first and work toward the most general. If I reverse the order, the first condition might swallow everything.
Guard clause alternative
If the logic is about early exits rather than a single selected value, I use guard clauses instead of a long ladder. It often reads better:
function classifyTemperature(tempC) {
if (tempC >= 35) return ‘hot‘;
if (tempC >= 25) return ‘warm‘;
if (tempC >= 15) return ‘mild‘;
return ‘cool‘;
}
This still uses multiple if statements, yet it’s explicit and avoids large nesting. I reach for this style when I’m transforming values rather than branching into multi-line blocks.
switch statements: a map of explicit cases
A switch statement is ideal when one variable is compared against multiple fixed values. It is more readable than a long else if chain for discrete values, especially with strings or enums.
const status = ‘shipped‘;
let label;
switch (status) {
case ‘pending‘:
label = ‘Waiting for payment‘;
break;
case ‘processing‘:
label = ‘Preparing your order‘;
break;
case ‘shipped‘:
label = ‘On the way‘;
break;
case ‘delivered‘:
label = ‘Delivered‘;
break;
default:
label = ‘Unknown status‘;
}
console.log(label);
I always include break unless I explicitly want fall-through. Missing break is one of those classic bugs that still shows up in real codebases.
The switch(true) pattern
Sometimes you want switch semantics with ranges. You can switch(true) and write each case as a condition. It reads better than a long ladder when you want a structured block.
const latencyMs = 120;
let health;
switch (true) {
case latencyMs < 50:
health = ‘excellent‘;
break;
case latencyMs < 100:
health = ‘good‘;
break;
case latencyMs < 200:
health = ‘fair‘;
break;
default:
health = ‘poor‘;
}
console.log(health);
I use this sparingly because some developers are not familiar with it. When clarity for the team is the priority, I stick to an else if ladder.
Switch vs object lookup
A modern alternative is mapping values to handlers in an object. I reach for it when each case simply maps to a result or a function call.
const actions = {
add: () => console.log(‘Add item‘),
remove: () => console.log(‘Remove item‘),
clear: () => console.log(‘Clear cart‘)
};
const command = ‘remove‘;
(actions[command] || (() => console.log(‘Unknown command‘)))();
This avoids switch entirely and scales cleanly, especially in functional code. It also makes it easier to test because the map is data rather than control flow.
The ternary operator: concise when disciplined
The ternary operator is shorthand for if...else in an expression context. It is powerful, but it can turn into a readability hazard if you nest it or use it for complex logic.
const isPro = user.plan === ‘pro‘;
const badge = isPro ? ‘Pro Member‘ : ‘Free Member‘;
That is exactly the kind of usage I endorse: a short condition and simple expressions. When the expressions get long, I return to if...else or extract a function. Clarity beats cleverness.
Nested ternary: rarely worth it
I only use nested ternary expressions when the result is simple and the logic is obvious at a glance. Here’s a case that is still acceptable:
const score = 72;
const rating = score >= 90 ? ‘excellent‘ : score >= 75 ? ‘good‘ : ‘needs work‘;
If I can’t read it in a single pass, I switch to a ladder or a map. My litmus test is: if I need parentheses to make the intent clear, it’s not a good ternary.
Nested if…else: handle with care
Nested conditions are unavoidable in some workflows, such as multi-step validations or decision trees. I use them, but I keep nesting shallow by extracting helper functions.
function shippingMessage(country, isExpress) {
if (country === ‘US‘) {
if (isExpress) {
return ‘Express shipping: 1-2 days‘;
}
return ‘Standard shipping: 3-5 days‘;
}
if (country === ‘CA‘) {
return ‘International shipping: 5-10 days‘;
}
return ‘Please contact support for shipping options‘;
}
This is readable because each nested level is short and related. If the nested structure grows beyond two levels, I refactor.
A refactor strategy I use
- Identify repeated checks.
- Move a related cluster into a function.
- Use guard clauses to exit early.
Here is a refactor of a more complex validation flow:
function validateOrder(order) {
if (!order) return { ok: false, reason: ‘Order missing‘ };
if (!order.items?.length) return { ok: false, reason: ‘No items‘ };
if (!order.customer?.email) return { ok: false, reason: ‘Email required‘ };
if (order.total <= 0) return { ok: false, reason: 'Invalid total' };
return { ok: true };
}
The logic is still conditional, but it is now linear and easy to scan.
Real-world scenarios where conditions do the heavy lifting
Form validation
Form validation is a classic case of layered conditions. You check for presence, format, and business rules, in that order. I favor small, explicit checks rather than a single mega-condition.
function validateProfile(profile) {
const errors = [];
if (!profile.name) errors.push(‘Name is required‘);
if (!profile.email) errors.push(‘Email is required‘);
if (profile.email && !profile.email.includes(‘@‘)) {
errors.push(‘Email format is invalid‘);
}
if (profile.age !== undefined && profile.age < 13) {
errors.push(‘Minimum age is 13‘);
}
return errors;
}
Notice how each condition reads like a rule. That makes the logic easy to explain to a teammate or a product manager.
Feature flags and experiments
Modern apps are full of feature flags and A/B tests. I keep the condition logic centralized so that rollout rules are consistent.
function canUseNewCheckout(user, flags) {
if (!flags.newCheckout) return false;
if (user.isInternal) return true;
return user.region === ‘US‘ && user.plan !== ‘basic‘;
}
Then I use it in the UI layer:
if (canUseNewCheckout(user, flags)) {
renderNewCheckout();
} else {
renderLegacyCheckout();
}
Error handling in async code
With async workflows, I use conditions to decide whether to retry, fall back, or surface an error immediately.
async function loadUserProfile(api, userId) {
try {
const profile = await api.fetchProfile(userId);
return profile;
} catch (err) {
if (err.code === ‘NOT_FOUND‘) return null;
if (err.code === ‘RATE_LIMIT‘) {
await wait(1000);
return api.fetchProfile(userId);
}
throw err;
}
}
This pattern keeps error handling explicit and ensures your app behaves predictably under stress.
Common mistakes and how I avoid them
1. Using == instead of ===
Loose equality performs type coercion, which can hide bugs. For example:
‘0‘ == 0 // true
‘0‘ === 0 // false
I stick to === and !== almost everywhere. The only time I consider == is when I intentionally want null and undefined to be treated the same, and even then I comment it to avoid confusion.
2. Assuming empty arrays or objects are falsy
[] and {} are truthy, always. If you need to check for emptiness, do it explicitly:
if (items.length === 0) {
console.log(‘No items‘);
}
3. Treating NaN as a normal number
NaN is weird: it is not equal to itself. I use Number.isNaN(value) when I need to check it.
const value = Number.parseFloat(input);
if (Number.isNaN(value)) {
console.log(‘Invalid number‘);
}
4. Assignment inside a condition
This is a classic slip: using = instead of ===. Some linters catch it, but I still see it in legacy code.
// Bad: assigns instead of compares
if (status = ‘active‘) {
// ...
}
Use strict equality, and let your editor highlight assignments in conditions.
5. Operator precedence surprises
&& binds tighter than ||. If your condition combines them, use parentheses. I do this even when I know the precedence, because it improves clarity.
const canView = isAdmin || (isOwner && isPublished);
When to use each statement type
I often teach this with a quick decision chart. It saves time during reviews and helps teams align on style.
- if: one simple gate, no alternatives.
- if…else: a clean binary choice.
- else if ladder: multiple ordered conditions, one winner.
- switch: discrete values mapped to actions.
- ternary: short expression with two outcomes.
Traditional vs modern pattern choices
Here is how I compare older habits with modern, readability-first approaches:
Modern preference
—
Guard clauses + early return
switch or object map
Named helper function
Precomputed booleans
These choices are not about style for style’s sake. They reduce the risk of logic errors and make code easier to maintain.
Performance considerations without hand-waving
Most conditional statements are effectively instant, yet performance can matter in hot paths. In UI code, conditions usually cost microseconds, so readability wins. In tight loops, conditions can add measurable overhead if they cause branch misprediction or repeated expensive checks.
Here’s the rule I follow: optimize conditional logic only when you can prove it matters. The best way to prove it is to measure a real workload, not a micro-benchmark that doesn’t resemble production.
Example: precompute outside a loop
// Less ideal: repeated check inside the loop
for (const item of items) {
if (user.plan === ‘enterprise‘) {
processEnterprise(item);
} else {
processStandard(item);
}
}
// Better: precompute the handler once
const handler = user.plan === ‘enterprise‘ ? processEnterprise : processStandard;
for (const item of items) {
handler(item);
}
This isn’t about cleverness; it reduces repeated checks and makes your intent clear. In big lists or complex handlers, it can be a small but measurable win.
Example: collapse repeated work
// Repeated condition
if (isConnected && hasToken && isAllowed) {
startSession();
}
// If these checks are reused, bundle once
const canStart = isConnected && hasToken && isAllowed;
if (canStart) startSession();
In practice, I do this when the check appears multiple times or is complex enough to deserve a name.
Ranges, not fake precision
When you hear claims like “this is 2x faster,” treat them skeptically. For branch-heavy code, the performance difference often falls in a small range, and readability wins unless you are inside a tight computation loop. I’ve seen improvements in the 5–20% range in high-frequency hot paths after restructuring conditions, but for most business logic, the difference is negligible.
Truthy and falsy in the wild: practical heuristics
The list of falsy values is short, but the way they appear in real apps can be subtle. Here are a few heuristics I use.
Heuristic 1: Always be explicit with numbers
If a number can be 0, don’t use truthiness. 0 is falsy, so the following is wrong if a valid value can be zero:
// Wrong if 0 is valid
if (discount) {
applyDiscount(discount);
}
A safer version is explicit:
if (discount !== undefined && discount !== null) {
applyDiscount(discount);
}
Heuristic 2: Strings are easy to lie with
A string that looks like a false value is still truthy:
Boolean(‘false‘); // true
Boolean(‘0‘); // true
If you accept string input from a URL or form, parse it intentionally:
const isEnabled = query.flag === ‘true‘;
Heuristic 3: Arrays and objects are always truthy
If you are checking for empty arrays, use length. If you need to check empty objects, use Object.keys(obj).length or maintain explicit flags.
if (Object.keys(filters).length === 0) {
console.log(‘No filters applied‘);
}
Heuristic 4: Undefined vs null
When a value can be either, decide whether you want to treat them the same. If yes, value == null is a concise check. If no, be explicit and use value === null or value === undefined.
Guard clauses and early returns: my default pattern
Guard clauses are one of the most powerful readability tools in JavaScript. They shrink the indentation level and make the intent obvious.
Before: nested control flow
function completeOrder(order, inventory) {
if (order) {
if (order.items && order.items.length > 0) {
if (inventory.hasStock(order.items)) {
return finalizeOrder(order);
} else {
return { ok: false, reason: ‘Out of stock‘ };
}
} else {
return { ok: false, reason: ‘No items‘ };
}
} else {
return { ok: false, reason: ‘Order missing‘ };
}
}
After: guard clauses
function completeOrder(order, inventory) {
if (!order) return { ok: false, reason: ‘Order missing‘ };
if (!order.items?.length) return { ok: false, reason: ‘No items‘ };
if (!inventory.hasStock(order.items)) return { ok: false, reason: ‘Out of stock‘ };
return finalizeOrder(order);
}
The logic is identical, but the second version is much easier to scan. I now reach for this pattern almost automatically.
Conditional logic as “business rules”
Many teams struggle because conditions are written as ad-hoc checks scattered across the codebase. I treat conditions as business rules that deserve names.
Step 1: Name the rule
function canRefund(order, user) {
return order.status === ‘delivered‘ && user.role === ‘support‘;
}
Step 2: Use it everywhere
if (!canRefund(order, user)) {
throw new Error(‘Refund not allowed‘);
}
This approach gives you a single source of truth, makes logic easier to test, and improves the readability of the calling code.
Avoiding “magic conditions”
If a condition needs a comment to explain it, that’s a hint it should be a named function.
// Hard to understand
if (daysSinceSignup > 14 && purchases > 0 && !isFraud) {
grantTrialExtension();
}
// Clear intent
function isEligibleForTrialExtension(user) {
return user.daysSinceSignup > 14 && user.purchases > 0 && !user.isFraud;
}
if (isEligibleForTrialExtension(user)) {
grantTrialExtension();
}
Working with optional chaining and nullish coalescing
Modern JavaScript gives us better tools for safe conditional logic. Optional chaining (?.) prevents errors when accessing nested data, and nullish coalescing (??) gives safer defaults for null and undefined specifically.
Optional chaining in conditions
if (user.profile?.email) {
sendNewsletter(user.profile.email);
}
This avoids the classic Cannot read property errors without a long chain of checks.
Nullish coalescing vs logical OR
const itemsPerPage = settings.itemsPerPage || 20; // wrong if 0 is valid
const safeItemsPerPage = settings.itemsPerPage ?? 20; // only defaults on null/undefined
I use ?? for numeric or boolean values that can legitimately be 0 or false.
Conditional statements in loops
Conditions in loops are powerful but can be a source of subtle bugs, especially with continue and break.
Example: filtering with a loop
const result = [];
for (const user of users) {
if (!user.isActive) continue;
if (user.age < 18) continue;
result.push(user);
}
This approach is explicit and avoids nested blocks. It also makes your filters easy to change.
Example: early exit with break
let firstAdmin = null;
for (const user of users) {
if (user.role === ‘admin‘) {
firstAdmin = user;
break;
}
}
If you’re scanning for a single match, break makes it clear you’re done.
Conditions in functional code: filter, find, and reduce
Modern JavaScript often prefers functional methods, but the logic inside them is still conditional.
filter: express conditions as predicates
const activeUsers = users.filter(u => u.isActive && u.age >= 18);
find: stop at the first match
const admin = users.find(u => u.role === ‘admin‘);
reduce: when conditions shape the output
const counts = orders.reduce((acc, order) => {
if (order.status === ‘shipped‘) acc.shipped++;
else if (order.status === ‘pending‘) acc.pending++;
else acc.other++;
return acc;
}, { shipped: 0, pending: 0, other: 0 });
I use these methods when they increase clarity. In performance-critical paths or complex branching, plain loops can be more readable.
Comparing conditions: strict vs loose, primitives vs objects
Strict equality is your friend
When values are primitives, === avoids surprises. It’s easy to reason about and consistent.
Objects compare by reference
const a = { id: 1 };
const b = { id: 1 };
console.log(a === b); // false
This matters in conditions like:
if (selectedUser === user) { ... }
This will only be true if they are the same object reference. If you want to compare values, compare a stable key like id.
Short-circuiting: powerful but easy to misuse
Short-circuiting is a feature, not just an optimization. I use it intentionally to avoid unsafe access or expensive computation.
Safe access
if (user && user.profile && user.profile.email) {
sendEmail(user.profile.email);
}
This is cleaner with optional chaining, but it shows the basic idea.
Avoid side effects in conditions
// Risky: side effect hidden in condition
isValid && saveChanges();
This is compact, but it hides the fact that saveChanges() is a side effect. When clarity matters, I prefer:
if (isValid) {
saveChanges();
}
Conditions in UI rendering
When you work with UI frameworks, conditional logic drives rendering. The key is to keep it readable and avoid nested clutter.
Precompute booleans
const showPromo = user.isNew && cartTotal > 50;
const showUpsell = user.plan === ‘free‘ && usage > 0.8;
Then use them in render code:
{showPromo && }
{showUpsell ? : null}
This keeps JSX clean and makes the logic reusable.
Avoid double negatives
Double negatives in conditions are hard to parse:
if (!isNotEligible) { ... } // Hard to read
I’d rather rename the variable or invert the logic:
if (isEligible) { ... }
Defensive programming: conditions as safety nets
I consider conditions the first line of defense against invalid inputs and unexpected states.
Validate external data
Anything from an API or user input is untrusted. Conditions are your safety net.
function normalizeUser(input) {
if (!input || typeof input !== ‘object‘) {
return { id: null, name: ‘Unknown‘ };
}
return {
id: input.id ?? null,
name: input.name ?? ‘Unknown‘
};
}
Protect against partial failures
In complex workflows, I insert conditional checks to prevent cascading failures.
if (!profile) {
logWarning(‘Profile missing, skipping personalization‘);
return renderGenericHomepage();
}
These checks don’t just prevent crashes—they keep the user experience graceful under real-world failure modes.
Edge cases I see in production
Here are issues that tend to appear in real codebases.
1. Checking length on possibly undefined
if (order.items.length > 0) { ... } // crash if items is undefined
Safer:
if (order.items?.length > 0) { ... }
2. Comparing dates as strings
If your dates are strings, comparisons can be misleading unless you use ISO format.
const isExpired = dateString < new Date().toISOString();
This works only if the date string is in ISO format. Otherwise, parse to a Date object.
3. Floating point comparisons
Never compare floats for exact equality when decimals are involved.
if (total === 0.3) { ... } // risky
Better:
if (Math.abs(total - 0.3) < 0.0001) { ... }
4. Condition order that hides errors
if (user && user.isActive && user.role === ‘admin‘) { ... }
This is fine, but if you later refactor to:
if (user.role === ‘admin‘ && user.isActive) { ... }
It will throw when user is null. Condition order matters for safety.
Alternative approaches: tables, maps, and rule engines
Sometimes conditions grow to the point where a different structure is a better fit.
Lookup tables
const pricing = {
basic: 10,
pro: 30,
enterprise: 100
};
const price = pricing[plan] ?? 0;
This is simpler than a ladder and easier to extend.
Arrays of rules
const rules = [
{ when: u => u.isBanned, result: ‘deny‘ },
{ when: u => u.isTrialExpired, result: ‘upgrade‘ },
{ when: u => u.isActive, result: ‘allow‘ }
];
function accessDecision(user) {
const match = rules.find(r => r.when(user));
return match ? match.result : ‘deny‘;
}
This pattern is more declarative and can be easier to test. It’s especially useful when non-developers contribute to rules in a config file.
When not to over-engineer
I avoid rule engines or complex config systems if the logic is simple. The simplest possible condition is still the most maintainable when requirements are stable.
Testing conditional logic
Conditions are notoriously easy to get wrong in edge cases. I test them explicitly.
Minimum test cases I aim for
- One case where the condition is true
- One case where the condition is false
- One case with edge values (
0, empty string,null,undefined)
Example: unit tests for a predicate
function isEligible(user) {
return user.isActive && user.age >= 18;
}
// Pseudocode tests
expect(isEligible({ isActive: true, age: 18 })).toBe(true);
expect(isEligible({ isActive: false, age: 25 })).toBe(false);
expect(isEligible({ isActive: true, age: 17 })).toBe(false);
If a predicate drives access or billing, I test more thoroughly and include boundary values.
Debugging complex conditions
When conditions grow complex, I break them apart and log the intermediate steps.
Stepwise debugging
const isAdmin = user.role === ‘admin‘;
const isOwner = user.id === resource.ownerId;
const isPublished = resource.status === ‘published‘;
const canView = isAdmin || (isOwner && isPublished);
This makes it easy to log or debug individual values and prevents me from misreading a dense expression.
Conditional statements in async flows and state machines
As soon as you have async steps and multiple states, conditions start to behave like a state machine. I often make that explicit.
Example: simple state transitions
function nextState(current, event) {
if (current === ‘idle‘ && event === ‘start‘) return ‘loading‘;
if (current === ‘loading‘ && event === ‘success‘) return ‘ready‘;
if (current === ‘loading‘ && event === ‘error‘) return ‘error‘;
return current;
}
When this grows, I move to a map-based approach or a dedicated state machine library. The key is to keep the logic explicit and testable.
Conditional logic in APIs and backend code
Backend services rely on conditions for validation, authorization, and error handling.
Authorization checks
function canAccessResource(user, resource) {
if (user.role === ‘admin‘) return true;
if (resource.visibility === ‘public‘) return true;
return resource.ownerId === user.id;
}
This logic is concise and easy to extend with more rules later.
Input validation
function validatePayload(payload) {
if (!payload) return { ok: false, error: ‘Missing body‘ };
if (typeof payload.email !== ‘string‘) return { ok: false, error: ‘Invalid email‘ };
if (!payload.email.includes(‘@‘)) return { ok: false, error: ‘Invalid email format‘ };
return { ok: true };
}
I prefer explicit checks that return early with clear errors. It improves API usability and avoids hidden coercion.
Conditional statements for data normalization
Data normalization is an underappreciated place where conditional logic shines. You decide how to handle missing or messy values.
function normalizeProduct(input) {
return {
id: input.id ?? null,
name: input.name?.trim() || ‘Untitled‘,
price: Number.isFinite(input.price) ? input.price : 0,
isActive: Boolean(input.isActive)
};
}
This approach makes the rest of your code more reliable because it can trust consistent types.
Choosing readability over cleverness
I’ve reviewed enough production code to know that clever conditions are expensive. If a condition requires mental gymnastics, it slows the team down and increases bugs.
A clear rule I follow
If you can’t explain a condition out loud in one sentence, refactor it into smaller named conditions.
const hasValidSession = session && session.expiresAt > Date.now();
const hasAccess = hasValidSession && (user.role === ‘admin‘ || user.role === ‘editor‘);
Even a small refactor like this can turn a cryptic statement into something anyone on the team can understand quickly.
Practical checklist for writing better conditions
I keep these in mind when I write or review conditional logic:
- Is the condition explicit about type and value?
- Can a valid value be falsy (
0,‘‘,false)? If so, avoid truthiness. - Is the order of conditions safe for nulls and undefined?
- Would a named helper function improve clarity?
- Is the happy path visible with guard clauses?
- Do I need parentheses for clarity, even if precedence already works?
Production considerations: rollout and monitoring
Conditions are often tied to feature flags, experiment rollouts, and gradual releases. In production, I pay attention to observability.
Log decisions that matter
If a conditional affects billing or access, log it in a structured way:
if (!canRefund(order, user)) {
logEvent(‘refund_denied‘, { orderId: order.id, userId: user.id });
return { ok: false, reason: ‘Not allowed‘ };
}
Guard against unexpected states
if (![‘pending‘, ‘processing‘, ‘shipped‘, ‘delivered‘].includes(status)) {
logWarning(‘unknown_status‘, { status });
}
Monitoring these unexpected branches helps you detect data issues early.
A few more patterns I rely on
Use predicate functions for complex conditions
const isEligibleForDiscount = user =>
user.isActive && user.plan !== ‘basic‘ && user.ordersLastMonth >= 3;
if (isEligibleForDiscount(user)) {
applyDiscount(user);
}
Prefer “positive” conditions
Positive conditions are easier to read than negated ones:
if (isValid) { ... } // better than if (!isInvalid)
Avoid boolean flags with ambiguous names
If a boolean needs a comment, the name is too vague. Rename it to describe the condition.
const isEmailVerified = user.emailVerifiedAt != null;
Summary: how I think about conditions now
Conditional statements are not just syntax—they are the core of decision-making in software. I treat them as the domain language of my app. That means I make them explicit, testable, and readable, even when the code is short. I rely on strict equality, guard clauses, and named predicate functions to keep logic clear and reliable.
When I build or review code, I ask: does this condition behave correctly for every realistic input? Can another developer understand it instantly? If the answer is yes, the code is likely to survive production.
If you internalize the mental model of truthy and falsy values, choose the right conditional structure, and apply a few disciplined patterns, you’ll avoid the subtle bugs that can cost hours—or millions—in the real world.
A quick decision guide you can keep
- Use
iffor a single gate and early exits. - Use
if...elsefor a clean binary decision. - Use
else ifladders for ordered conditions. - Use
switchor lookup tables for discrete values. - Use ternary only for short, simple expressions.
- Use guard clauses and named predicates to keep logic readable and testable.
These aren’t just preferences—they are habits that make condition-heavy code safer, faster to read, and easier to maintain. If you want one takeaway: write conditions so that your future self can understand them at a glance. That’s the difference between code that works today and code that lasts.
