CSC/ECE 517 Fall 2013/ch1 1w07 d: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
Line 2: Line 2:
The practice of [http://en.wikipedia.org/wiki/Code_refactoring code refactoring] deals with changing the content or structure of code without changing the code's function in its execution.  Code refactoring has become a standard programming practice, as it potentially promotes readability, extensibility, and reusability of code.
The practice of [http://en.wikipedia.org/wiki/Code_refactoring code refactoring] deals with changing the content or structure of code without changing the code's function in its execution.  Code refactoring has become a standard programming practice, as it potentially promotes readability, extensibility, and reusability of code.


Whether done through an IDE or by hand, large-scale code projects can prove tedious to refactor.  If minimal non-functional benefits are achieved through refactoring, time is wasted.  Furthermore, if not done properly, code refactoring can actually break the functionality of the code.
Whether done through an IDE or by hand, large-scale code projects can prove tedious to refactor.  If minimal non-functional benefits are achieved through refactoring, time is wasted.  Furthermore, if not done properly, code refactoring can actually break the functionality of the code.  In the extreme case, code could be structured so badly that starting over completely may be more viable than refactoring.  As such, it is important to be able to know when and what to refactor.


==Metrics==
==Metrics==

Revision as of 15:39, 18 September 2013

Background

The practice of code refactoring deals with changing the content or structure of code without changing the code's function in its execution. Code refactoring has become a standard programming practice, as it potentially promotes readability, extensibility, and reusability of code.

Whether done through an IDE or by hand, large-scale code projects can prove tedious to refactor. If minimal non-functional benefits are achieved through refactoring, time is wasted. Furthermore, if not done properly, code refactoring can actually break the functionality of the code. In the extreme case, code could be structured so badly that starting over completely may be more viable than refactoring. As such, it is important to be able to know when and what to refactor.

Metrics

There are a variety of metrics that are used to quantify the merits of refactoring.

Complexity

In general, complexity is a measure of the number of branches and paths in the code.

Cyclomatic complexity, in particular, is a popular metric for measuring a method's complexity. In its simplest form, cyclomatic complexity can be thought of as adding 1 to the number of decision points within the code. <ref> http://www.codeproject.com/Articles/13212/Code-Metrics-Code-Smells-and-Refactoring-in-Practi</ref> These include cases in switch statements, loops, and if-else statements.

public void makeDecision(condition) {
  if(condition a) {
    choose(a);
  }
  else {
    choose(b);
  }
}

In this example, there are two decision points, so the cyclomatic complexity is 2+1=3.

Cyclomatic complexity values are divided into tiers of risk, where values less than 20 are of low-to-moderate risk, values between 20 and 50 are of high risk, and values greater than 50 are of extreme risk. <ref>http://www.klocwork.com/products/documentation/current/McCabe_Cyclomatic_Complexity</ref>

Lines of Code

Change Over Time

Duplication

Best Practices

References

<references/>