A programmer reviews the accuracy of an algorithm by _____ it (before executing code).

Introduction / Context:
Before running a program, developers often verify logic manually to catch defects early. This practice—called desk-checking—uses pencil-and-paper (or a simple table) to simulate the algorithm with sample inputs and follow variable changes step by step.

Given Data / Assumptions:

• No actual execution or debugger is required.
• Representative test cases are chosen, including edge cases.
• The goal is to validate control flow and state transitions.

Concept / Approach:
Desk-checking reduces costly rework by exposing logic gaps, off-by-one errors, and uninitialized variable usage before compiling or running code. It complements later dynamic testing and fits well in code reviews and pair programming sessions.

Step-by-Step Solution:
1) Select input values (normal, boundary, invalid). 2) Walk through each algorithm step, recording variable updates. 3) Compare expected outcomes to the algorithm’s computed results. 4) Adjust algorithm where discrepancies appear.

Verification / Alternative check:
Software engineering guides recommend desk-checking and dry runs prior to unit tests to minimize trivial defects.

Why Other Options Are Wrong:
Option A/D: “Analyzing” and “planning” are general phases, not the specific manual simulation practice.
Option B: Coding produces the artifact; it does not validate logic by itself.
Option E: Not applicable because a standard practice exists.

Common Pitfalls:
Skipping desk-checks and relying solely on runtime tests; this often lengthens the debug cycle.

Final Answer:
Desk-checking