Skill guide
What is idiomatic code?
Published · Updated
Published by Unrust. Scoring and editorial method
Quick answer
Idiomatic code uses patterns that experienced readers of a language and codebase will recognize as clear, conventional, and appropriate for the job. It is not a universal checklist and it is not an excuse to reject unfamiliar code. A good idiom makes behavior easier to see, reduces unnecessary ceremony, and fits the constraints of the surrounding system. The best choice still depends on performance, readability, team conventions, and the problem being solved.
JavaScript: make a collection transformation visible
Both versions return the IDs of enabled features in their original order. Assume a dense array of ordinary objects with boolean enabled fields and string IDs. The filter/map version names the two operations directly; the explicit loop is also reasonable, especially if each step needs logging or error handling.
This rewrite creates an intermediate array and makes two passes. Do not call it a performance improvement without measuring your workload. If property access has side effects, the different evaluation order can matter too.
function enabledIds(features) {
const ids = [];
for (let index = 0; index < features.length; index++) {
if (features[index].enabled) {
ids.push(features[index].id);
}
}
return ids;
}function enabledIds(features) {
return features
.filter((feature) => feature.enabled)
.map((feature) => feature.id);
}Python: express a small list transformation
For a list of dictionaries with enabled and id keys, both functions preserve order and return the same IDs. A comprehension removes index bookkeeping without hiding a complicated policy. Missing keys still raise KeyError; this rewrite does not add validation.
Keep the loop when a branch needs several statements, exception handling, or an explanation of its own. Compactness is useful only while the rule remains easy to inspect.
def enabled_ids(features):
ids = []
for index in range(len(features)):
if features[index]["enabled"]:
ids.append(features[index]["id"])
return idsdef enabled_ids(features):
return [feature["id"] for feature in features if feature["enabled"]]TypeScript: let a guard narrow the remaining path
Both forms use the ok discriminant to narrow Result before reading value or reason. Returning early removes nesting on the success path without a type assertion. Neither version validates an untrusted network response; that needs a separate runtime check.
The original if/else is already idiomatic. Choose a guard when it makes the surrounding function easier to follow, not because fewer lines prove better code.
type Result =
| { ok: true; value: number }
| { ok: false; reason: string };
function describe(result: Result): string {
if (result.ok) {
return "Value: " + result.value;
} else {
return "Unavailable: " + result.reason;
}
}type Result =
| { ok: true; value: number }
| { ok: false; reason: string };
function describe(result: Result): string {
if (!result.ok) return "Unavailable: " + result.reason;
return "Value: " + result.value;
}Use the codebase's conventions and preserve behavior
Read nearby code, lint rules, and tests before changing a pattern. Check ordinary inputs, empty collections, invalid values and side effects. A useful review explains what became clearer and what remained equivalent under the stated contract.
Interactive reasoning check
Which rewrite still fits the job?
Read the reasoning without answering
Choose the form that exposes the current contract. A small transformation can fit a comprehension; error recovery and per-item effects can justify a loop. Test behavior before calling either an improvement.
A small practice loop
- 01Pick one recent change and identify the local convention it follows or breaks.
- 02Rewrite a small nested conditional with the clearest alternative you can justify, then compare both versions with a teammate or style guide.
- 03When reviewing code, explain the reader-facing benefit of a suggested change instead of calling it simply more idiomatic.
Common questions
Is idiomatic code always shorter?
No. An idiom often removes unnecessary ceremony, but shorter code is not automatically clearer. The right choice makes the behavior and the relevant constraints easier for the next reader to understand.
Can generated code be idiomatic?
It can use familiar patterns, but familiar style does not prove it fits the local codebase or the requirement. Review behavior, tests, error handling, and conventions separately.
Sources and scope
Original public examples, checked by executing both versions against representative inputs. These are teaching examples, separate from the diagnostic battery.
- Array.prototype.filter
MDN
Filtering behavior and creation of a new result array.
- Python data structures
Python documentation
List comprehensions and list operations.
- Narrowing
TypeScript handbook
Control-flow analysis and discriminated unions.
Check your own starting point
Unrust uses short, timed, unassisted drills to give developers a per-skill snapshot. One session cannot explain the cause of a result, but it can show you what is worth practicing next.
Take the free diagnostic