Code Understanding Step by Step - How to Find a Feature in the Code?

Code understanding is a must-have skill in both the implementation and maintenance phase of the software life cycle.  Different case studies agree that code comprehension is at least 50% of the entire job. It's huge. Code understanding can relate to the whole program or only a relevant part of it. In practice it is usually impossible to understand the code in its entirety.

When a developer has a specific task, he or she tries to understand only those parts of the code that are relevant to the parts that they are modifying. The descriptions of these tasks are typically expressed in terms of features. Developers, however, need to implement the requested user-level feature modifications at the source code level. Thus, mapping between features required by a user and the code implementing those features leads to a problem called feature location.

Almost all these methods are difficult to apply in practice, except the most popular solution which is called software reconnaissance. This method was motivated by conversations with developers having feature location problems in a private branch telephone exchange.  This method is based on execution of the code. Usually program executions are implemented by running appropriate test cases.

The basic idea is to group test cases into two classes. The test cases in the first group execute the feature, while the other group does not. The hypothesis is that the statements executed exclusively for the tests in the first group are implementing the feature. In other words, the set of statements executed in the first group except the statements executed in the second group are considered an implementation of the feature.

The method is working well when we can create test cases including and excluding the feature, however this is not always the case. For example a static analyzer tries to find all possible static bugs in the code for one execution; it is difficult to persuade it to search for different bugs for different executions. What can we do in this case?

Fortunately, even in this case we can apply software reconnaissance. The clue is the appropriate selection of input. Consider a static analyzer such as Findbugs as an example . We might found the location of the feature by writing two slightly different test cases, which in our case are small programs to be analyzed. The first idea is to write these two programs so that one should contain a given static bug while the other shouldn't., Apart from this the two programs are the same. We can believe that the difference in the executions is just the location of the feature, because of the bug the analyzer should observe. However, this is not a complete solution. When executing the buggy code, lots of new code parts are executed such as handling bug reports, etc. These parts are not related to the feature we are looking for, thus it is difficult to select the appropriate ones.

A much better solution is when both programs contain the same static problems and the second exclusively contains t the bug whose feature location is needed. In this case all the non-feature code can be ignored since they are executed for both test cases.  Some part of the feature will be executed for both inputs, however, for the buggy code some parts of the feature has to be executed which surely hasn't for the correct code, or else how the analyzer would recognize the bug.  Thus we will find some parts of the feature, and this is just our goal.

Use Case: Finding a feature in Findbugs

Our results for unknown source code (Findbugs, Checkstyle) validated our presumption: in most of the cases we got the location of the feature by applying our tool Jidebug:  http://www.4dsoft.eu/jidebug.

In some cases we had lots of code parts in different classes.  In these cases we started from the methods containing the most program statements our tool marked as implementing the feature. The method is really fast, the largest part of the time spent on successful feature location was to write the code, all others are negligible.

The critical element of the method is selecting appropriate input. This is not an easy task at first, but after some trials the method is much more safe and efficient than text search or similar ad hoc methods.

Finally, here is an example. We randomly selected a feature of Findbugs, a well known open source static analyser. This feature aims to find the code defining hashCode() and uses Object.equals().The task is to find the code location of a this feature. At first, we developed two small programs to be analysed by Findbugs. Only the second input code contains the problem to be revealed by the execution of this implemented feature. Both inputs contain, however, another coding problem as well, i.e. a method name starts with upper case letter. As we mentioned earlier the cause is to filter out the execution handling all static problems which is outside our feature. The input codes are as follows.

package examples;

public class A {

	public void Method() {
	}

	@Override
	public int hashCode() {                        
		return super.hashCode();
	}

	@Override
	public boolean equals(Object obj) {  // we fixed the problem in class B 
		return super.equals(obj);
	}
}

Input program #1

package examples;
public class B {

	public void Method()  { // doesn't start with a lower case letter
	}

	@Override                          
	public int hashCode() { // defines hashCode and uses Object.equals()
		return super.hashCode();
	}
}   

Input program #2

Then we execute Findbugs twice with these two programs one each other, and use Jidebug to find the feature. It emphasizes the program statements presumed to belong to the feature by red. The screenshot below shows the result. Actually, the feature's code is really implemented by the statements selected by Jidebug.

About Jidebug  

Jidebug for Java is a code comprehension and bug finding tool made for the Eclipse IDE. Download the trial version and try out this exciting new feature at http://www.4dsoft.eu/jidebug