Mes Secrets Inconnus

A nice read for those interested in dead  code analysis while doing code coverage

Dead Code is a term that means more than just a block of code with no possible entry points. It's been used to describe code that's been commented out or exists in files but not being built.  Also in some cases, it's been inappropriately used to describe code that is very difficult to reach.

The following 3 categories are meant to clarify the different types of "Dead Code" and recommendations on what to do for each.

Unused Code:

Orphaned code that lingers in the build but has no possible customer usage scenarios. This is more like the classical “Dead Code” definition; code blocks with no possible entry points.

Example:

· Class that never gets instantiated anywhere.

· Function that is never used in any other code.

Risk:

· Likely untested

· Likely un-analyzed by various runtime tools

· Potentially wasted space (media, ROM images, etc. if not optimized out).

· Security exposure.

Unused code is most likely optimized out, but in the cases where it makes it into the binary, it should be considered for removal.

Unreachable Code:

Code that is unexecuted due to logic that does not currently evaluate to allow execution (ex. relies on config/environmental scenarios that do not exist).

Example:

· Blocks of code that are logically unreachable: if (some_condition) { ...code....}, where some_condition doesn’t exist as TRUE in the world today.

· Blocks of code to handle non-existent hardware:

· Exception handler code that may impossible to trigger.

Risk:

· Likely untested, and can be awakened if config/environment comes into existence (most serious for already shipped code).

· Likely un-analyzed by various tools

· Wasted space (media, ROM images, etc.)

· Security exposure.

Unreachable code may also be optimized out (like in the cases of if (0) {...}), but for other code in this category that makes it into the binary, it may require core code changes to enable test cases, like interface hooks or some other type of testing approach (like fault injection).

The most serious code in this category is code that could become active post RTM when the world changes in a way that causes it to be executed.

Boneyard Code:

Code that is kept around for either posterity, tradition, fear of unknown (like if confronted with “let’s get rid of if”), or just plain laziness.

Example:

· Code that is commented out

· Code in files that are not part of compilation (i.e. in tree, but not in sources)

Risk:

· Untested

· Un-analyzed by various static analysis tools

· May not go through security review

· If enabled/re-activated at some future date, may introduce anachronistic code

· Security exposure.

Boneyard code is not as serious as it has no presence in shipping code and thus, by definition, poses no risk to our customers. Should be remove during something like a MQ timeframe or some other "Codebase Clean-up" effort.