6 exercises — write TODO, FIXME, HACK, and NOTE comments professionally, with owners, ticket references, and clear context.
0 / 6 completed
1 / 6
Which is the most professionally useful way to write a `TODO` comment?
A high-quality TODO comment includes: (1) an owner (or team) — TODO(alex), (2) a specific description of what needs to happen, (3) a tracking reference (ticket number) when the work is non-trivial, and (4) context on why it's acceptable to defer right now.
Bare "TODO" with no context becomes permanent, unowned debt — searchable but meaningless. A well-written TODO is nearly as useful as a proper ticket, and often gets picked up faster because it's visible directly in the code path.
2 / 6
What is the correct professional use of a `FIXME` comment, as distinct from `TODO`?
The conventional distinction: `TODO` marks planned, not-yet-done work (often a feature or improvement); `FIXME` marks a known defect in code that already exists and is currently running — something actively wrong, not just incomplete. Many linters and static analysis tools treat `FIXME` with higher urgency than `TODO` for exactly this reason.
Formula: // FIXME: [specific incorrect behaviour] — [condition that triggers it] — [ticket, if tracked].
Using the two markers correctly helps automated tooling and human reviewers triage code health accurately — grepping for `FIXME` should surface real bugs, not just future feature ideas.
3 / 6
You need to write a `HACK` comment for a workaround you know is not the "proper" fix. Which is correctly written?
A `HACK` comment should explain (1) what the workaround does, (2) why the "proper" solution isn't used (external constraint, time pressure, upstream bug), and (3) ideally, what would trigger removing it. This turns an apology into actionable information for the next engineer who encounters the code.
Formula: // HACK: [what it does] to work around [specific constraint/bug]. [Removal condition, if known].
Being explicit about the trade-off (rather than just "this is hacky, sorry") helps future maintainers judge whether the hack is still necessary and gives them the context to remove it safely when circumstances change.
4 / 6
What is the correct use of a `NOTE` comment marker, distinct from `TODO`/`FIXME`/`HACK`?
`NOTE` is the marker for important, non-obvious context that isn't actionable debt (unlike TODO/FIXME/HACK) but that a future reader genuinely needs to know — an invariant, a non-obvious dependency, or a warning about a subtle behaviour.
Formula: // NOTE: [important context or invariant that isn't obvious from the code alone].
The four markers (TODO/FIXME/HACK/NOTE) form a useful, greppable vocabulary: TODO = planned work, FIXME = known bug, HACK = intentional workaround, NOTE = important context. Using them consistently makes a codebase's debt and caveats searchable in one command (`grep -rn "TODO\|FIXME\|HACK"`).
5 / 6
A code review comment says: "This TODO has no owner and no ticket — it's been here for 2 years." What is the correct professional response?
Stale, unowned TODOs are a common code smell. The professional response acknowledges the gap and commits to one of two concrete actions: formalise it (create a ticket, assign an owner) if it's still relevant, or remove it if the underlying concern has been resolved or is no longer valid. Leaving it as ambiguous, unowned debt is the wrong outcome either way.
Formula: "Good catch — I'll [create a ticket and assign an owner / remove the comment] since [reasoning]."
Some teams enforce this with a CI check that fails on TODOs without a ticket reference, precisely to prevent comments like this from silently aging for years.
6 / 6
Why is it considered bad practice to use `TODO`/`FIXME` comments as a substitute for an actual issue tracker for significant work?
In-code markers are excellent for local, code-adjacent context ("this specific line needs revisiting") but poor for project management — they lack assignment, prioritisation, status, discoverability outside the file, and reporting. The professional pattern is to use both together: a short in-code marker referencing a ticket number, with the ticket carrying the full tracking metadata.
Useful phrase: "Let's keep the comment for local context but file a ticket for visibility and prioritisation — comments alone are easy to lose track of." This hybrid approach gets the benefits of both: immediate visibility in the code, and proper tracking in the backlog.
What will I practice in "TODO/FIXME/HACK Comments — Code Comments Exercise"?
This is a Code Comments exercise set. It walks through 6 scenario-based multiple-choice questions built around real usage of Code Comments terminology that IT professionals encounter on the job.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to complete with no account, sign-up, or paywall.
How many questions are in this exercise?
This set contains 6 questions. Each one shows immediate feedback and a detailed explanation after you answer, so you learn the correct usage right away rather than waiting for a final score.
Do I need prior experience to complete this exercise?
No prior experience is required. Each question includes a full explanation covering the reasoning behind the correct answer, so the exercise itself teaches the Code Comments vocabulary as you go.
Can I retry the exercise if I get questions wrong?
Yes — use the "Try again" button on the results screen to reset your answers and go through all the questions again. There is no limit on attempts.
Is my progress saved?
Your answers and score for the current session are tracked in the browser as you go. No account or login is needed, and there is nothing to install.
What if I don't understand a term used in a question?
Read the explanation shown after you answer each question — it breaks down the correct term in plain English with a real-world example. You can also check the site Glossary for quick definitions.
How is this different from reading a blog article on the topic?
Exercises like this one are interactive drills that test and reinforce specific vocabulary through multiple-choice questions, while blog articles explain concepts in prose. Practising here after reading builds active recall, not just passive recognition.
Where can I find more Code Comments exercises?
See the Code Comments exercises hub for the full set of related pages, or browse all exercise categories from the main Exercises index.
Can I use this exercise to prepare for a technical interview?
Yes — Code Comments vocabulary comes up often in technical discussions and interviews. Pair this exercise with our dedicated Interview Preparation section for role-specific practice.