This rule was developed in part by Fatima Nadeem at the October 20-22, 2017 OurCS Workshop (http://www.cs.cmu.edu/ourcs/register.html).
For more information about this statement, see the About the OurCS Workshop page.

Under Construction

This guideline is under construction. 


When having unreachable code it allows programs to be vulnerable to attacks and threat, as discovered by  [Watanabe, Akiyama, Kanei, Shioji, Takata, Sun, Ishi, Shibahara, Yagi, Mori, 2017].

Thus when creating new libraries or functions...

  1. Be wary when using and placement of statements such as break, continue, and return, as they're indicators that segments of code are at risk of being unreachable; as stated by [Goel, Diaz-Agudo, Roth-Berghofer, 2016] .  
    1. Use Structured Programming, explained by [Joyner 2013], to help better the design of code therefore reducing the unnecessary use of break and continue; 

  2. Modularize code as much as possible rather than combining methods/methods/classes/etc. into one.
    1.  [Chou, Chang, Kuo 2011]  explains why this is an issue in their paper; they state ...
      "In order to support design reuse, a circuit may have multiple modes and configurations so that it can be used in different applications. When verifying a specific configuration, a substantial amount of unused code may be discovered because the code may be written for other modes."


  3. Avoiding putting in dead code, such as empty function or placeholders, an issue stated by [Chou, Chang, Kuo 2011]. If dead code is temporarily used as place holder, remove before release of app.

 

Noncompliant Code Example

This noncompliant code example shows an a line of code that is unreachable. 

int x = 1;
 
if (x == 1){
	return x;
	x += 1;  
}

The statement following the return statement will never get executed thus created errors and bugs in the program which rely on that statement.

Compliant Solution

In this compliant solution with reachable code.

int x = 1;

if (x == 1){
	x += 1;
	return x; 
}

Exceptions

 

Risk Assessment

Summary of risk assessment.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

TBD

Medium

Probable

Medium

 

 

Automated Detection

Tools are available online, such as ProGuard, that help clean up code by removing unused statements that may have been a result of unreachable code.

Tool

Version

Checker

Description

TBD 


 

Related Guidelines

Fill in the table below with at least one entry row, per these instructions, then remove this purple-font section.

DRD10-X. Do not release apps that are debuggableIssues of bugs and discrepency within the code relates to this rule.

Bibliography

[Chou, Chang, Kuo 2011]Hong-Zu Chou, Kai-Hui Chang, Sy-Yen Kuo, Facilitating unreachable code diagnosis and debugging, IEEE Press Piscataway, NJ, USA, 2011
[Watanabe, Akiyama, Kanei, Shioji, Takata, Sun, Ishi, Shibahara, Yagi, Mori, 2017]Taukya Watanabe, Mitsuaki Akiyama, Fumihiro Kanei, Eitaro Shioji, Yuta Takata, So Bun, Yuta Ishi, Toshiki Shibahara, Takeshi Yagi, Tatsuya Mori, Understanding the Origins of Mobile App Vulnerabilities: A Large-scale Measurement Study of Free and Paid Apps, IEEE Press Piscataway, NJ, USA, 2017
[Joyner 2013]Ian Joyner, Simply Structured Programming, 2013
[Goel, Diaz-Agudo, Roth-Berghofer, 2016]
Ashok Goel, M Belen Diaz-Agudo, Thomas Roth-Berghofer, Case-Based Reasoning Research and Development: 24th International Conference, ICCBR 2016, Atlanta, GA, USA, 2016