CSC/ECE 517 Fall 2009/wiki1a 8 rr: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 9: Line 9:
====Improve names====
====Improve names====
*Renaming methods/variables etc to more meaningful names is a good practice. The method name should tell the reader what exactly the method does. Or a variable name should give a clear picture of what the variable stores.
*Renaming methods/variables etc to more meaningful names is a good practice. The method name should tell the reader what exactly the method does. Or a variable name should give a clear picture of what the variable stores.
   display()  => displayStudentNames
   display()  => displayStudentNames()
*Extract a sub package depending on their gross dependencies or usages. This is to make the code more flexible.  
*Extract a sub package depending on their gross dependencies or usages. This is to make the code more flexible. For example
  interface org.davison.data.DataProvider
  interface org.davison.data.DataProvider
  class org.davison.data.DataFactory
  class org.davison.data.DataFactory
Line 22: Line 22:
  class org.davison.data.jdbc.JDBCProvider
  class org.davison.data.jdbc.JDBCProvider
  class org.davison.data.jdbc.JDBCHelper
  class org.davison.data.jdbc.JDBCHelper
:This holds good for method/class/interface also
====Change location of code====
====Change location of code====
*Always try to keep the class in relevant package. If it does not fit into any existing package then create a new package. This starts to make sense when this part of the code gets re-used in other parts of the project. This applies to class/method/field
*Always try to keep the class in relevant package. If it does not fit into any existing package then create a new package. This starts to make sense when this part of the code gets re-used in other parts of the project. This applies to class/method/field
Line 57: Line 57:
   // do something
   // do something
  }
  }
===2. Code management and restructuring===
====Change Reference to Value and Change Value to Reference====




===2. Code management and restructuring===
===3. Allow abstraction===
===3. Allow abstraction===
===4. Change of logic===
===4. Change of logic===

Revision as of 07:05, 8 September 2009

Categorization of code refactoring

What is Code Refactoring?

Code Refactoring is a technique of reorganization code to change its structure but at the same time preserving the basic functionality of the code. There are many kinds of code refactoring. This wiki tries to categorize these types of refactoring so that it's easy for people to learn these patterns and remember them.

Categories of Code refactoring

1. Improve readability and code reuse

One of the major motivation for code refactoring is readability.

Improve names

  • Renaming methods/variables etc to more meaningful names is a good practice. The method name should tell the reader what exactly the method does. Or a variable name should give a clear picture of what the variable stores.
 display()  => displayStudentNames()
  • Extract a sub package depending on their gross dependencies or usages. This is to make the code more flexible. For example
interface org.davison.data.DataProvider
class org.davison.data.DataFactory
// Database classes
class org.davison.data.JDBCProvider
class org.davison.data.JDBCHelper

Could be modified to 

interface org.davison.data.DataProvider
class org.davison.data.DataFactory
// Database classes
class org.davison.data.jdbc.JDBCProvider
class org.davison.data.jdbc.JDBCHelper
This holds good for method/class/interface also

Change location of code

  • Always try to keep the class in relevant package. If it does not fit into any existing package then create a new package. This starts to make sense when this part of the code gets re-used in other parts of the project. This applies to class/method/field
class org.davison.ui.TextThing
class org.davison.ui.TextProcessor
class org.davison.log.Logger
//depends on
class org.davison.ui.StringUtil

Could be modified to 

class org.davison.ui.TextThing
class org.davison.ui.TextProcessor
class org.davison.log.Logger
//depends on
class org.davison.util.StringUtil
  • Pull up or Push down (method/fields)
Pull the method/fields up to the superclass as shown in this example or push the method/fields to the subclass when needed as shown in this example.
  • Some other methods include
    • Add parameter - The main motivation here is when the method needs more information by the caller. Also Remove parameter can be used to remove parameters which the function no longer wants.
    • Introduce explaining variable - This can be explained with the below example
if ((platform.toUpperCase().indexOf("MAC") > -1) && (browser.toUpperCase().indexOf("IE") > -1) && wasInitialized() && resize > 0 )
{
  // do something
}

Can be modified to 

final boolean isMacOs     = platform.toUpperCase().indexOf("MAC") > -1;
final boolean isIEBrowser = browser.toUpperCase().indexOf("IE")  > -1;
final boolean wasResized  = resize > 0;
if (isMacOs && isIEBrowser && wasInitialized() && wasResized)
{
  // do something
}

2. Code management and restructuring

Change Reference to Value and Change Value to Reference

3. Allow abstraction

4. Change of logic

5. Merging/Reduction of code

Conclusion

References

External references

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_8_rr&oldid=18660"