Opening verse
Par for the Course
A golfer stands before the green,
A coder faces down a screen.
Both choose a path, both judge the space,
Then trust their hands to set the pace.
In both, a lower score can show
How well you chose the way to go.
But fewer moves are not the prize
If no one sees where meaning lies.
A heavy swing may miss its aim;
A tangled script can do the same.
The cleaner shot, the cleaner line,
Makes every ounce of effort count by design.
Each extra stroke can raise the score;
Each needless line can ask for more:
More tests to write, more bugs to chase,
More chances things will fall from place.
You practise, fail, adjust, repeat,
Until the motion feels complete.
With patience, focus, steady art,
Consistency becomes the heart.
And when the final putt drops clean,
Or perfect output fills the screen,
The finest work seems light and small—
Not doing less, but wasting none at all.
Less code, better code?
Clarity is the real low score.
Writing less code does not mean squeezing an entire application into one unreadable line. It means removing unnecessary steps, repeated logic, and needless complexity.
The aim is not simply to write fewer characters. The aim is to make the code easier to understand, test, and maintain.
Here are five JavaScript examples where a cleaner approach makes every line count.
Refactor / Development
Do not manually create a result you already have
function canVote(age) {
let result = false;
if (age >= 18) {
result = true;
} else {
result = false;
}
return result;
}function canVote(age) {
return age >= 18;
}The comparison age >= 18 already produces either true or false. The longer version creates a variable and an entire conditional block without adding any useful information.
It is the coding equivalent of taking three strokes when one would have done the job.
Refactor / Development
Use the language to express your intention
Suppose we need to check whether a list contains an overdue invoice.
function hasOverdueInvoice(invoices) {
let hasOverdue = false;
for (let index = 0; index < invoices.length; index++) {
if (invoices[index].status === "overdue") {
hasOverdue = true;
break;
}
}
return hasOverdue;
}function hasOverdueInvoice(invoices) {
return invoices.some(
invoice => invoice.status === "overdue"
);
}Both versions work, but some() tells the reader exactly what the code is trying to discover: does some item in this collection meet the condition?
The better version has less state, less control flow, and fewer places for mistakes to hide.
Refactor / Development
Avoid unnecessary nesting
Concise code is not always about having fewer lines. Sometimes it is about having fewer layers of logic to work through.
function openDashboard(user) {
if (user) {
if (user.isActive) {
if (user.permissions.includes("dashboard")) {
return loadDashboard(user);
} else {
throw new Error("Dashboard access denied");
}
} else {
throw new Error("User is inactive");
}
} else {
throw new Error("User is required");
}
}function openDashboard(user) {
if (!user) {
throw new Error("User is required");
}
if (!user.isActive) {
throw new Error("User is inactive");
}
if (!user.permissions.includes("dashboard")) {
throw new Error("Dashboard access denied");
}
return loadDashboard(user);
}The second version is not dramatically shorter, but it is much easier to follow. Each invalid situation is dealt with immediately, leaving the successful path clear.
These are often called guard clauses. They reduce the number of conditions a developer must hold in their head at once.
Refactor / Development
Do the work once
function calculateOrder(items) {
const subtotal = items.reduce(
(sum, item) => sum + item.price * item.quantity,
0
);
const tax = items.reduce(
(sum, item) => sum + item.price * item.quantity,
0
) * 0.2;
const total =
items.reduce(
(sum, item) => sum + item.price * item.quantity,
0
) +
items.reduce(
(sum, item) => sum + item.price * item.quantity,
0
) * 0.2;
return {
subtotal,
tax,
total
};
}function calculateOrder(items) {
const subtotal = items.reduce(
(sum, item) => sum + item.price * item.quantity,
0
);
const tax = subtotal * 0.2;
const total = subtotal + tax;
return {
subtotal,
tax,
total
};
}The first version repeatedly performs the same calculation. That makes the code longer, wastes processing time, and creates several copies of the same logic that may later need to be updated.
The better version calculates the subtotal once and reuses the result.
Refactor / Development
Shorter is only better when it remains clear
Code golf can be entertaining, but production software should not become a competition to remove every possible character.
const d=(u,t)=>u?.m?t*.1:0;function calculateMemberDiscount(user, orderTotal) {
if (!user?.isMember) {
return 0;
}
return orderTotal * 0.1;
}The first version is shorter, but it hides the meaning behind vague variable names and compressed logic. A future developer has to stop and decipher it.
The second version explains itself. Good code is not necessarily the code with the fewest characters. It is the code that communicates its purpose with the least unnecessary effort.
Much like golf, the perfect result is not achieved by swinging wildly or taking shortcuts at every opportunity. It comes from choosing the right approach, removing wasted movement, and making each stroke—or each line—count.
The clean line
The finest work seems light and small—not doing less, but wasting none at all.