JavaScript skill practice
How do you approach this?
Writing Idiomatic JavaScript with Clear Intent
Published · Updated
Published by Unrust. Scoring and editorial method
Quick answer
Idiomatic JavaScript uses familiar language and repository patterns to make behavior easy to inspect: clear guards, deliberate array transformations, readable async control flow, and explicit handling of nullable data where it matters. An idiom is not a rule to compress every operation into one expression. Prefer the form that lets a teammate predict state, errors, and ownership in the surrounding codebase.
Original example
Keep a transformation and its policy visible
const enabledFeatureIds = features
.filter((feature) => feature.enabled)
.map((feature) => feature.id);This concise original example is easy to read when enabled and id are the full policy. If the code must log excluded features, normalize missing ids, or preserve a particular order, that behavior deserves explicit structure rather than being hidden inside a cleverer chain. Local tests should make that choice observable.
Use expressive transforms when they preserve the contract
Methods such as map, filter, find, and some reduce calls can communicate collection intent quickly, but they should not bury a business rule or error condition. If a chain makes ordering, mutation, or a fallback hard to explain, a small named loop or helper may be more idiomatic for that repository.
Let the codebase set the local dialect
JavaScript supports many valid styles for modules, async work, validation, and state updates. Read nearby code, lint rules, and tests before introducing a new pattern, then explain any departure in terms of a concrete safety or readability benefit rather than personal preference.
Check a concrete outcome
Use the original example with this input. These are local teaching fixtures, checked against the displayed snippet; they do not call external services.
The filter selects enabled entries; map extracts their IDs. Assume ordinary objects and dense arrays, without property getters.
const features = [{id: "a", enabled: true}, {id: "b", enabled: false}];| Expression after the example | Observed result |
|---|---|
| enabledFeatureIds | ["a"] |
Checklist
- Can a reader see the collection policy without decoding unrelated expression tricks?
- Does this JavaScript form hide a mutation, error path, or business rule?
- Does surrounding code use the same async and null-handling convention?
Practice loop
- 01Find a nested JavaScript conditional and write the clearest guard-clause version you can justify.
- 02Compare a collection method chain with a named loop for the same behavior and note which exposes errors better.
- 03Check nearby code and tests before calling a valid pattern idiomatic for this repository.
Limits of this page
Idiomatic JavaScript changes across runtimes, teams, and performance constraints, so there is no universal style score. A timed comparison can support a discussion about clarity, but it cannot establish that one person is more capable or explain why a convention was unfamiliar.
Source context
Published by Unrust as practical teaching material using public language documentation and original examples. See the scoring and editorial method for scope, checking and limitations.
Check your own starting point
One diagnostic session is a snapshot, not causal proof of why a result occurred. It can help you choose a focused next practice step without making a broader claim about your ability.
Take the free diagnosticTake the read in JavaScript →Same six skills, side by side on your dashboard.