6 exercises — explain non-obvious algorithm choices, Big-O complexity, magic numbers, and base cases with high-quality comments.
0 / 6 completed
1 / 6
You implemented a non-obvious algorithm choice: using a Bloom filter instead of a hash set for membership checks. Which comment correctly explains the design decision above the class?
A design-decision comment for a non-obvious algorithm choice should state (1) what was chosen and what the obvious alternative would have been, (2) the specific constraint that drove the choice (memory budget, dataset size), and (3) the trade-off accepted (false-positive rate) — ideally with a reference for deeper analysis.
Formula: // We use [choice] instead of [obvious alternative] because [specific constraint]. We accept [trade-off] (see [reference]).
This level of detail is justified specifically because the choice is non-obvious — a future engineer seeing "Bloom filter" might reasonably ask "why not just a hash set?" and the comment should pre-empt that question.
2 / 6
You want to document the time complexity of a function above its definition. Which is correctly written?
Big-O comments should state both time and space complexity using standard Big-O notation, and ideally point to the specific line or operation that dominates the complexity — this is especially valuable when the dominating factor isn't the most visually obvious part of the code.
Documenting complexity is most valuable for non-trivial algorithms where a reader might assume a naive complexity (e.g. thinking a function is O(n) when a hidden nested loop or sort makes it O(n²) or O(n log n)) — flagging it prevents accidental performance regressions during refactoring.
3 / 6
You implemented a well-known algorithm (e.g. Dijkstra's shortest path) with a specific optimisation (a Fibonacci heap instead of a binary heap). Which comment correctly documents this?
Even for well-known algorithms, comments should name the algorithm explicitly (helps readers who don't immediately recognise it and enables searching for reference material), state the specific variant/optimisation used, give the resulting complexity, and justify why the added complexity was worth it for this specific use case.
Formula: // [Algorithm name] using [specific optimisation] for [complexity] instead of [naive complexity] — worth it because [context-specific justification].
"Well-known" doesn't mean "self-explanatory in this context" — the choice of a specific variant (Fibonacci heap vs. binary heap) is exactly the kind of non-obvious decision that deserves a comment.
4 / 6
A magic number appears in a numerical algorithm: `x *= 0.618033988749895;`. Which comment correctly explains it?
A magic-number comment for an algorithmic constant should name what the number represents mathematically, why it was chosen for this specific use case, and ideally cite a reference source if the constant comes from established literature (a textbook, paper, or RFC).
Formula: // [Name/meaning of the constant] — used for [specific purpose] in this [algorithm], per [reference, if applicable].
Uncommented magic numbers in numerical or cryptographic code are especially dangerous — a future engineer might "clean up" the number, assuming it was arbitrary, and silently break the algorithm's correctness.
5 / 6
You wrote a recursive algorithm with a non-obvious base case. Which comment correctly documents the base case's reasoning?
A base case comment is most valuable when the chosen convention (e.g. treating an empty subtree as depth 0 rather than -1 or throwing) has downstream implications for how the rest of the algorithm is written. Explaining the convention and why it simplifies the calling code prevents someone from "fixing" what looks like an inconsistency but is actually a deliberate design choice.
Formula: // Base case: [convention chosen] — this lets [downstream benefit] without [complexity avoided].
Non-obvious base cases are one of the most common sources of off-by-one bugs when algorithms are modified later, making them a high-value target for comments.
6 / 6
A colleague asks "when should I NOT add a comment to a complex-looking piece of code?" What is the correct answer, based on best practice for algorithm comments?
The best "comment" is often no comment at all — achieved by extracting well-named functions that make the algorithm's structure self-documenting. Comments are reserved for cases where naming and structure genuinely cannot convey the "why" — a non-obvious trade-off, a reference to external literature, or a subtle invariant that isn't visible from the code's shape alone.
Rule of thumb: "If a good function/variable name could replace this comment, refactor instead of commenting. If the comment explains WHY, not WHAT, keep it — that's information the code itself can never express."
What will I practice in "Commenting Complex Algorithms — 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.