Lesson plan
Unreachable code
In computer programming, unreachable code is part of the source code of a program which can never be executed because there exists no control flow path to the code from the rest of the program. Unreachable code is sometimes also called dead code, although dead code may also refer to code that is executed but has no effect on the output of a program. Unreachable code is generally considered undesirable for several reasons: * It uses memory unnecessarily * It can cause unnecessary use of the CPU's instruction cache ** This can also decrease data locality * Time and effort may be spent testing, maintaining and documenting code which is never used ** Sometimes an automated test is the only thing using the code. Unreachable code can have some legitimate uses, like providing a library of functions for calling or jumping to manually via a debugger while the program is halted after a breakpoint. This is particularly useful for examining and pretty-printing the internal state of the program. It may make sense to have such code in the shipped product, so that a developer can attach a debugger to a client's running instance.
Article summary
In computer programming, unreachable code is part of the source code of a program which can never be executed because there exists no control flow path to the code from the rest of the program. Unreachable code is sometimes also called dead code, although dead code may also refer to code that is executed but has no effect on the output of a program. Unreachable code is generally considered undesirable for several reasons: * It uses memory unnecessarily * It can cause unnecessary use of the CPU's instruction cache ** This can also decrease data locality * Time and effort may be spent testing, maintaining and documenting code which is never used ** Sometimes an automated test is the only thing using the code. Unreachable code can have some legitimate uses, like providing a library of functions for calling or jumping to manually via a debugger while the program is halted after a breakpoint. This is particularly useful for examining and pretty-printing the internal state of the program. It may make sense to have such code in the shipped product, so that a developer can attach a debugger to a client's running instance.
Key claims
No claims recorded.
Discussion questions
- Summarise the article in your own words. Which single claim would you verify first, and why?
- Which claim in this article is most likely to be revised as the sources update? How would you check its current status?
- If two sources disagreed about one of these facts, what would you need in order to trust one over the other?
Bibliography
No sources recorded.
Key claims and bibliography are generated from the same tracked claims and sources as the article page.