Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2014/ch1a 1e rm

2014-02-19T05:42:54Z

Rjlloyd: /* Metrics */

This page discusses refactoring techniques and metrics. It also includes tips on refactoring in Ruby and list of tools for automated refactoring.

For the page with a history of edits, go to [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2014/ch1a_1w1e_rm this page].

==Background==

The idea behind [http://en.wikipedia.org/wiki/Code_refactoring code refactoring] is to take a code base and improve its readability, [http://en.wikipedia.org/wiki/Extensibility extensibility], and [http://en.wikipedia.org/wiki/Reusability reusability]. The practice is focused on having a better quality and more standardized code base, and not on fixing bugs or changing functionality.

In their Refactoring book<ref name="Refactoring book">http://books.google.com/books?id=1MsETFPD3I0C</ref>, Martin Fowler and Kent Beck define refactoring as 'A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior… It is a disciplined way to clean up code that minimizes the chances of introducing bugs'.

Refactoring has its difficulties, whether or not it is done using an [http://en.wikipedia.org/wiki/Integrated_development_environment IDE] or whether it is done by hand. There are lots of errors that can be made during refactoring, so it is pertinent to determine when it is necessary to refactor. Code metrics are one method used to determine how badly a file needs refactoring.

Two main types of refactoring are <ref>http://web.cecs.pdx.edu/~black/publications/IEEESoftwareRefact.pdf</ref>:
# Floss refactoring: refactoring performed regularly to keep code clean; gives healthy benefits in the long run
# Root canal refactoring: infrequent and protracted periods of refactoring; makes it painful and expensive (similar to dental analogy); mainly performed to clean unhealthy code

==Refactoring Techniques==
Before a coder performs a refactor, they must, either formally or informally, identify their ‘code smells’. A code smell refers to a negative quality of a code base that either implements bad programming practices or slows down code development or runtime. These aren't typically bugs, but can increase the chance of bugs later on if not fixed. Based on the type of code smell, a different refactoring technique is used to fix it.

===Duplicate Code===
Duplicate code can be a tricky concept when refactoring. Large sections of duplicated code can be easy to find and fixed by pulling it out and creating a single centralized method to call, however it is usually not that easy. Sometimes it may only be one or two lines of code that are duplicated which calls for an assessment of whether or not it is in the best interest to create a new method for a couple lines of code. Other times, code is not duplicate, rather it is similar enough that a generic method could be created to serve various purposes.
Some specific techniques to deal with this are:
*Extract Method / Pull-up Method
**If common code is used in multiple places, simply pull it out and make a method that can be called from all of the necessary places. Variables can be passed in if slight variations are needed between calls.
**If the code is used in various subclasses, put the common code in a method in the superclass, so that it can be seen and called by its children.<ref>http://www.refactoring.com/catalog/extractMethod.html Extract Method Example</ref>
Before Refactor
<pre>
class Cat
end

class Lion < Mammal
def likes
puts "Boxes"
end
end
class HouseCat < Mammal
def likes
puts "Boxes"
end
end
</pre>
After Pull Up Refactor
<pre>
class Cat
def likes
puts "Boxes"
end
end

class Lion < Mammal
end
class HouseCat < Mammal
end
</pre>

*Form Template Method
**If two methods in subclasses perform similar steps in the same order, but the steps are different, then get the steps into methods with the same signature, so that the original methods become the same. Then pull them up. <ref>http://www.refactoring.com/catalog/formTemplateMethod.html</ref>
Before Refactor
<pre>
class Cat
end
class Tiger < Cat
def live
puts “Wake up”
puts “Catch deer”
puts “Eat deer”
puts “Sleep in sun”
end
end
class HouseCat < Cat
def live
puts “Wake up”
puts “Wake human up”
puts “Eat food”
puts “Sleep in sun”
end
end
</pre>
After Form Template Refactor
<pre>
class Cat
def live
puts “Wake up”
do_morning_routine
puts “Sleep in the sun”
end
end
class Tiger < Cat
def do_morning_routine
puts “Catch deer”
puts “Eat deer”
end
end
class HouseCat < Cat
def do_morning_routine
puts “Wake human up”
puts “Eat food”
end
end
</pre>

===Large Method/Class===
If a project is not planned out well enough in advance, it is easy for methods and classes to become populated with excess functionality. While functionality of a block of code may be necessary for the project, the code block might not really pertain to the method or class it is included in.
*Extract Method
**This can be used when duplicate code occurs, as discussed above. But it can also be used when a method performs multiple functions that have the ability to be split up into various functions that serve a single purpose.
Before Refactoring
<pre>
def foo
puts "hey"
puts "how are you"
puts "bye!"
end
def bar
puts "bye!"
end
</pre>
After Extract Method Refactor
<pre>
def greet
puts "hey"
puts "how are you"
end
def farewell
puts "bye!"
end
def foo
greet
farewell
end
def bar
greet
end
</pre>
*Extract Class/Subclass/Superclass
**If there are class variables or methods that don’t directly pertain to a class, then it may be necessary to create a new class for those pieces.[http://www.refactoring.com/catalog/extractClass.html Example]
**If there are pieces of a class that are only for a specific subset of instances, then a subclass can be constructed to contain these.[http://www.refactoring.com/catalog/extractSubclass.html Example]
**If there are pieces that multiple classes use, then a superclass can be constructed to handle these generic functions, leaving the subclasses to deal with the remaining differences<ref>http://www.refactoring.com/catalog/extractSuperclass.html Example </ref>
Before Refactoring
<pre>
class Person
def initialize(f,m,l,s)
@firstName = f
@middleName = m
@lastName = l
@SSN = s
end
end
</pre>
After Extract Class Refactoring
<pre>

class FullName
def initialize(f,m,l)
@firstName = f
@middleName = m
@lastName = l
end
end

class Person
def initialize(f,m,l,s)
@name = FullName.new(f,m,l)
@SSN = s
end
end
</pre>

===Improving Readability and Clarity===
Many times, refactoring can be used to do simple, yet necessary changes like renaming variables, methods, or classes. As features get added to a project, classes tend to get charged with more uses than originally planned, so sometimes, the original naming scheme no longer applies and a new one needs to be instilled.

Moving methods and parameters around to where they have the best accessibility also has its uses. Classes also tend to be promoted or demoted to super and sub classes after their ultimate functional purpose is determined.

==Metric Tools==
It can be hard to decide whether or not to refactor, especially when it’s for something that appears to be working fine with just a surface level smell. Program analysis tools are used to derive various types of code metrics, which allow coders to identify problem areas and future pitfalls of their code base. These tools look at the code in several different ways, including the number of times a source file has been edited to help determine if it is a possible target of [feature envy], duplicate code structure to identify replicated lines, and block depths to suggest possible complexity issues.

===Code Climate===
[https://codeclimate.com Code Climate] is a hosted code metrics tool that analyzes projects in a multitdue of ways. It produces three main metric ratings with grades from A-F that comprise of the methods and classes contained in each file and project.
#Complexity Metric - This is based off of the Assignment, Branches, and Conditions ([http://c2.com/cgi/wiki?AbcMetric ABC]) metric, where the number of assignments, branches, and conditions are counted and analyzed. However, because Code Climate is constructed for Ruby programs, it also takes into account certain types of Ruby constructs that may increase the metric score, but are actually beneficial to the project.
#Duplication Metric - This looks at the syntax trees of the code in order to identify identical and similar code structures. Because the syntax trees are being analyzed, code formatting and different method and class names do not affect the score. <ref>https://codeclimate.com/docs#quality-metrics</ref>
#Churn Method - This integrates with the Git repository to look at the change history of the project’s files. Files with excessively high change histories have a tendency to have a high complexity rating as well, as they can be the result of feature envy, where extra functions are added into a file instead of being added to a new file with its own functionality.

===Open Source Ruby Metric Tools===
There are a variety of open source code metric tools that can be employed specifically for Ruby programs. [https://www.ruby-toolbox.com/categories/code_metrics The Ruby Toolbox] contains the most popular of these tools along with ratings.

[http://rubydoc.info/gems/simplecov/frames Simple Cov] is at the top of this list for code coverage. It was developed specifically to be of use to anyone using any framework. It integrates itself with the project’s own test cases to check the code coverage of them in addition to cucumber features.

For cyclomatic complexity (the number of possible paths), Saikuro is commonly employed and made to be easy to implement. For code complexity, Flog is the typical choice by the open source community of users.<ref>http://www.sitepoint.com/code-metrics-and-you/</ref>

==Getting Started with Refactoring==

===First step: Writing tests===
The first step in refactoring is writing solid set of tests for the section of code under consideration, in order to avoid introducing bugs. In Ruby, this can be done using [http://www.ruby-doc.org/stdlib-2.1.0/libdoc/test/unit/rdoc/Test/Unit.html Test::Unit] or [http://rspec.info/ Rspec]. Next step is to make small changes, test, make small changes, test again and so on<ref name='Refactoring Ruby Edition'>http://books.google.com/books?id=6jyOUrJBJHAC</ref>. This ensures that we can revert back to the working version of code if any small refactoring causes the application to stop working.

===When to refactor===
It is always confusing when to start refactoring. If either one of the following conditions is true, it is a good time to start refactoring code<ref name='Refactoring Ruby Edition'/>:
* The Rule of Three - If any code segment gives trouble more than two times, it is time to refactor it
* Adding new function - It might be helpful to refactor when adding new functionality as it would give better understanding of code. Sometimes, revisiting old design might help to accommodate new features better
* Fixing a bug - It is useful to refactor code which had a bug; this might save bug reports from the same piece of code in future
* During code review - Refactoring is useful during code reviews as it can be applied immediately making code reviews more fruitful
* Understanding other's code - If a new member joins the team and is asked to refactor existing code, it helps them to get a better understanding of the code base. It might take extra time to get them started, but trying to refactor will help them contribute to the project better in the long run.

A [http://blog.codeclimate.com/blog/2014/01/09/when-is-it-time-to-refactor/ CodeClimate blog] suggests some other conditions to decide when to refactor code.

===When NOT to refactor:===
* Avoid refactoring when you should ideally be rewriting the entire code. Although a tough call to make, rewriting is inevitable when current code does not work at all or is too buggy to stabilize.
* Avoid refactoring when close to a deadline since productivity gain by refactoring is mostly seen after the deadline and might just cause the project to miss the deadline.
* Avoid refactoring for academic purposes, i.e. avoid changing code in working condition because you do not agree with those lines of code or that is not how you would have implemented it.

==Automated Code Refactoring==
=== RubyMine ===
*[http://www.jetbrains.com/ruby/webhelp/refactoring.html RubyMine] has a built in refactoring menu.
*To perform refactoring, select a code fragment to refactor. Refactorings available for your selection appear under the Refactor Menu in RubyMine. <ref>http://www.jetbrains.com/ruby/webhelp/refactoring-source-code.html#common</ref> [[File:RubyMine_refactoring_menu.png]]

===RFactor ===
*[http://fabiokung.com/2009/02/04/rfactor-ruby-refactoring-for-your-loved-editor/ RFactor] is a Ruby gem, which aims to provide common and simple refactorings for Ruby code for text editors like TextMate
*The first release has only Extract method implemented while other refactorings are coming soon
*It is available on [http://github.com/fabiokung/rfactor-tmbundle/tree/master GitHub]

=== Other IDEs ===
*Some other IDEs with built-in refactoring include [http://www.aptana.com/products/studio3 Aptana Studio], [http://www.aptana.com/products/radrails Aptana RadRails] and [https://netbeans.org/features/ruby/index.html NetBeans 7] (which requires Ruby and Rails [http://plugins.netbeans.org/plugin/38549 plugin])
*A StackOverflow [http://stackoverflow.com/questions/8705144/ide-with-refactoring-support-for-ruby-on-rails post] compares these tools ranking them as RubyMine being the best, followed by NetBeans, RadRails 2 and Aptana Studio 3

==Further Reading==
*[http://en.wikipedia.org/wiki/Code_smell Ways to identify problems in code]

*[http://ghendry.net/refactor.html A description of smells with their techniques exists]

*[http://www.refactoring.com/catalog/index.html A list of techniques with examples in Ruby are listed]

*[http://blog.codeclimate.com/blog/2012/11/14/why-ruby-class-methods-resist-refactoring/ Resistance With Refactoring Ruby Class Methods]

*[http://www.railsinside.com/uncategorized/460-the-first-step-of-refactoring-a-rails-application.html Refactoring a Rails Application]

*[http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ Refactoring Fat Models]

*[https://speakerdeck.com/brianvh/refactoring-views-in-rails Talk on Refactoring Fat Views]

*[http://books.google.com/books?id=i6mZ0HBDPzsC Rails AntiPatterns: Best Practice Ruby on Rails Refactoring]

==References==
<references/>

CSC/ECE 517 Spring 2014/ch1a 1e rm

2014-02-19T05:42:08Z

Rjlloyd: /* More Techniques */

This page discusses refactoring techniques and metrics. It also includes tips on refactoring in Ruby and list of tools for automated refactoring.

For the page with a history of edits, go to [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2014/ch1a_1w1e_rm this page].

==Background==

The idea behind [http://en.wikipedia.org/wiki/Code_refactoring code refactoring] is to take a code base and improve its readability, [http://en.wikipedia.org/wiki/Extensibility extensibility], and [http://en.wikipedia.org/wiki/Reusability reusability]. The practice is focused on having a better quality and more standardized code base, and not on fixing bugs or changing functionality.

In their Refactoring book<ref name="Refactoring book">http://books.google.com/books?id=1MsETFPD3I0C</ref>, Martin Fowler and Kent Beck define refactoring as 'A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior… It is a disciplined way to clean up code that minimizes the chances of introducing bugs'.

Refactoring has its difficulties, whether or not it is done using an [http://en.wikipedia.org/wiki/Integrated_development_environment IDE] or whether it is done by hand. There are lots of errors that can be made during refactoring, so it is pertinent to determine when it is necessary to refactor. Code metrics are one method used to determine how badly a file needs refactoring.

Two main types of refactoring are <ref>http://web.cecs.pdx.edu/~black/publications/IEEESoftwareRefact.pdf</ref>:
# Floss refactoring: refactoring performed regularly to keep code clean; gives healthy benefits in the long run
# Root canal refactoring: infrequent and protracted periods of refactoring; makes it painful and expensive (similar to dental analogy); mainly performed to clean unhealthy code

==Refactoring Techniques==
Before a coder performs a refactor, they must, either formally or informally, identify their ‘code smells’. A code smell refers to a negative quality of a code base that either implements bad programming practices or slows down code development or runtime. These aren't typically bugs, but can increase the chance of bugs later on if not fixed. Based on the type of code smell, a different refactoring technique is used to fix it.

===Duplicate Code===
Duplicate code can be a tricky concept when refactoring. Large sections of duplicated code can be easy to find and fixed by pulling it out and creating a single centralized method to call, however it is usually not that easy. Sometimes it may only be one or two lines of code that are duplicated which calls for an assessment of whether or not it is in the best interest to create a new method for a couple lines of code. Other times, code is not duplicate, rather it is similar enough that a generic method could be created to serve various purposes.
Some specific techniques to deal with this are:
*Extract Method / Pull-up Method
**If common code is used in multiple places, simply pull it out and make a method that can be called from all of the necessary places. Variables can be passed in if slight variations are needed between calls.
**If the code is used in various subclasses, put the common code in a method in the superclass, so that it can be seen and called by its children.<ref>http://www.refactoring.com/catalog/extractMethod.html Extract Method Example</ref>
Before Refactor
<pre>
class Cat
end

class Lion < Mammal
def likes
puts "Boxes"
end
end
class HouseCat < Mammal
def likes
puts "Boxes"
end
end
</pre>
After Pull Up Refactor
<pre>
class Cat
def likes
puts "Boxes"
end
end

class Lion < Mammal
end
class HouseCat < Mammal
end
</pre>

*Form Template Method
**If two methods in subclasses perform similar steps in the same order, but the steps are different, then get the steps into methods with the same signature, so that the original methods become the same. Then pull them up. <ref>http://www.refactoring.com/catalog/formTemplateMethod.html</ref>
Before Refactor
<pre>
class Cat
end
class Tiger < Cat
def live
puts “Wake up”
puts “Catch deer”
puts “Eat deer”
puts “Sleep in sun”
end
end
class HouseCat < Cat
def live
puts “Wake up”
puts “Wake human up”
puts “Eat food”
puts “Sleep in sun”
end
end
</pre>
After Form Template Refactor
<pre>
class Cat
def live
puts “Wake up”
do_morning_routine
puts “Sleep in the sun”
end
end
class Tiger < Cat
def do_morning_routine
puts “Catch deer”
puts “Eat deer”
end
end
class HouseCat < Cat
def do_morning_routine
puts “Wake human up”
puts “Eat food”
end
end
</pre>

===Large Method/Class===
If a project is not planned out well enough in advance, it is easy for methods and classes to become populated with excess functionality. While functionality of a block of code may be necessary for the project, the code block might not really pertain to the method or class it is included in.
*Extract Method
**This can be used when duplicate code occurs, as discussed above. But it can also be used when a method performs multiple functions that have the ability to be split up into various functions that serve a single purpose.
Before Refactoring
<pre>
def foo
puts "hey"
puts "how are you"
puts "bye!"
end
def bar
puts "bye!"
end
</pre>
After Extract Method Refactor
<pre>
def greet
puts "hey"
puts "how are you"
end
def farewell
puts "bye!"
end
def foo
greet
farewell
end
def bar
greet
end
</pre>
*Extract Class/Subclass/Superclass
**If there are class variables or methods that don’t directly pertain to a class, then it may be necessary to create a new class for those pieces.[http://www.refactoring.com/catalog/extractClass.html Example]
**If there are pieces of a class that are only for a specific subset of instances, then a subclass can be constructed to contain these.[http://www.refactoring.com/catalog/extractSubclass.html Example]
**If there are pieces that multiple classes use, then a superclass can be constructed to handle these generic functions, leaving the subclasses to deal with the remaining differences<ref>http://www.refactoring.com/catalog/extractSuperclass.html Example </ref>
Before Refactoring
<pre>
class Person
def initialize(f,m,l,s)
@firstName = f
@middleName = m
@lastName = l
@SSN = s
end
end
</pre>
After Extract Class Refactoring
<pre>

class FullName
def initialize(f,m,l)
@firstName = f
@middleName = m
@lastName = l
end
end

class Person
def initialize(f,m,l,s)
@name = FullName.new(f,m,l)
@SSN = s
end
end
</pre>

===Improving Readability and Clarity===
Many times, refactoring can be used to do simple, yet necessary changes like renaming variables, methods, or classes. As features get added to a project, classes tend to get charged with more uses than originally planned, so sometimes, the original naming scheme no longer applies and a new one needs to be instilled.

Moving methods and parameters around to where they have the best accessibility also has its uses. Classes also tend to be promoted or demoted to super and sub classes after their ultimate functional purpose is determined.

==Metrics==
It can be hard to decide whether or not to refactor, especially when it’s for something that appears to be working fine with just a surface level smell. Program analysis tools are used to derive various types of code metrics, which allow coders to identify problem areas and future pitfalls of their code base. These tools look at the code in several different ways, including the number of times a source file has been edited to help determine if it is a possible target of [feature envy], duplicate code structure to identify replicated lines, and block depths to suggest possible complexity issues.

===Code Climate===
[https://codeclimate.com Code Climate] is a hosted code metrics tool that analyzes projects in a multitdue of ways. It produces three main metric ratings with grades from A-F that comprise of the methods and classes contained in each file and project.
#Complexity Metric - This is based off of the Assignment, Branches, and Conditions ([http://c2.com/cgi/wiki?AbcMetric ABC]) metric, where the number of assignments, branches, and conditions are counted and analyzed. However, because Code Climate is constructed for Ruby programs, it also takes into account certain types of Ruby constructs that may increase the metric score, but are actually beneficial to the project.
#Duplication Metric - This looks at the syntax trees of the code in order to identify identical and similar code structures. Because the syntax trees are being analyzed, code formatting and different method and class names do not affect the score. <ref>https://codeclimate.com/docs#quality-metrics</ref>
#Churn Method - This integrates with the Git repository to look at the change history of the project’s files. Files with excessively high change histories have a tendency to have a high complexity rating as well, as they can be the result of feature envy, where extra functions are added into a file instead of being added to a new file with its own functionality.

===Open Source Ruby Metric Tools===
There are a variety of open source code metric tools that can be employed specifically for Ruby programs. [https://www.ruby-toolbox.com/categories/code_metrics The Ruby Toolbox] contains the most popular of these tools along with ratings.

[http://rubydoc.info/gems/simplecov/frames Simple Cov] is at the top of this list for code coverage. It was developed specifically to be of use to anyone using any framework. It integrates itself with the project’s own test cases to check the code coverage of them in addition to cucumber features.

For cyclomatic complexity (the number of possible paths), Saikuro is commonly employed and made to be easy to implement. For code complexity, Flog is the typical choice by the open source community of users.<ref>http://www.sitepoint.com/code-metrics-and-you/</ref>

==Getting Started with Refactoring==

===First step: Writing tests===
The first step in refactoring is writing solid set of tests for the section of code under consideration, in order to avoid introducing bugs. In Ruby, this can be done using [http://www.ruby-doc.org/stdlib-2.1.0/libdoc/test/unit/rdoc/Test/Unit.html Test::Unit] or [http://rspec.info/ Rspec]. Next step is to make small changes, test, make small changes, test again and so on<ref name='Refactoring Ruby Edition'>http://books.google.com/books?id=6jyOUrJBJHAC</ref>. This ensures that we can revert back to the working version of code if any small refactoring causes the application to stop working.

===When to refactor===
It is always confusing when to start refactoring. If either one of the following conditions is true, it is a good time to start refactoring code<ref name='Refactoring Ruby Edition'/>:
* The Rule of Three - If any code segment gives trouble more than two times, it is time to refactor it
* Adding new function - It might be helpful to refactor when adding new functionality as it would give better understanding of code. Sometimes, revisiting old design might help to accommodate new features better
* Fixing a bug - It is useful to refactor code which had a bug; this might save bug reports from the same piece of code in future
* During code review - Refactoring is useful during code reviews as it can be applied immediately making code reviews more fruitful
* Understanding other's code - If a new member joins the team and is asked to refactor existing code, it helps them to get a better understanding of the code base. It might take extra time to get them started, but trying to refactor will help them contribute to the project better in the long run.

A [http://blog.codeclimate.com/blog/2014/01/09/when-is-it-time-to-refactor/ CodeClimate blog] suggests some other conditions to decide when to refactor code.

===When NOT to refactor:===
* Avoid refactoring when you should ideally be rewriting the entire code. Although a tough call to make, rewriting is inevitable when current code does not work at all or is too buggy to stabilize.
* Avoid refactoring when close to a deadline since productivity gain by refactoring is mostly seen after the deadline and might just cause the project to miss the deadline.
* Avoid refactoring for academic purposes, i.e. avoid changing code in working condition because you do not agree with those lines of code or that is not how you would have implemented it.

==Automated Code Refactoring==
=== RubyMine ===
*[http://www.jetbrains.com/ruby/webhelp/refactoring.html RubyMine] has a built in refactoring menu.
*To perform refactoring, select a code fragment to refactor. Refactorings available for your selection appear under the Refactor Menu in RubyMine. <ref>http://www.jetbrains.com/ruby/webhelp/refactoring-source-code.html#common</ref> [[File:RubyMine_refactoring_menu.png]]

===RFactor ===
*[http://fabiokung.com/2009/02/04/rfactor-ruby-refactoring-for-your-loved-editor/ RFactor] is a Ruby gem, which aims to provide common and simple refactorings for Ruby code for text editors like TextMate
*The first release has only Extract method implemented while other refactorings are coming soon
*It is available on [http://github.com/fabiokung/rfactor-tmbundle/tree/master GitHub]

=== Other IDEs ===
*Some other IDEs with built-in refactoring include [http://www.aptana.com/products/studio3 Aptana Studio], [http://www.aptana.com/products/radrails Aptana RadRails] and [https://netbeans.org/features/ruby/index.html NetBeans 7] (which requires Ruby and Rails [http://plugins.netbeans.org/plugin/38549 plugin])
*A StackOverflow [http://stackoverflow.com/questions/8705144/ide-with-refactoring-support-for-ruby-on-rails post] compares these tools ranking them as RubyMine being the best, followed by NetBeans, RadRails 2 and Aptana Studio 3

==Further Reading==
*[http://en.wikipedia.org/wiki/Code_smell Ways to identify problems in code]

*[http://ghendry.net/refactor.html A description of smells with their techniques exists]

*[http://www.refactoring.com/catalog/index.html A list of techniques with examples in Ruby are listed]

*[http://blog.codeclimate.com/blog/2012/11/14/why-ruby-class-methods-resist-refactoring/ Resistance With Refactoring Ruby Class Methods]

*[http://www.railsinside.com/uncategorized/460-the-first-step-of-refactoring-a-rails-application.html Refactoring a Rails Application]

*[http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ Refactoring Fat Models]

*[https://speakerdeck.com/brianvh/refactoring-views-in-rails Talk on Refactoring Fat Views]

*[http://books.google.com/books?id=i6mZ0HBDPzsC Rails AntiPatterns: Best Practice Ruby on Rails Refactoring]

==References==
<references/>

CSC/ECE 517 Spring 2014/ch1a 1e rm

2014-02-19T05:37:05Z

Rjlloyd: /* Best Practices */

This page discusses refactoring techniques and metrics. It also includes tips on refactoring in Ruby and list of tools for automated refactoring.

For the page with a history of edits, go to [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2014/ch1a_1w1e_rm this page].

==Background==

The idea behind [http://en.wikipedia.org/wiki/Code_refactoring code refactoring] is to take a code base and improve its readability, [http://en.wikipedia.org/wiki/Extensibility extensibility], and [http://en.wikipedia.org/wiki/Reusability reusability]. The practice is focused on having a better quality and more standardized code base, and not on fixing bugs or changing functionality.

In their Refactoring book<ref name="Refactoring book">http://books.google.com/books?id=1MsETFPD3I0C</ref>, Martin Fowler and Kent Beck define refactoring as 'A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior… It is a disciplined way to clean up code that minimizes the chances of introducing bugs'.

Refactoring has its difficulties, whether or not it is done using an [http://en.wikipedia.org/wiki/Integrated_development_environment IDE] or whether it is done by hand. There are lots of errors that can be made during refactoring, so it is pertinent to determine when it is necessary to refactor. Code metrics are one method used to determine how badly a file needs refactoring.

Two main types of refactoring are <ref>http://web.cecs.pdx.edu/~black/publications/IEEESoftwareRefact.pdf</ref>:
# Floss refactoring: refactoring performed regularly to keep code clean; gives healthy benefits in the long run
# Root canal refactoring: infrequent and protracted periods of refactoring; makes it painful and expensive (similar to dental analogy); mainly performed to clean unhealthy code

==Refactoring Techniques==
Before a coder performs a refactor, they must, either formally or informally, identify their ‘code smells’. A code smell refers to a negative quality of a code base that either implements bad programming practices or slows down code development or runtime. These aren't typically bugs, but can increase the chance of bugs later on if not fixed. Based on the type of code smell, a different refactoring technique is used to fix it.

===Duplicate Code===
Duplicate code can be a tricky concept when refactoring. Large sections of duplicated code can be easy to find and fixed by pulling it out and creating a single centralized method to call, however it is usually not that easy. Sometimes it may only be one or two lines of code that are duplicated which calls for an assessment of whether or not it is in the best interest to create a new method for a couple lines of code. Other times, code is not duplicate, rather it is similar enough that a generic method could be created to serve various purposes.
Some specific techniques to deal with this are:
*Extract Method / Pull-up Method
**If common code is used in multiple places, simply pull it out and make a method that can be called from all of the necessary places. Variables can be passed in if slight variations are needed between calls.
**If the code is used in various subclasses, put the common code in a method in the superclass, so that it can be seen and called by its children.<ref>http://www.refactoring.com/catalog/extractMethod.html Extract Method Example</ref>
Before Refactor
<pre>
class Cat
end

class Lion < Mammal
def likes
puts "Boxes"
end
end
class HouseCat < Mammal
def likes
puts "Boxes"
end
end
</pre>
After Pull Up Refactor
<pre>
class Cat
def likes
puts "Boxes"
end
end

class Lion < Mammal
end
class HouseCat < Mammal
end
</pre>

*Form Template Method
**If two methods in subclasses perform similar steps in the same order, but the steps are different, then get the steps into methods with the same signature, so that the original methods become the same. Then pull them up. <ref>http://www.refactoring.com/catalog/formTemplateMethod.html</ref>
Before Refactor
<pre>
class Cat
end
class Tiger < Cat
def live
puts “Wake up”
puts “Catch deer”
puts “Eat deer”
puts “Sleep in sun”
end
end
class HouseCat < Cat
def live
puts “Wake up”
puts “Wake human up”
puts “Eat food”
puts “Sleep in sun”
end
end
</pre>
After Form Template Refactor
<pre>
class Cat
def live
puts “Wake up”
do_morning_routine
puts “Sleep in the sun”
end
end
class Tiger < Cat
def do_morning_routine
puts “Catch deer”
puts “Eat deer”
end
end
class HouseCat < Cat
def do_morning_routine
puts “Wake human up”
puts “Eat food”
end
end
</pre>

===Large Method/Class===
If a project is not planned out well enough in advance, it is easy for methods and classes to become populated with excess functionality. While functionality of a block of code may be necessary for the project, the code block might not really pertain to the method or class it is included in.
*Extract Method
**This can be used when duplicate code occurs, as discussed above. But it can also be used when a method performs multiple functions that have the ability to be split up into various functions that serve a single purpose.
Before Refactoring
<pre>
def foo
puts "hey"
puts "how are you"
puts "bye!"
end
def bar
puts "bye!"
end
</pre>
After Extract Method Refactor
<pre>
def greet
puts "hey"
puts "how are you"
end
def farewell
puts "bye!"
end
def foo
greet
farewell
end
def bar
greet
end
</pre>
*Extract Class/Subclass/Superclass
**If there are class variables or methods that don’t directly pertain to a class, then it may be necessary to create a new class for those pieces.[http://www.refactoring.com/catalog/extractClass.html Example]
**If there are pieces of a class that are only for a specific subset of instances, then a subclass can be constructed to contain these.[http://www.refactoring.com/catalog/extractSubclass.html Example]
**If there are pieces that multiple classes use, then a superclass can be constructed to handle these generic functions, leaving the subclasses to deal with the remaining differences<ref>http://www.refactoring.com/catalog/extractSuperclass.html Example </ref>
Before Refactoring
<pre>
class Person
def initialize(f,m,l,s)
@firstName = f
@middleName = m
@lastName = l
@SSN = s
end
end
</pre>
After Extract Class Refactoring
<pre>

class FullName
def initialize(f,m,l)
@firstName = f
@middleName = m
@lastName = l
end
end

class Person
def initialize(f,m,l,s)
@name = FullName.new(f,m,l)
@SSN = s
end
end
</pre>

===Improving Readability and Clarity===
Many times, refactoring can be used to do simple, yet necessary changes like renaming variables, methods, or classes. As features get added to a project, classes tend to get charged with more uses than originally planned, so sometimes, the original naming scheme no longer applies and a new one needs to be instilled.

Moving methods and parameters around to where they have the best accessibility also has its uses. Classes also tend to be promoted or demoted to super and sub classes after their ultimate functional purpose is determined.

===More Techniques===
There many more techniques than those that are listed above. Each has its specific purpose, though one must take care to make sure that it is a necessary refactoring.

==Metrics==
It can be hard to decide whether or not to refactor, especially when it’s for something that appears to be working fine with just a surface level smell. Program analysis tools are used to derive various types of code metrics, which allow coders to identify problem areas and future pitfalls of their code base. These tools look at the code in several different ways, including the number of times a source file has been edited to help determine if it is a possible target of [feature envy], duplicate code structure to identify replicated lines, and block depths to suggest possible complexity issues.

===Code Climate===
[https://codeclimate.com Code Climate] is a hosted code metrics tool that analyzes projects in a multitdue of ways. It produces three main metric ratings with grades from A-F that comprise of the methods and classes contained in each file and project.
#Complexity Metric - This is based off of the Assignment, Branches, and Conditions ([http://c2.com/cgi/wiki?AbcMetric ABC]) metric, where the number of assignments, branches, and conditions are counted and analyzed. However, because Code Climate is constructed for Ruby programs, it also takes into account certain types of Ruby constructs that may increase the metric score, but are actually beneficial to the project.
#Duplication Metric - This looks at the syntax trees of the code in order to identify identical and similar code structures. Because the syntax trees are being analyzed, code formatting and different method and class names do not affect the score. <ref>https://codeclimate.com/docs#quality-metrics</ref>
#Churn Method - This integrates with the Git repository to look at the change history of the project’s files. Files with excessively high change histories have a tendency to have a high complexity rating as well, as they can be the result of feature envy, where extra functions are added into a file instead of being added to a new file with its own functionality.

===Open Source Ruby Metric Tools===
There are a variety of open source code metric tools that can be employed specifically for Ruby programs. [https://www.ruby-toolbox.com/categories/code_metrics The Ruby Toolbox] contains the most popular of these tools along with ratings.

[http://rubydoc.info/gems/simplecov/frames Simple Cov] is at the top of this list for code coverage. It was developed specifically to be of use to anyone using any framework. It integrates itself with the project’s own test cases to check the code coverage of them in addition to cucumber features.

For cyclomatic complexity (the number of possible paths), Saikuro is commonly employed and made to be easy to implement. For code complexity, Flog is the typical choice by the open source community of users.<ref>http://www.sitepoint.com/code-metrics-and-you/</ref>

==Getting Started with Refactoring==

===First step: Writing tests===
The first step in refactoring is writing solid set of tests for the section of code under consideration, in order to avoid introducing bugs. In Ruby, this can be done using [http://www.ruby-doc.org/stdlib-2.1.0/libdoc/test/unit/rdoc/Test/Unit.html Test::Unit] or [http://rspec.info/ Rspec]. Next step is to make small changes, test, make small changes, test again and so on<ref name='Refactoring Ruby Edition'>http://books.google.com/books?id=6jyOUrJBJHAC</ref>. This ensures that we can revert back to the working version of code if any small refactoring causes the application to stop working.

===When to refactor===
It is always confusing when to start refactoring. If either one of the following conditions is true, it is a good time to start refactoring code<ref name='Refactoring Ruby Edition'/>:
* The Rule of Three - If any code segment gives trouble more than two times, it is time to refactor it
* Adding new function - It might be helpful to refactor when adding new functionality as it would give better understanding of code. Sometimes, revisiting old design might help to accommodate new features better
* Fixing a bug - It is useful to refactor code which had a bug; this might save bug reports from the same piece of code in future
* During code review - Refactoring is useful during code reviews as it can be applied immediately making code reviews more fruitful
* Understanding other's code - If a new member joins the team and is asked to refactor existing code, it helps them to get a better understanding of the code base. It might take extra time to get them started, but trying to refactor will help them contribute to the project better in the long run.

A [http://blog.codeclimate.com/blog/2014/01/09/when-is-it-time-to-refactor/ CodeClimate blog] suggests some other conditions to decide when to refactor code.

===When NOT to refactor:===
* Avoid refactoring when you should ideally be rewriting the entire code. Although a tough call to make, rewriting is inevitable when current code does not work at all or is too buggy to stabilize.
* Avoid refactoring when close to a deadline since productivity gain by refactoring is mostly seen after the deadline and might just cause the project to miss the deadline.
* Avoid refactoring for academic purposes, i.e. avoid changing code in working condition because you do not agree with those lines of code or that is not how you would have implemented it.

==Automated Code Refactoring==
=== RubyMine ===
*[http://www.jetbrains.com/ruby/webhelp/refactoring.html RubyMine] has a built in refactoring menu.
*To perform refactoring, select a code fragment to refactor. Refactorings available for your selection appear under the Refactor Menu in RubyMine. <ref>http://www.jetbrains.com/ruby/webhelp/refactoring-source-code.html#common</ref> [[File:RubyMine_refactoring_menu.png]]

===RFactor ===
*[http://fabiokung.com/2009/02/04/rfactor-ruby-refactoring-for-your-loved-editor/ RFactor] is a Ruby gem, which aims to provide common and simple refactorings for Ruby code for text editors like TextMate
*The first release has only Extract method implemented while other refactorings are coming soon
*It is available on [http://github.com/fabiokung/rfactor-tmbundle/tree/master GitHub]

=== Other IDEs ===
*Some other IDEs with built-in refactoring include [http://www.aptana.com/products/studio3 Aptana Studio], [http://www.aptana.com/products/radrails Aptana RadRails] and [https://netbeans.org/features/ruby/index.html NetBeans 7] (which requires Ruby and Rails [http://plugins.netbeans.org/plugin/38549 plugin])
*A StackOverflow [http://stackoverflow.com/questions/8705144/ide-with-refactoring-support-for-ruby-on-rails post] compares these tools ranking them as RubyMine being the best, followed by NetBeans, RadRails 2 and Aptana Studio 3

==Further Reading==
*[http://en.wikipedia.org/wiki/Code_smell Ways to identify problems in code]

*[http://ghendry.net/refactor.html A description of smells with their techniques exists]

*[http://www.refactoring.com/catalog/index.html A list of techniques with examples in Ruby are listed]

*[http://blog.codeclimate.com/blog/2012/11/14/why-ruby-class-methods-resist-refactoring/ Resistance With Refactoring Ruby Class Methods]

*[http://www.railsinside.com/uncategorized/460-the-first-step-of-refactoring-a-rails-application.html Refactoring a Rails Application]

*[http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ Refactoring Fat Models]

*[https://speakerdeck.com/brianvh/refactoring-views-in-rails Talk on Refactoring Fat Views]

*[http://books.google.com/books?id=i6mZ0HBDPzsC Rails AntiPatterns: Best Practice Ruby on Rails Refactoring]

==References==
<references/>

CSC/ECE 517 Spring 2014/ch1a 1e rm

2014-02-19T05:32:08Z

Rjlloyd: /* Metrics */

This page discusses refactoring techniques and metrics. It also includes tips on refactoring in Ruby and list of tools for automated refactoring.

For the page with a history of edits, go to [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2014/ch1a_1w1e_rm this page].

==Background==

The idea behind [http://en.wikipedia.org/wiki/Code_refactoring code refactoring] is to take a code base and improve its readability, [http://en.wikipedia.org/wiki/Extensibility extensibility], and [http://en.wikipedia.org/wiki/Reusability reusability]. The practice is focused on having a better quality and more standardized code base, and not on fixing bugs or changing functionality.

In their Refactoring book<ref name="Refactoring book">http://books.google.com/books?id=1MsETFPD3I0C</ref>, Martin Fowler and Kent Beck define refactoring as 'A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior… It is a disciplined way to clean up code that minimizes the chances of introducing bugs'.

Refactoring has its difficulties, whether or not it is done using an [http://en.wikipedia.org/wiki/Integrated_development_environment IDE] or whether it is done by hand. There are lots of errors that can be made during refactoring, so it is pertinent to determine when it is necessary to refactor. Code metrics are one method used to determine how badly a file needs refactoring.

Two main types of refactoring are <ref>http://web.cecs.pdx.edu/~black/publications/IEEESoftwareRefact.pdf</ref>:
# Floss refactoring: refactoring performed regularly to keep code clean; gives healthy benefits in the long run
# Root canal refactoring: infrequent and protracted periods of refactoring; makes it painful and expensive (similar to dental analogy); mainly performed to clean unhealthy code

==Refactoring Techniques==
Before a coder performs a refactor, they must, either formally or informally, identify their ‘code smells’. A code smell refers to a negative quality of a code base that either implements bad programming practices or slows down code development or runtime. These aren't typically bugs, but can increase the chance of bugs later on if not fixed. Based on the type of code smell, a different refactoring technique is used to fix it.

===Duplicate Code===
Duplicate code can be a tricky concept when refactoring. Large sections of duplicated code can be easy to find and fixed by pulling it out and creating a single centralized method to call, however it is usually not that easy. Sometimes it may only be one or two lines of code that are duplicated which calls for an assessment of whether or not it is in the best interest to create a new method for a couple lines of code. Other times, code is not duplicate, rather it is similar enough that a generic method could be created to serve various purposes.
Some specific techniques to deal with this are:
*Extract Method / Pull-up Method
**If common code is used in multiple places, simply pull it out and make a method that can be called from all of the necessary places. Variables can be passed in if slight variations are needed between calls.
**If the code is used in various subclasses, put the common code in a method in the superclass, so that it can be seen and called by its children.<ref>http://www.refactoring.com/catalog/extractMethod.html Extract Method Example</ref>
Before Refactor
<pre>
class Cat
end

class Lion < Mammal
def likes
puts "Boxes"
end
end
class HouseCat < Mammal
def likes
puts "Boxes"
end
end
</pre>
After Pull Up Refactor
<pre>
class Cat
def likes
puts "Boxes"
end
end

class Lion < Mammal
end
class HouseCat < Mammal
end
</pre>

*Form Template Method
**If two methods in subclasses perform similar steps in the same order, but the steps are different, then get the steps into methods with the same signature, so that the original methods become the same. Then pull them up. <ref>http://www.refactoring.com/catalog/formTemplateMethod.html</ref>
Before Refactor
<pre>
class Cat
end
class Tiger < Cat
def live
puts “Wake up”
puts “Catch deer”
puts “Eat deer”
puts “Sleep in sun”
end
end
class HouseCat < Cat
def live
puts “Wake up”
puts “Wake human up”
puts “Eat food”
puts “Sleep in sun”
end
end
</pre>
After Form Template Refactor
<pre>
class Cat
def live
puts “Wake up”
do_morning_routine
puts “Sleep in the sun”
end
end
class Tiger < Cat
def do_morning_routine
puts “Catch deer”
puts “Eat deer”
end
end
class HouseCat < Cat
def do_morning_routine
puts “Wake human up”
puts “Eat food”
end
end
</pre>

===Large Method/Class===
If a project is not planned out well enough in advance, it is easy for methods and classes to become populated with excess functionality. While functionality of a block of code may be necessary for the project, the code block might not really pertain to the method or class it is included in.
*Extract Method
**This can be used when duplicate code occurs, as discussed above. But it can also be used when a method performs multiple functions that have the ability to be split up into various functions that serve a single purpose.
Before Refactoring
<pre>
def foo
puts "hey"
puts "how are you"
puts "bye!"
end
def bar
puts "bye!"
end
</pre>
After Extract Method Refactor
<pre>
def greet
puts "hey"
puts "how are you"
end
def farewell
puts "bye!"
end
def foo
greet
farewell
end
def bar
greet
end
</pre>
*Extract Class/Subclass/Superclass
**If there are class variables or methods that don’t directly pertain to a class, then it may be necessary to create a new class for those pieces.[http://www.refactoring.com/catalog/extractClass.html Example]
**If there are pieces of a class that are only for a specific subset of instances, then a subclass can be constructed to contain these.[http://www.refactoring.com/catalog/extractSubclass.html Example]
**If there are pieces that multiple classes use, then a superclass can be constructed to handle these generic functions, leaving the subclasses to deal with the remaining differences<ref>http://www.refactoring.com/catalog/extractSuperclass.html Example </ref>
Before Refactoring
<pre>
class Person
def initialize(f,m,l,s)
@firstName = f
@middleName = m
@lastName = l
@SSN = s
end
end
</pre>
After Extract Class Refactoring
<pre>

class FullName
def initialize(f,m,l)
@firstName = f
@middleName = m
@lastName = l
end
end

class Person
def initialize(f,m,l,s)
@name = FullName.new(f,m,l)
@SSN = s
end
end
</pre>

===Improving Readability and Clarity===
Many times, refactoring can be used to do simple, yet necessary changes like renaming variables, methods, or classes. As features get added to a project, classes tend to get charged with more uses than originally planned, so sometimes, the original naming scheme no longer applies and a new one needs to be instilled.

Moving methods and parameters around to where they have the best accessibility also has its uses. Classes also tend to be promoted or demoted to super and sub classes after their ultimate functional purpose is determined.

===More Techniques===
There many more techniques than those that are listed above. Each has its specific purpose, though one must take care to make sure that it is a necessary refactoring.

==Metrics==
It can be hard to decide whether or not to refactor, especially when it’s for something that appears to be working fine with just a surface level smell. Program analysis tools are used to derive various types of code metrics, which allow coders to identify problem areas and future pitfalls of their code base. These tools look at the code in several different ways, including the number of times a source file has been edited to help determine if it is a possible target of [feature envy], duplicate code structure to identify replicated lines, and block depths to suggest possible complexity issues.

===Code Climate===
[https://codeclimate.com Code Climate] is a hosted code metrics tool that analyzes projects in a multitdue of ways. It produces three main metric ratings with grades from A-F that comprise of the methods and classes contained in each file and project.
#Complexity Metric - This is based off of the Assignment, Branches, and Conditions ([http://c2.com/cgi/wiki?AbcMetric ABC]) metric, where the number of assignments, branches, and conditions are counted and analyzed. However, because Code Climate is constructed for Ruby programs, it also takes into account certain types of Ruby constructs that may increase the metric score, but are actually beneficial to the project.
#Duplication Metric - This looks at the syntax trees of the code in order to identify identical and similar code structures. Because the syntax trees are being analyzed, code formatting and different method and class names do not affect the score. <ref>https://codeclimate.com/docs#quality-metrics</ref>
#Churn Method - This integrates with the Git repository to look at the change history of the project’s files. Files with excessively high change histories have a tendency to have a high complexity rating as well, as they can be the result of feature envy, where extra functions are added into a file instead of being added to a new file with its own functionality.

===Open Source Ruby Metric Tools===
There are a variety of open source code metric tools that can be employed specifically for Ruby programs. [https://www.ruby-toolbox.com/categories/code_metrics The Ruby Toolbox] contains the most popular of these tools along with ratings.

[http://rubydoc.info/gems/simplecov/frames Simple Cov] is at the top of this list for code coverage. It was developed specifically to be of use to anyone using any framework. It integrates itself with the project’s own test cases to check the code coverage of them in addition to cucumber features.

For cyclomatic complexity (the number of possible paths), Saikuro is commonly employed and made to be easy to implement. For code complexity, Flog is the typical choice by the open source community of users.<ref>http://www.sitepoint.com/code-metrics-and-you/</ref>

===Best Practices===
Because

==Getting Started with Refactoring==

===First step: Writing tests===
The first step in refactoring is writing solid set of tests for the section of code under consideration, in order to avoid introducing bugs. In Ruby, this can be done using [http://www.ruby-doc.org/stdlib-2.1.0/libdoc/test/unit/rdoc/Test/Unit.html Test::Unit] or [http://rspec.info/ Rspec]. Next step is to make small changes, test, make small changes, test again and so on<ref name='Refactoring Ruby Edition'>http://books.google.com/books?id=6jyOUrJBJHAC</ref>. This ensures that we can revert back to the working version of code if any small refactoring causes the application to stop working.

===When to refactor===
It is always confusing when to start refactoring. If either one of the following conditions is true, it is a good time to start refactoring code<ref name='Refactoring Ruby Edition'/>:
* The Rule of Three - If any code segment gives trouble more than two times, it is time to refactor it
* Adding new function - It might be helpful to refactor when adding new functionality as it would give better understanding of code. Sometimes, revisiting old design might help to accommodate new features better
* Fixing a bug - It is useful to refactor code which had a bug; this might save bug reports from the same piece of code in future
* During code review - Refactoring is useful during code reviews as it can be applied immediately making code reviews more fruitful
* Understanding other's code - If a new member joins the team and is asked to refactor existing code, it helps them to get a better understanding of the code base. It might take extra time to get them started, but trying to refactor will help them contribute to the project better in the long run.

A [http://blog.codeclimate.com/blog/2014/01/09/when-is-it-time-to-refactor/ CodeClimate blog] suggests some other conditions to decide when to refactor code.

===When NOT to refactor:===
* Avoid refactoring when you should ideally be rewriting the entire code. Although a tough call to make, rewriting is inevitable when current code does not work at all or is too buggy to stabilize.
* Avoid refactoring when close to a deadline since productivity gain by refactoring is mostly seen after the deadline and might just cause the project to miss the deadline.
* Avoid refactoring for academic purposes, i.e. avoid changing code in working condition because you do not agree with those lines of code or that is not how you would have implemented it.

==Automated Code Refactoring==
=== RubyMine ===
*[http://www.jetbrains.com/ruby/webhelp/refactoring.html RubyMine] has a built in refactoring menu.
*To perform refactoring, select a code fragment to refactor. Refactorings available for your selection appear under the Refactor Menu in RubyMine. <ref>http://www.jetbrains.com/ruby/webhelp/refactoring-source-code.html#common</ref> [[File:RubyMine_refactoring_menu.png]]

===RFactor ===
*[http://fabiokung.com/2009/02/04/rfactor-ruby-refactoring-for-your-loved-editor/ RFactor] is a Ruby gem, which aims to provide common and simple refactorings for Ruby code for text editors like TextMate
*The first release has only Extract method implemented while other refactorings are coming soon
*It is available on [http://github.com/fabiokung/rfactor-tmbundle/tree/master GitHub]

=== Other IDEs ===
*Some other IDEs with built-in refactoring include [http://www.aptana.com/products/studio3 Aptana Studio], [http://www.aptana.com/products/radrails Aptana RadRails] and [https://netbeans.org/features/ruby/index.html NetBeans 7] (which requires Ruby and Rails [http://plugins.netbeans.org/plugin/38549 plugin])
*A StackOverflow [http://stackoverflow.com/questions/8705144/ide-with-refactoring-support-for-ruby-on-rails post] compares these tools ranking them as RubyMine being the best, followed by NetBeans, RadRails 2 and Aptana Studio 3

==Further Reading==
*[http://en.wikipedia.org/wiki/Code_smell Ways to identify problems in code]

*[http://ghendry.net/refactor.html A description of smells with their techniques exists]

*[http://www.refactoring.com/catalog/index.html A list of techniques with examples in Ruby are listed]

*[http://blog.codeclimate.com/blog/2012/11/14/why-ruby-class-methods-resist-refactoring/ Resistance With Refactoring Ruby Class Methods]

*[http://www.railsinside.com/uncategorized/460-the-first-step-of-refactoring-a-rails-application.html Refactoring a Rails Application]

*[http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ Refactoring Fat Models]

*[https://speakerdeck.com/brianvh/refactoring-views-in-rails Talk on Refactoring Fat Views]

*[http://books.google.com/books?id=i6mZ0HBDPzsC Rails AntiPatterns: Best Practice Ruby on Rails Refactoring]

==References==
<references/>

CSC/ECE 517 Spring 2014/ch1a 1e rm

2014-02-19T05:31:47Z

Rjlloyd: /* Metrics */

This page discusses refactoring techniques and metrics. It also includes tips on refactoring in Ruby and list of tools for automated refactoring.

For the page with a history of edits, go to [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2014/ch1a_1w1e_rm this page].

==Background==

The idea behind [http://en.wikipedia.org/wiki/Code_refactoring code refactoring] is to take a code base and improve its readability, [http://en.wikipedia.org/wiki/Extensibility extensibility], and [http://en.wikipedia.org/wiki/Reusability reusability]. The practice is focused on having a better quality and more standardized code base, and not on fixing bugs or changing functionality.

In their Refactoring book<ref name="Refactoring book">http://books.google.com/books?id=1MsETFPD3I0C</ref>, Martin Fowler and Kent Beck define refactoring as 'A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior… It is a disciplined way to clean up code that minimizes the chances of introducing bugs'.

Refactoring has its difficulties, whether or not it is done using an [http://en.wikipedia.org/wiki/Integrated_development_environment IDE] or whether it is done by hand. There are lots of errors that can be made during refactoring, so it is pertinent to determine when it is necessary to refactor. Code metrics are one method used to determine how badly a file needs refactoring.

Two main types of refactoring are <ref>http://web.cecs.pdx.edu/~black/publications/IEEESoftwareRefact.pdf</ref>:
# Floss refactoring: refactoring performed regularly to keep code clean; gives healthy benefits in the long run
# Root canal refactoring: infrequent and protracted periods of refactoring; makes it painful and expensive (similar to dental analogy); mainly performed to clean unhealthy code

==Refactoring Techniques==
Before a coder performs a refactor, they must, either formally or informally, identify their ‘code smells’. A code smell refers to a negative quality of a code base that either implements bad programming practices or slows down code development or runtime. These aren't typically bugs, but can increase the chance of bugs later on if not fixed. Based on the type of code smell, a different refactoring technique is used to fix it.

===Duplicate Code===
Duplicate code can be a tricky concept when refactoring. Large sections of duplicated code can be easy to find and fixed by pulling it out and creating a single centralized method to call, however it is usually not that easy. Sometimes it may only be one or two lines of code that are duplicated which calls for an assessment of whether or not it is in the best interest to create a new method for a couple lines of code. Other times, code is not duplicate, rather it is similar enough that a generic method could be created to serve various purposes.
Some specific techniques to deal with this are:
*Extract Method / Pull-up Method
**If common code is used in multiple places, simply pull it out and make a method that can be called from all of the necessary places. Variables can be passed in if slight variations are needed between calls.
**If the code is used in various subclasses, put the common code in a method in the superclass, so that it can be seen and called by its children.<ref>http://www.refactoring.com/catalog/extractMethod.html Extract Method Example</ref>
Before Refactor
<pre>
class Cat
end

class Lion < Mammal
def likes
puts "Boxes"
end
end
class HouseCat < Mammal
def likes
puts "Boxes"
end
end
</pre>
After Pull Up Refactor
<pre>
class Cat
def likes
puts "Boxes"
end
end

class Lion < Mammal
end
class HouseCat < Mammal
end
</pre>

*Form Template Method
**If two methods in subclasses perform similar steps in the same order, but the steps are different, then get the steps into methods with the same signature, so that the original methods become the same. Then pull them up. <ref>http://www.refactoring.com/catalog/formTemplateMethod.html</ref>
Before Refactor
<pre>
class Cat
end
class Tiger < Cat
def live
puts “Wake up”
puts “Catch deer”
puts “Eat deer”
puts “Sleep in sun”
end
end
class HouseCat < Cat
def live
puts “Wake up”
puts “Wake human up”
puts “Eat food”
puts “Sleep in sun”
end
end
</pre>
After Form Template Refactor
<pre>
class Cat
def live
puts “Wake up”
do_morning_routine
puts “Sleep in the sun”
end
end
class Tiger < Cat
def do_morning_routine
puts “Catch deer”
puts “Eat deer”
end
end
class HouseCat < Cat
def do_morning_routine
puts “Wake human up”
puts “Eat food”
end
end
</pre>

===Large Method/Class===
If a project is not planned out well enough in advance, it is easy for methods and classes to become populated with excess functionality. While functionality of a block of code may be necessary for the project, the code block might not really pertain to the method or class it is included in.
*Extract Method
**This can be used when duplicate code occurs, as discussed above. But it can also be used when a method performs multiple functions that have the ability to be split up into various functions that serve a single purpose.
Before Refactoring
<pre>
def foo
puts "hey"
puts "how are you"
puts "bye!"
end
def bar
puts "bye!"
end
</pre>
After Extract Method Refactor
<pre>
def greet
puts "hey"
puts "how are you"
end
def farewell
puts "bye!"
end
def foo
greet
farewell
end
def bar
greet
end
</pre>
*Extract Class/Subclass/Superclass
**If there are class variables or methods that don’t directly pertain to a class, then it may be necessary to create a new class for those pieces.[http://www.refactoring.com/catalog/extractClass.html Example]
**If there are pieces of a class that are only for a specific subset of instances, then a subclass can be constructed to contain these.[http://www.refactoring.com/catalog/extractSubclass.html Example]
**If there are pieces that multiple classes use, then a superclass can be constructed to handle these generic functions, leaving the subclasses to deal with the remaining differences<ref>http://www.refactoring.com/catalog/extractSuperclass.html Example </ref>
Before Refactoring
<pre>
class Person
def initialize(f,m,l,s)
@firstName = f
@middleName = m
@lastName = l
@SSN = s
end
end
</pre>
After Extract Class Refactoring
<pre>

class FullName
def initialize(f,m,l)
@firstName = f
@middleName = m
@lastName = l
end
end

class Person
def initialize(f,m,l,s)
@name = FullName.new(f,m,l)
@SSN = s
end
end
</pre>

===Improving Readability and Clarity===
Many times, refactoring can be used to do simple, yet necessary changes like renaming variables, methods, or classes. As features get added to a project, classes tend to get charged with more uses than originally planned, so sometimes, the original naming scheme no longer applies and a new one needs to be instilled.

Moving methods and parameters around to where they have the best accessibility also has its uses. Classes also tend to be promoted or demoted to super and sub classes after their ultimate functional purpose is determined.

===More Techniques===
There many more techniques than those that are listed above. Each has its specific purpose, though one must take care to make sure that it is a necessary refactoring.

==Metrics==
It can be hard to decide whether or not to refactor, especially when it’s for something that appears to be working fine with just a surface level smell. Program analysis tools are used to derive various types of code metrics, which allow coders to identify problem areas and future pitfalls of their code base. These tools look at the code in several different ways, including the number of times a source file has been edited to help determine if it is a possible target of [feature envy], duplicate code structure to identify replicated lines, and block depths to suggest possible complexity issues.

===Open Source Ruby Metric Tools===
There are a variety of open source code metric tools that can be employed specifically for Ruby programs. [https://www.ruby-toolbox.com/categories/code_metrics The Ruby Toolbox] contains the most popular of these tools along with ratings.

[http://rubydoc.info/gems/simplecov/frames Simple Cov] is at the top of this list for code coverage. It was developed specifically to be of use to anyone using any framework. It integrates itself with the project’s own test cases to check the code coverage of them in addition to cucumber features.

For cyclomatic complexity (the number of possible paths), Saikuro is commonly employed and made to be easy to implement. For code complexity, Flog is the typical choice by the open source community of users.<ref>http://www.sitepoint.com/code-metrics-and-you/</ref>

===Code Climate===
[https://codeclimate.com Code Climate] is a hosted code metrics tool that analyzes projects in a multitdue of ways. It produces three main metric ratings with grades from A-F that comprise of the methods and classes contained in each file and project.
#Complexity Metric - This is based off of the Assignment, Branches, and Conditions ([http://c2.com/cgi/wiki?AbcMetric ABC]) metric, where the number of assignments, branches, and conditions are counted and analyzed. However, because Code Climate is constructed for Ruby programs, it also takes into account certain types of Ruby constructs that may increase the metric score, but are actually beneficial to the project.
#Duplication Metric - This looks at the syntax trees of the code in order to identify identical and similar code structures. Because the syntax trees are being analyzed, code formatting and different method and class names do not affect the score. <ref>https://codeclimate.com/docs#quality-metrics</ref>
#Churn Method - This integrates with the Git repository to look at the change history of the project’s files. Files with excessively high change histories have a tendency to have a high complexity rating as well, as they can be the result of feature envy, where extra functions are added into a file instead of being added to a new file with its own functionality.

===Best Practices===
Because

==Getting Started with Refactoring==

===First step: Writing tests===
The first step in refactoring is writing solid set of tests for the section of code under consideration, in order to avoid introducing bugs. In Ruby, this can be done using [http://www.ruby-doc.org/stdlib-2.1.0/libdoc/test/unit/rdoc/Test/Unit.html Test::Unit] or [http://rspec.info/ Rspec]. Next step is to make small changes, test, make small changes, test again and so on<ref name='Refactoring Ruby Edition'>http://books.google.com/books?id=6jyOUrJBJHAC</ref>. This ensures that we can revert back to the working version of code if any small refactoring causes the application to stop working.

===When to refactor===
It is always confusing when to start refactoring. If either one of the following conditions is true, it is a good time to start refactoring code<ref name='Refactoring Ruby Edition'/>:
* The Rule of Three - If any code segment gives trouble more than two times, it is time to refactor it
* Adding new function - It might be helpful to refactor when adding new functionality as it would give better understanding of code. Sometimes, revisiting old design might help to accommodate new features better
* Fixing a bug - It is useful to refactor code which had a bug; this might save bug reports from the same piece of code in future
* During code review - Refactoring is useful during code reviews as it can be applied immediately making code reviews more fruitful
* Understanding other's code - If a new member joins the team and is asked to refactor existing code, it helps them to get a better understanding of the code base. It might take extra time to get them started, but trying to refactor will help them contribute to the project better in the long run.

A [http://blog.codeclimate.com/blog/2014/01/09/when-is-it-time-to-refactor/ CodeClimate blog] suggests some other conditions to decide when to refactor code.

===When NOT to refactor:===
* Avoid refactoring when you should ideally be rewriting the entire code. Although a tough call to make, rewriting is inevitable when current code does not work at all or is too buggy to stabilize.
* Avoid refactoring when close to a deadline since productivity gain by refactoring is mostly seen after the deadline and might just cause the project to miss the deadline.
* Avoid refactoring for academic purposes, i.e. avoid changing code in working condition because you do not agree with those lines of code or that is not how you would have implemented it.

==Automated Code Refactoring==
=== RubyMine ===
*[http://www.jetbrains.com/ruby/webhelp/refactoring.html RubyMine] has a built in refactoring menu.
*To perform refactoring, select a code fragment to refactor. Refactorings available for your selection appear under the Refactor Menu in RubyMine. <ref>http://www.jetbrains.com/ruby/webhelp/refactoring-source-code.html#common</ref> [[File:RubyMine_refactoring_menu.png]]

===RFactor ===
*[http://fabiokung.com/2009/02/04/rfactor-ruby-refactoring-for-your-loved-editor/ RFactor] is a Ruby gem, which aims to provide common and simple refactorings for Ruby code for text editors like TextMate
*The first release has only Extract method implemented while other refactorings are coming soon
*It is available on [http://github.com/fabiokung/rfactor-tmbundle/tree/master GitHub]

=== Other IDEs ===
*Some other IDEs with built-in refactoring include [http://www.aptana.com/products/studio3 Aptana Studio], [http://www.aptana.com/products/radrails Aptana RadRails] and [https://netbeans.org/features/ruby/index.html NetBeans 7] (which requires Ruby and Rails [http://plugins.netbeans.org/plugin/38549 plugin])
*A StackOverflow [http://stackoverflow.com/questions/8705144/ide-with-refactoring-support-for-ruby-on-rails post] compares these tools ranking them as RubyMine being the best, followed by NetBeans, RadRails 2 and Aptana Studio 3

==Further Reading==
*[http://en.wikipedia.org/wiki/Code_smell Ways to identify problems in code]

*[http://ghendry.net/refactor.html A description of smells with their techniques exists]

*[http://www.refactoring.com/catalog/index.html A list of techniques with examples in Ruby are listed]

*[http://blog.codeclimate.com/blog/2012/11/14/why-ruby-class-methods-resist-refactoring/ Resistance With Refactoring Ruby Class Methods]

*[http://www.railsinside.com/uncategorized/460-the-first-step-of-refactoring-a-rails-application.html Refactoring a Rails Application]

*[http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ Refactoring Fat Models]

*[https://speakerdeck.com/brianvh/refactoring-views-in-rails Talk on Refactoring Fat Views]

*[http://books.google.com/books?id=i6mZ0HBDPzsC Rails AntiPatterns: Best Practice Ruby on Rails Refactoring]

==References==
<references/>

CSC/ECE 517 Spring 2014/ch1a 1e rm

2014-02-19T05:13:09Z

Rjlloyd: /* Code Climate */

This page discusses refactoring techniques and metrics. It also includes tips on refactoring in Ruby and list of tools for automated refactoring.

For the page with a history of edits, go to [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2014/ch1a_1w1e_rm this page].

==Background==

The idea behind [http://en.wikipedia.org/wiki/Code_refactoring code refactoring] is to take a code base and improve its readability, [http://en.wikipedia.org/wiki/Extensibility extensibility], and [http://en.wikipedia.org/wiki/Reusability reusability]. The practice is focused on having a better quality and more standardized code base, and not on fixing bugs or changing functionality.

In their Refactoring book<ref name="Refactoring book">http://books.google.com/books?id=1MsETFPD3I0C</ref>, Martin Fowler and Kent Beck define refactoring as 'A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior… It is a disciplined way to clean up code that minimizes the chances of introducing bugs'.

Refactoring has its difficulties, whether or not it is done using an [http://en.wikipedia.org/wiki/Integrated_development_environment IDE] or whether it is done by hand. There are lots of errors that can be made during refactoring, so it is pertinent to determine when it is necessary to refactor. Code metrics are one method used to determine how badly a file needs refactoring.

==Refactoring Techniques==
Before a coder performs a refactor, they must, either formally or informally, identify their ‘code smells’. A code smell refers to a negative quality of a code base that either implements bad programming practices or slows down code development or runtime. These aren't typically bugs, but can increase the chance of bugs later on if not fixed. Based on the type of code smell, a different refactoring technique is used to fix it.

===Duplicate Code===
Duplicate code can be a tricky concept when refactoring. Large sections of duplicated code can be easy to find and fixed by pulling it out and creating a single centralized method to call, however it is usually not that easy. Sometimes it may only be one or two lines of code that are duplicated which calls for an assessment of whether or not it is in the best interest to create a new method for a couple lines of code. Other times, code is not duplicate, rather it is similar enough that a generic method could be created to serve various purposes.
Some specific techniques to deal with this are:
*Extract Method / Pull-up Method
**If common code is used in multiple places, simply pull it out and make a method that can be called from all of the necessary places. Variables can be passed in if slight variations are needed between calls.
**If the code is used in various subclasses, put the common code in a method in the superclass, so that it can be seen and called by its children.<ref>http://www.refactoring.com/catalog/extractMethod.html Extract Method Example</ref>
Before Refactor
<pre>
class Cat
end

class Lion < Mammal
def likes
puts "Boxes"
end
end
class HouseCat < Mammal
def likes
puts "Boxes"
end
end
</pre>
After Pull Up Refactor
<pre>
class Cat
def likes
puts "Boxes"
end
end

class Lion < Mammal
end
class HouseCat < Mammal
end
</pre>

*Form Template Method
**If two methods in subclasses perform similar steps in the same order, but the steps are different, then get the steps into methods with the same signature, so that the original methods become the same. Then pull them up. <ref>http://www.refactoring.com/catalog/formTemplateMethod.html</ref>
Before Refactor
<pre>
class Cat
end
class Tiger < Cat
def live
puts “Wake up”
puts “Catch deer”
puts “Eat deer”
puts “Sleep in sun”
end
end
class HouseCat < Cat
def live
puts “Wake up”
puts “Wake human up”
puts “Eat food”
puts “Sleep in sun”
end
end
</pre>
After Form Template Refactor
<pre>
class Cat
def live
puts “Wake up”
do_morning_routine
puts “Sleep in the sun”
end
end
class Tiger < Cat
def do_morning_routine
puts “Catch deer”
puts “Eat deer”
end
end
class HouseCat < Cat
def do_morning_routine
puts “Wake human up”
puts “Eat food”
end
end
</pre>

===Large Method/Class===
If a project is not planned out well enough in advance, it is easy for methods and classes to become populated with excess functionality. While functionality of a block of code may be necessary for the project, the code block might not really pertain to the method or class it is included in.
*Extract Method
**This can be used when duplicate code occurs, as discussed above. But it can also be used when a method performs multiple functions that have the ability to be split up into various functions that serve a single purpose.
Before Refactoring
<pre>
def foo
puts "hey"
puts "how are you"
puts "bye!"
end
def bar
puts "bye!"
end
</pre>
After Extract Method Refactor
<pre>
def greet
puts "hey"
puts "how are you"
end
def farewell
puts "bye!"
end
def foo
greet
farewell
end
def bar
greet
end
</pre>
*Extract Class/Subclass/Superclass
**If there are class variables or methods that don’t directly pertain to a class, then it may be necessary to create a new class for those pieces.[http://www.refactoring.com/catalog/extractClass.html Example]
**If there are pieces of a class that are only for a specific subset of instances, then a subclass can be constructed to contain these.[http://www.refactoring.com/catalog/extractSubclass.html Example]
**If there are pieces that multiple classes use, then a superclass can be constructed to handle these generic functions, leaving the subclasses to deal with the remaining differences<ref>http://www.refactoring.com/catalog/extractSuperclass.html Example </ref>
Before Refactoring
<pre>
class Person
def initialize(f,m,l,s)
@firstName = f
@middleName = m
@lastName = l
@SSN = s
end
end
</pre>
After Extract Class Refactoring
<pre>

class FullName
def initialize(f,m,l)
@firstName = f
@middleName = m
@lastName = l
end
end

class Person
def initialize(f,m,l,s)
@name = FullName.new(f,m,l)
@SSN = s
end
end
</pre>

===Improving Readability and Clarity===
Many times, refactoring can be used to do simple, yet necessary changes like renaming variables, methods, or classes. As features get added to a project, classes tend to get charged with more uses than originally planned, so sometimes, the original naming scheme no longer applies and a new one needs to be instilled.

Moving methods and parameters around to where they have the best accessibility also has its uses. Classes also tend to be promoted or demoted to super and sub classes after their ultimate functional purpose is determined.

===More Techniques===
There many more techniques than those that are listed above. Each has its specific purpose, though one must take care to make sure that it is a necessary refactoring.

==Metrics==
It can be hard to decide whether or not to refactor, especially when it’s for something that appears to be working fine with just a surface level smell. Program analysis tools are used to derive various types of code metrics, which allow coders to identify problem areas and future pitfalls of their code base. These tools look at the code in several different ways, including the number of times a source file has been edited to help determine if it is a possible target of [feature envy], duplicate code structure to identify replicated lines, and block depths to suggest possible complexity issues.

===Open Source Ruby Metric Tools===
There are a variety of open source code metric tools that can be employed specifically for Ruby programs. [https://www.ruby-toolbox.com/categories/code_metrics The Ruby Toolbox] contains the most popular of these tools along with ratings.

[http://rubydoc.info/gems/simplecov/frames Simple Cov] is at the top of this list. It was developed specifically to be of use to anyone using any framework. It integrates itself with the project’s own test cases to check the code coverage of them in addition to cucumber features.

===Code Climate===
[https://codeclimate.com Code Climate] is a hosted code metrics tool that analyzes projects in a multitdue of ways. It produces three main metric ratings with grades from A-F that comprise of the methods and classes contained in each file and project.
#Complexity Metric - This is based off of the Assignment, Branches, and Conditions ([http://c2.com/cgi/wiki?AbcMetric ABC]) metric, where the number of assignments, branches, and conditions are counted and analyzed. However, because Code Climate is constructed for Ruby programs, it also takes into account certain types of Ruby constructs that may increase the metric score, but are actually beneficial to the project.
#Duplication Metric - This looks at the syntax trees of the code in order to identify identical and similar code structures. Because the syntax trees are being analyzed, code formatting and different method and class names do not affect the score. <ref>https://codeclimate.com/docs#quality-metrics</ref>
#Churn Method - This integrates with the Git repository to look at the change history of the project’s files. Files with excessively high change histories have a tendency to have a high complexity rating as well, as they can be the result of feature envy, where extra functions are added into a file instead of being added to a new file with its own functionality.

==Getting Started with Refactoring==

===First step: Writing tests===
The first step in refactoring is writing solid set of tests for the section of code under consideration, in order to avoid introducing bugs. In Ruby, this can be done using [http://www.ruby-doc.org/stdlib-2.1.0/libdoc/test/unit/rdoc/Test/Unit.html Test::Unit] or [http://rspec.info/ Rspec]. Next step is to make small changes, test, make small changes, test again and so on<ref name='Refactoring Ruby Edition'>http://books.google.com/books?id=6jyOUrJBJHAC</ref>. This ensures that we can revert back to the working version of code if any small refactoring causes the application to stop working.

===When to refactor===
It is always confusing when to start refactoring. If either one of the following conditions is true, it is a good time to start refactoring code<ref name='Refactoring Ruby Edition'/>:
* The Rule of Three - If any code segment gives trouble more than two times, it is time to refactor it
* Adding new function - It might be helpful to refactor when adding new functionality as it would give better understanding of code. Sometimes, revisiting old design might help to accommodate new features better
* Fixing a bug - It is useful to refactor code which had a bug; this might save bug reports from the same piece of code in future
* During code review - Refactoring is useful during code reviews as it can be applied immediately making code reviews more fruitful
* Understanding other's code - If a new member joins the team and is asked to refactor existing code, it helps them to get a better understanding of the code base. It might take extra time to get them started, but trying to refactor will help them contribute to the project better in the long run.

A [http://blog.codeclimate.com/blog/2014/01/09/when-is-it-time-to-refactor/ CodeClimate blog] suggests some other conditions to decide when to refactor code.

===When NOT to refactor:===
* Avoid refactoring when you should ideally be rewriting the entire code. Although a tough call to make, rewriting is inevitable when current code does not work at all or is too buggy to stabilize.
* Avoid refactoring when close to a deadline since productivity gain by refactoring is mostly seen after the deadline and might just cause the project to miss the deadline.
* Avoid refactoring for academic purposes, i.e. avoid changing code in working condition because you do not agree with those lines of code or that is not how you would have implemented it.

==Automated Code Refactoring==
=== RubyMine ===
*[http://www.jetbrains.com/ruby/webhelp/refactoring.html RubyMine] has a built in refactoring menu.
*To perform refactoring, select a code fragment to refactor. Refactorings available for your selection appear under the Refactor Menu in RubyMine. <ref>http://www.jetbrains.com/ruby/webhelp/refactoring-source-code.html#common</ref> [[File:RubyMine_refactoring_menu.png]]

===RFactor ===
*[http://fabiokung.com/2009/02/04/rfactor-ruby-refactoring-for-your-loved-editor/ RFactor] is a Ruby gem, which aims to provide common and simple refactorings for Ruby code for text editors like TextMate
*The first release has only Extract method implemented while other refactorings are coming soon
*It is available on [http://github.com/fabiokung/rfactor-tmbundle/tree/master GitHub]

=== Other IDEs ===
*Some other IDEs with built-in refactoring include [http://www.aptana.com/products/studio3 Aptana Studio], [http://www.aptana.com/products/radrails Aptana RadRails] and [https://netbeans.org/features/ruby/index.html NetBeans 7] (which requires Ruby and Rails [http://plugins.netbeans.org/plugin/38549 plugin])
*A StackOverflow [http://stackoverflow.com/questions/8705144/ide-with-refactoring-support-for-ruby-on-rails post] compares these tools ranking them as RubyMine being the best, followed by NetBeans, RadRails 2 and Aptana Studio 3

==Further Reading==
*[http://en.wikipedia.org/wiki/Code_smell Ways to identify problems in code]

*[http://ghendry.net/refactor.html A description of smells with their techniques exists]

*[http://www.refactoring.com/catalog/index.html A list of techniques with examples in Ruby are listed]

*[http://blog.codeclimate.com/blog/2012/11/14/why-ruby-class-methods-resist-refactoring/ Resistance With Refactoring Ruby Class Methods]

*[http://www.railsinside.com/uncategorized/460-the-first-step-of-refactoring-a-rails-application.html Refactoring a Rails Application]

*[http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ Refactoring Fat Models]

*[https://speakerdeck.com/brianvh/refactoring-views-in-rails Talk on Refactoring Fat Views]

*[http://books.google.com/books?id=i6mZ0HBDPzsC Rails AntiPatterns: Best Practice Ruby on Rails Refactoring]

==References==
<references/>

CSC/ECE 517 Spring 2014/ch1a 1e rm

2014-02-19T05:12:39Z

Rjlloyd: /* Background */

This page discusses refactoring techniques and metrics. It also includes tips on refactoring in Ruby and list of tools for automated refactoring.

For the page with a history of edits, go to [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2014/ch1a_1w1e_rm this page].

==Background==

The idea behind [http://en.wikipedia.org/wiki/Code_refactoring code refactoring] is to take a code base and improve its readability, [http://en.wikipedia.org/wiki/Extensibility extensibility], and [http://en.wikipedia.org/wiki/Reusability reusability]. The practice is focused on having a better quality and more standardized code base, and not on fixing bugs or changing functionality.

In their Refactoring book<ref name="Refactoring book">http://books.google.com/books?id=1MsETFPD3I0C</ref>, Martin Fowler and Kent Beck define refactoring as 'A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior… It is a disciplined way to clean up code that minimizes the chances of introducing bugs'.

Refactoring has its difficulties, whether or not it is done using an [http://en.wikipedia.org/wiki/Integrated_development_environment IDE] or whether it is done by hand. There are lots of errors that can be made during refactoring, so it is pertinent to determine when it is necessary to refactor. Code metrics are one method used to determine how badly a file needs refactoring.

==Refactoring Techniques==
Before a coder performs a refactor, they must, either formally or informally, identify their ‘code smells’. A code smell refers to a negative quality of a code base that either implements bad programming practices or slows down code development or runtime. These aren't typically bugs, but can increase the chance of bugs later on if not fixed. Based on the type of code smell, a different refactoring technique is used to fix it.

===Duplicate Code===
Duplicate code can be a tricky concept when refactoring. Large sections of duplicated code can be easy to find and fixed by pulling it out and creating a single centralized method to call, however it is usually not that easy. Sometimes it may only be one or two lines of code that are duplicated which calls for an assessment of whether or not it is in the best interest to create a new method for a couple lines of code. Other times, code is not duplicate, rather it is similar enough that a generic method could be created to serve various purposes.
Some specific techniques to deal with this are:
*Extract Method / Pull-up Method
**If common code is used in multiple places, simply pull it out and make a method that can be called from all of the necessary places. Variables can be passed in if slight variations are needed between calls.
**If the code is used in various subclasses, put the common code in a method in the superclass, so that it can be seen and called by its children.<ref>http://www.refactoring.com/catalog/extractMethod.html Extract Method Example</ref>
Before Refactor
<pre>
class Cat
end

class Lion < Mammal
def likes
puts "Boxes"
end
end
class HouseCat < Mammal
def likes
puts "Boxes"
end
end
</pre>
After Pull Up Refactor
<pre>
class Cat
def likes
puts "Boxes"
end
end

class Lion < Mammal
end
class HouseCat < Mammal
end
</pre>

*Form Template Method
**If two methods in subclasses perform similar steps in the same order, but the steps are different, then get the steps into methods with the same signature, so that the original methods become the same. Then pull them up. <ref>http://www.refactoring.com/catalog/formTemplateMethod.html</ref>
Before Refactor
<pre>
class Cat
end
class Tiger < Cat
def live
puts “Wake up”
puts “Catch deer”
puts “Eat deer”
puts “Sleep in sun”
end
end
class HouseCat < Cat
def live
puts “Wake up”
puts “Wake human up”
puts “Eat food”
puts “Sleep in sun”
end
end
</pre>
After Form Template Refactor
<pre>
class Cat
def live
puts “Wake up”
do_morning_routine
puts “Sleep in the sun”
end
end
class Tiger < Cat
def do_morning_routine
puts “Catch deer”
puts “Eat deer”
end
end
class HouseCat < Cat
def do_morning_routine
puts “Wake human up”
puts “Eat food”
end
end
</pre>

===Large Method/Class===
If a project is not planned out well enough in advance, it is easy for methods and classes to become populated with excess functionality. While functionality of a block of code may be necessary for the project, the code block might not really pertain to the method or class it is included in.
*Extract Method
**This can be used when duplicate code occurs, as discussed above. But it can also be used when a method performs multiple functions that have the ability to be split up into various functions that serve a single purpose.
Before Refactoring
<pre>
def foo
puts "hey"
puts "how are you"
puts "bye!"
end
def bar
puts "bye!"
end
</pre>
After Extract Method Refactor
<pre>
def greet
puts "hey"
puts "how are you"
end
def farewell
puts "bye!"
end
def foo
greet
farewell
end
def bar
greet
end
</pre>
*Extract Class/Subclass/Superclass
**If there are class variables or methods that don’t directly pertain to a class, then it may be necessary to create a new class for those pieces.[http://www.refactoring.com/catalog/extractClass.html Example]
**If there are pieces of a class that are only for a specific subset of instances, then a subclass can be constructed to contain these.[http://www.refactoring.com/catalog/extractSubclass.html Example]
**If there are pieces that multiple classes use, then a superclass can be constructed to handle these generic functions, leaving the subclasses to deal with the remaining differences<ref>http://www.refactoring.com/catalog/extractSuperclass.html Example </ref>
Before Refactoring
<pre>
class Person
def initialize(f,m,l,s)
@firstName = f
@middleName = m
@lastName = l
@SSN = s
end
end
</pre>
After Extract Class Refactoring
<pre>

class FullName
def initialize(f,m,l)
@firstName = f
@middleName = m
@lastName = l
end
end

class Person
def initialize(f,m,l,s)
@name = FullName.new(f,m,l)
@SSN = s
end
end
</pre>

===Improving Readability and Clarity===
Many times, refactoring can be used to do simple, yet necessary changes like renaming variables, methods, or classes. As features get added to a project, classes tend to get charged with more uses than originally planned, so sometimes, the original naming scheme no longer applies and a new one needs to be instilled.

Moving methods and parameters around to where they have the best accessibility also has its uses. Classes also tend to be promoted or demoted to super and sub classes after their ultimate functional purpose is determined.

===More Techniques===
There many more techniques than those that are listed above. Each has its specific purpose, though one must take care to make sure that it is a necessary refactoring.

==Metrics==
It can be hard to decide whether or not to refactor, especially when it’s for something that appears to be working fine with just a surface level smell. Program analysis tools are used to derive various types of code metrics, which allow coders to identify problem areas and future pitfalls of their code base. These tools look at the code in several different ways, including the number of times a source file has been edited to help determine if it is a possible target of [feature envy], duplicate code structure to identify replicated lines, and block depths to suggest possible complexity issues.

===Open Source Ruby Metric Tools===
There are a variety of open source code metric tools that can be employed specifically for Ruby programs. [https://www.ruby-toolbox.com/categories/code_metrics The Ruby Toolbox] contains the most popular of these tools along with ratings.

[http://rubydoc.info/gems/simplecov/frames Simple Cov] is at the top of this list. It was developed specifically to be of use to anyone using any framework. It integrates itself with the project’s own test cases to check the code coverage of them in addition to cucumber features.

===Code Climate===
[https://codeclimate.com Code Climate] is a hosted code metrics tool that analyzes projects in a multitdue of ways. It produces three main metric ratings with grades from A-F that comprise of the methods and classes contained in each file and project.
#Complexity Metric - This is based off of the Assignment, Branches, and Conditions ([http://c2.com/cgi/wiki?AbcMetric ABC]) metric, where the number of assignments, branches, and conditions are counted and analyzed. However, because Code Climate is constructed for Ruby programs, it also takes into account certain types of Ruby constructs that may increase the metric score, but are actually beneficial to the project.
#Duplication Metric - This looks at the syntax trees of the code in order to identify identical and similar code structures. Because the syntax trees are being analyzed, code formatting and different method and class names do not affect the score. <ref>https://codeclimate.com/docs#quality-metrics</ref>
#Churn Method - This integrates with the Git repository to look at the change history of the project’s files. Files with excessively high change histories have a tendency to have a high complexity rating as well, as they can be the result of feature envy, where extra functions are added into a file instead of being added to a new file with it’s own functionality.

==Getting Started with Refactoring==

===First step: Writing tests===
The first step in refactoring is writing solid set of tests for the section of code under consideration, in order to avoid introducing bugs. In Ruby, this can be done using [http://www.ruby-doc.org/stdlib-2.1.0/libdoc/test/unit/rdoc/Test/Unit.html Test::Unit] or [http://rspec.info/ Rspec]. Next step is to make small changes, test, make small changes, test again and so on<ref name='Refactoring Ruby Edition'>http://books.google.com/books?id=6jyOUrJBJHAC</ref>. This ensures that we can revert back to the working version of code if any small refactoring causes the application to stop working.

===When to refactor===
It is always confusing when to start refactoring. If either one of the following conditions is true, it is a good time to start refactoring code<ref name='Refactoring Ruby Edition'/>:
* The Rule of Three - If any code segment gives trouble more than two times, it is time to refactor it
* Adding new function - It might be helpful to refactor when adding new functionality as it would give better understanding of code. Sometimes, revisiting old design might help to accommodate new features better
* Fixing a bug - It is useful to refactor code which had a bug; this might save bug reports from the same piece of code in future
* During code review - Refactoring is useful during code reviews as it can be applied immediately making code reviews more fruitful
* Understanding other's code - If a new member joins the team and is asked to refactor existing code, it helps them to get a better understanding of the code base. It might take extra time to get them started, but trying to refactor will help them contribute to the project better in the long run.

A [http://blog.codeclimate.com/blog/2014/01/09/when-is-it-time-to-refactor/ CodeClimate blog] suggests some other conditions to decide when to refactor code.

===When NOT to refactor:===
* Avoid refactoring when you should ideally be rewriting the entire code. Although a tough call to make, rewriting is inevitable when current code does not work at all or is too buggy to stabilize.
* Avoid refactoring when close to a deadline since productivity gain by refactoring is mostly seen after the deadline and might just cause the project to miss the deadline.
* Avoid refactoring for academic purposes, i.e. avoid changing code in working condition because you do not agree with those lines of code or that is not how you would have implemented it.

==Automated Code Refactoring==
=== RubyMine ===
*[http://www.jetbrains.com/ruby/webhelp/refactoring.html RubyMine] has a built in refactoring menu.
*To perform refactoring, select a code fragment to refactor. Refactorings available for your selection appear under the Refactor Menu in RubyMine. <ref>http://www.jetbrains.com/ruby/webhelp/refactoring-source-code.html#common</ref> [[File:RubyMine_refactoring_menu.png]]

===RFactor ===
*[http://fabiokung.com/2009/02/04/rfactor-ruby-refactoring-for-your-loved-editor/ RFactor] is a Ruby gem, which aims to provide common and simple refactorings for Ruby code for text editors like TextMate
*The first release has only Extract method implemented while other refactorings are coming soon
*It is available on [http://github.com/fabiokung/rfactor-tmbundle/tree/master GitHub]

=== Other IDEs ===
*Some other IDEs with built-in refactoring include [http://www.aptana.com/products/studio3 Aptana Studio], [http://www.aptana.com/products/radrails Aptana RadRails] and [https://netbeans.org/features/ruby/index.html NetBeans 7] (which requires Ruby and Rails [http://plugins.netbeans.org/plugin/38549 plugin])
*A StackOverflow [http://stackoverflow.com/questions/8705144/ide-with-refactoring-support-for-ruby-on-rails post] compares these tools ranking them as RubyMine being the best, followed by NetBeans, RadRails 2 and Aptana Studio 3

==Further Reading==
*[http://en.wikipedia.org/wiki/Code_smell Ways to identify problems in code]

*[http://ghendry.net/refactor.html A description of smells with their techniques exists]

*[http://www.refactoring.com/catalog/index.html A list of techniques with examples in Ruby are listed]

*[http://blog.codeclimate.com/blog/2012/11/14/why-ruby-class-methods-resist-refactoring/ Resistance With Refactoring Ruby Class Methods]

*[http://www.railsinside.com/uncategorized/460-the-first-step-of-refactoring-a-rails-application.html Refactoring a Rails Application]

*[http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ Refactoring Fat Models]

*[https://speakerdeck.com/brianvh/refactoring-views-in-rails Talk on Refactoring Fat Views]

*[http://books.google.com/books?id=i6mZ0HBDPzsC Rails AntiPatterns: Best Practice Ruby on Rails Refactoring]

==References==
<references/>

CSC/ECE 517 Spring 2014/ch1a 1e rm

2014-02-19T05:11:22Z

Rjlloyd: /* Further Reading */

This page discusses refactoring techniques and metrics. It also includes tips on refactoring in Ruby and list of tools for automated refactoring.

For the page with a history of edits, go to [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2014/ch1a_1w1e_rm this page].

==Background==

The idea behind [http://en.wikipedia.org/wiki/Code_refactoring code refactoring] is to take a code base and improve it's readability, [http://en.wikipedia.org/wiki/Extensibility extensibility], and [http://en.wikipedia.org/wiki/Reusability reusability]. The practice is focused on having a better quality and more standardized code base, and not on fixing bugs or changing functionality.

In their Refactoring book<ref name="Refactoring book">http://books.google.com/books?id=1MsETFPD3I0C</ref>, Martin Fowler and Kent Beck define refactoring as 'A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior… It is a disciplined way to clean up code that minimizes the chances of introducing bugs'.

Refactoring has its difficulties, whether or not it is done using an [http://en.wikipedia.org/wiki/Integrated_development_environment IDE] or whether it is done by hand. There are lots of pitfalls and errors that can be made during refactoring, so it is pertinent to determine how important a refactor is to the code. Code metrics are one method used to determine how badly a file needs refactoring.

==Refactoring Techniques==
Before a coder performs a refactor, they must, either formally or informally, identify their ‘code smells’. A code smell refers to a negative quality of a code base that either implements bad programming practices or slows down code development or runtime. These aren't typically bugs, but can increase the chance of bugs later on if not fixed. Based on the type of code smell, a different refactoring technique is used to fix it.

===Duplicate Code===
Duplicate code can be a tricky concept when refactoring. Large sections of duplicated code can be easy to find and fixed by pulling it out and creating a single centralized method to call, however it is usually not that easy. Sometimes it may only be one or two lines of code that are duplicated which calls for an assessment of whether or not it is in the best interest to create a new method for a couple lines of code. Other times, code is not duplicate, rather it is similar enough that a generic method could be created to serve various purposes.
Some specific techniques to deal with this are:
*Extract Method / Pull-up Method
**If common code is used in multiple places, simply pull it out and make a method that can be called from all of the necessary places. Variables can be passed in if slight variations are needed between calls.
**If the code is used in various subclasses, put the common code in a method in the superclass, so that it can be seen and called by its children.<ref>http://www.refactoring.com/catalog/extractMethod.html Extract Method Example</ref>
Before Refactor
<pre>
class Cat
end

class Lion < Mammal
def likes
puts "Boxes"
end
end
class HouseCat < Mammal
def likes
puts "Boxes"
end
end
</pre>
After Pull Up Refactor
<pre>
class Cat
def likes
puts "Boxes"
end
end

class Lion < Mammal
end
class HouseCat < Mammal
end
</pre>

*Form Template Method
**If two methods in subclasses perform similar steps in the same order, but the steps are different, then get the steps into methods with the same signature, so that the original methods become the same. Then pull them up. <ref>http://www.refactoring.com/catalog/formTemplateMethod.html</ref>
Before Refactor
<pre>
class Cat
end
class Tiger < Cat
def live
puts “Wake up”
puts “Catch deer”
puts “Eat deer”
puts “Sleep in sun”
end
end
class HouseCat < Cat
def live
puts “Wake up”
puts “Wake human up”
puts “Eat food”
puts “Sleep in sun”
end
end
</pre>
After Form Template Refactor
<pre>
class Cat
def live
puts “Wake up”
do_morning_routine
puts “Sleep in the sun”
end
end
class Tiger < Cat
def do_morning_routine
puts “Catch deer”
puts “Eat deer”
end
end
class HouseCat < Cat
def do_morning_routine
puts “Wake human up”
puts “Eat food”
end
end
</pre>

===Large Method/Class===
If a project is not planned out well enough in advance, it is easy for methods and classes to become populated with excess functionality. While functionality of a block of code may be necessary for the project, the code block might not really pertain to the method or class it is included in.
*Extract Method
**This can be used when duplicate code occurs, as discussed above. But it can also be used when a method performs multiple functions that have the ability to be split up into various functions that serve a single purpose.
Before Refactoring
<pre>
def foo
puts "hey"
puts "how are you"
puts "bye!"
end
def bar
puts "bye!"
end
</pre>
After Extract Method Refactor
<pre>
def greet
puts "hey"
puts "how are you"
end
def farewell
puts "bye!"
end
def foo
greet
farewell
end
def bar
greet
end
</pre>
*Extract Class/Subclass/Superclass
**If there are class variables or methods that don’t directly pertain to a class, then it may be necessary to create a new class for those pieces.[http://www.refactoring.com/catalog/extractClass.html Example]
**If there are pieces of a class that are only for a specific subset of instances, then a subclass can be constructed to contain these.[http://www.refactoring.com/catalog/extractSubclass.html Example]
**If there are pieces that multiple classes use, then a superclass can be constructed to handle these generic functions, leaving the subclasses to deal with the remaining differences<ref>http://www.refactoring.com/catalog/extractSuperclass.html Example </ref>
Before Refactoring
<pre>
class Person
def initialize(f,m,l,s)
@firstName = f
@middleName = m
@lastName = l
@SSN = s
end
end
</pre>
After Extract Class Refactoring
<pre>

class FullName
def initialize(f,m,l)
@firstName = f
@middleName = m
@lastName = l
end
end

class Person
def initialize(f,m,l,s)
@name = FullName.new(f,m,l)
@SSN = s
end
end
</pre>

===Improving Readability and Clarity===
Many times, refactoring can be used to do simple, yet necessary changes like renaming variables, methods, or classes. As features get added to a project, classes tend to get charged with more uses than originally planned, so sometimes, the original naming scheme no longer applies and a new one needs to be instilled.

Moving methods and parameters around to where they have the best accessibility also has its uses. Classes also tend to be promoted or demoted to super and sub classes after their ultimate functional purpose is determined.

===More Techniques===
There many more techniques than those that are listed above. Each has its specific purpose, though one must take care to make sure that it is a necessary refactoring.

==Metrics==
It can be hard to decide whether or not to refactor, especially when it’s for something that appears to be working fine with just a surface level smell. Program analysis tools are used to derive various types of code metrics, which allow coders to identify problem areas and future pitfalls of their code base. These tools look at the code in several different ways, including the number of times a source file has been edited to help determine if it is a possible target of [feature envy], duplicate code structure to identify replicated lines, and block depths to suggest possible complexity issues.

===Open Source Ruby Metric Tools===
There are a variety of open source code metric tools that can be employed specifically for Ruby programs. [https://www.ruby-toolbox.com/categories/code_metrics The Ruby Toolbox] contains the most popular of these tools along with ratings.

[http://rubydoc.info/gems/simplecov/frames Simple Cov] is at the top of this list. It was developed specifically to be of use to anyone using any framework. It integrates itself with the project’s own test cases to check the code coverage of them in addition to cucumber features.

===Code Climate===
[https://codeclimate.com Code Climate] is a hosted code metrics tool that analyzes projects in a multitdue of ways. It produces three main metric ratings with grades from A-F that comprise of the methods and classes contained in each file and project.
#Complexity Metric - This is based off of the Assignment, Branches, and Conditions ([http://c2.com/cgi/wiki?AbcMetric ABC]) metric, where the number of assignments, branches, and conditions are counted and analyzed. However, because Code Climate is constructed for Ruby programs, it also takes into account certain types of Ruby constructs that may increase the metric score, but are actually beneficial to the project.
#Duplication Metric - This looks at the syntax trees of the code in order to identify identical and similar code structures. Because the syntax trees are being analyzed, code formatting and different method and class names do not affect the score. <ref>https://codeclimate.com/docs#quality-metrics</ref>
#Churn Method - This integrates with the Git repository to look at the change history of the project’s files. Files with excessively high change histories have a tendency to have a high complexity rating as well, as they can be the result of feature envy, where extra functions are added into a file instead of being added to a new file with it’s own functionality.

==Getting Started with Refactoring==

===First step: Writing tests===
The first step in refactoring is writing solid set of tests for the section of code under consideration, in order to avoid introducing bugs. In Ruby, this can be done using [http://www.ruby-doc.org/stdlib-2.1.0/libdoc/test/unit/rdoc/Test/Unit.html Test::Unit] or [http://rspec.info/ Rspec]. Next step is to make small changes, test, make small changes, test again and so on<ref name='Refactoring Ruby Edition'>http://books.google.com/books?id=6jyOUrJBJHAC</ref>. This ensures that we can revert back to the working version of code if any small refactoring causes the application to stop working.

===When to refactor===
It is always confusing when to start refactoring. If either one of the following conditions is true, it is a good time to start refactoring code<ref name='Refactoring Ruby Edition'/>:
* The Rule of Three - If any code segment gives trouble more than two times, it is time to refactor it
* Adding new function - It might be helpful to refactor when adding new functionality as it would give better understanding of code. Sometimes, revisiting old design might help to accommodate new features better
* Fixing a bug - It is useful to refactor code which had a bug; this might save bug reports from the same piece of code in future
* During code review - Refactoring is useful during code reviews as it can be applied immediately making code reviews more fruitful
* Understanding other's code - If a new member joins the team and is asked to refactor existing code, it helps them to get a better understanding of the code base. It might take extra time to get them started, but trying to refactor will help them contribute to the project better in the long run.

A [http://blog.codeclimate.com/blog/2014/01/09/when-is-it-time-to-refactor/ CodeClimate blog] suggests some other conditions to decide when to refactor code.

===When NOT to refactor:===
* Avoid refactoring when you should ideally be rewriting the entire code. Although a tough call to make, rewriting is inevitable when current code does not work at all or is too buggy to stabilize.
* Avoid refactoring when close to a deadline since productivity gain by refactoring is mostly seen after the deadline and might just cause the project to miss the deadline.
* Avoid refactoring for academic purposes, i.e. avoid changing code in working condition because you do not agree with those lines of code or that is not how you would have implemented it.

==Automated Code Refactoring==
=== RubyMine ===
*[http://www.jetbrains.com/ruby/webhelp/refactoring.html RubyMine] has a built in refactoring menu.
*To perform refactoring, select a code fragment to refactor. Refactorings available for your selection appear under the Refactor Menu in RubyMine. <ref>http://www.jetbrains.com/ruby/webhelp/refactoring-source-code.html#common</ref> [[File:RubyMine_refactoring_menu.png]]

===RFactor ===
*[http://fabiokung.com/2009/02/04/rfactor-ruby-refactoring-for-your-loved-editor/ RFactor] is a Ruby gem, which aims to provide common and simple refactorings for Ruby code for text editors like TextMate
*The first release has only Extract method implemented while other refactorings are coming soon
*It is available on [http://github.com/fabiokung/rfactor-tmbundle/tree/master GitHub]

=== Other IDEs ===
*Some other IDEs with built-in refactoring include [http://www.aptana.com/products/studio3 Aptana Studio], [http://www.aptana.com/products/radrails Aptana RadRails] and [https://netbeans.org/features/ruby/index.html NetBeans 7] (which requires Ruby and Rails [http://plugins.netbeans.org/plugin/38549 plugin])
*A StackOverflow [http://stackoverflow.com/questions/8705144/ide-with-refactoring-support-for-ruby-on-rails post] compares these tools ranking them as RubyMine being the best, followed by NetBeans, RadRails 2 and Aptana Studio 3

==Further Reading==
*[http://en.wikipedia.org/wiki/Code_smell Ways to identify problems in code]

*[http://ghendry.net/refactor.html A description of smells with their techniques exists]

*[http://www.refactoring.com/catalog/index.html A list of techniques with examples in Ruby are listed]

*[http://blog.codeclimate.com/blog/2012/11/14/why-ruby-class-methods-resist-refactoring/ Resistance With Refactoring Ruby Class Methods]

*[http://www.railsinside.com/uncategorized/460-the-first-step-of-refactoring-a-rails-application.html Refactoring a Rails Application]

*[http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ Refactoring Fat Models]

*[https://speakerdeck.com/brianvh/refactoring-views-in-rails Talk on Refactoring Fat Views]

*[http://books.google.com/books?id=i6mZ0HBDPzsC Rails AntiPatterns: Best Practice Ruby on Rails Refactoring]

==References==
<references/>

CSC/ECE 517 Spring 2014/ch1a 1e rm

2014-02-19T05:10:52Z

Rjlloyd: /* Refactoring Techniques */

This page discusses refactoring techniques and metrics. It also includes tips on refactoring in Ruby and list of tools for automated refactoring.

For the page with a history of edits, go to [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2014/ch1a_1w1e_rm this page].

==Background==

The idea behind [http://en.wikipedia.org/wiki/Code_refactoring code refactoring] is to take a code base and improve it's readability, [http://en.wikipedia.org/wiki/Extensibility extensibility], and [http://en.wikipedia.org/wiki/Reusability reusability]. The practice is focused on having a better quality and more standardized code base, and not on fixing bugs or changing functionality.

In their Refactoring book<ref name="Refactoring book">http://books.google.com/books?id=1MsETFPD3I0C</ref>, Martin Fowler and Kent Beck define refactoring as 'A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior… It is a disciplined way to clean up code that minimizes the chances of introducing bugs'.

Refactoring has its difficulties, whether or not it is done using an [http://en.wikipedia.org/wiki/Integrated_development_environment IDE] or whether it is done by hand. There are lots of pitfalls and errors that can be made during refactoring, so it is pertinent to determine how important a refactor is to the code. Code metrics are one method used to determine how badly a file needs refactoring.

==Refactoring Techniques==
Before a coder performs a refactor, they must, either formally or informally, identify their ‘code smells’. A code smell refers to a negative quality of a code base that either implements bad programming practices or slows down code development or runtime. These aren't typically bugs, but can increase the chance of bugs later on if not fixed. Based on the type of code smell, a different refactoring technique is used to fix it.

===Duplicate Code===
Duplicate code can be a tricky concept when refactoring. Large sections of duplicated code can be easy to find and fixed by pulling it out and creating a single centralized method to call, however it is usually not that easy. Sometimes it may only be one or two lines of code that are duplicated which calls for an assessment of whether or not it is in the best interest to create a new method for a couple lines of code. Other times, code is not duplicate, rather it is similar enough that a generic method could be created to serve various purposes.
Some specific techniques to deal with this are:
*Extract Method / Pull-up Method
**If common code is used in multiple places, simply pull it out and make a method that can be called from all of the necessary places. Variables can be passed in if slight variations are needed between calls.
**If the code is used in various subclasses, put the common code in a method in the superclass, so that it can be seen and called by its children.<ref>http://www.refactoring.com/catalog/extractMethod.html Extract Method Example</ref>
Before Refactor
<pre>
class Cat
end

class Lion < Mammal
def likes
puts "Boxes"
end
end
class HouseCat < Mammal
def likes
puts "Boxes"
end
end
</pre>
After Pull Up Refactor
<pre>
class Cat
def likes
puts "Boxes"
end
end

class Lion < Mammal
end
class HouseCat < Mammal
end
</pre>

*Form Template Method
**If two methods in subclasses perform similar steps in the same order, but the steps are different, then get the steps into methods with the same signature, so that the original methods become the same. Then pull them up. <ref>http://www.refactoring.com/catalog/formTemplateMethod.html</ref>
Before Refactor
<pre>
class Cat
end
class Tiger < Cat
def live
puts “Wake up”
puts “Catch deer”
puts “Eat deer”
puts “Sleep in sun”
end
end
class HouseCat < Cat
def live
puts “Wake up”
puts “Wake human up”
puts “Eat food”
puts “Sleep in sun”
end
end
</pre>
After Form Template Refactor
<pre>
class Cat
def live
puts “Wake up”
do_morning_routine
puts “Sleep in the sun”
end
end
class Tiger < Cat
def do_morning_routine
puts “Catch deer”
puts “Eat deer”
end
end
class HouseCat < Cat
def do_morning_routine
puts “Wake human up”
puts “Eat food”
end
end
</pre>

===Large Method/Class===
If a project is not planned out well enough in advance, it is easy for methods and classes to become populated with excess functionality. While functionality of a block of code may be necessary for the project, the code block might not really pertain to the method or class it is included in.
*Extract Method
**This can be used when duplicate code occurs, as discussed above. But it can also be used when a method performs multiple functions that have the ability to be split up into various functions that serve a single purpose.
Before Refactoring
<pre>
def foo
puts "hey"
puts "how are you"
puts "bye!"
end
def bar
puts "bye!"
end
</pre>
After Extract Method Refactor
<pre>
def greet
puts "hey"
puts "how are you"
end
def farewell
puts "bye!"
end
def foo
greet
farewell
end
def bar
greet
end
</pre>
*Extract Class/Subclass/Superclass
**If there are class variables or methods that don’t directly pertain to a class, then it may be necessary to create a new class for those pieces.[http://www.refactoring.com/catalog/extractClass.html Example]
**If there are pieces of a class that are only for a specific subset of instances, then a subclass can be constructed to contain these.[http://www.refactoring.com/catalog/extractSubclass.html Example]
**If there are pieces that multiple classes use, then a superclass can be constructed to handle these generic functions, leaving the subclasses to deal with the remaining differences<ref>http://www.refactoring.com/catalog/extractSuperclass.html Example </ref>
Before Refactoring
<pre>
class Person
def initialize(f,m,l,s)
@firstName = f
@middleName = m
@lastName = l
@SSN = s
end
end
</pre>
After Extract Class Refactoring
<pre>

class FullName
def initialize(f,m,l)
@firstName = f
@middleName = m
@lastName = l
end
end

class Person
def initialize(f,m,l,s)
@name = FullName.new(f,m,l)
@SSN = s
end
end
</pre>

===Improving Readability and Clarity===
Many times, refactoring can be used to do simple, yet necessary changes like renaming variables, methods, or classes. As features get added to a project, classes tend to get charged with more uses than originally planned, so sometimes, the original naming scheme no longer applies and a new one needs to be instilled.

Moving methods and parameters around to where they have the best accessibility also has its uses. Classes also tend to be promoted or demoted to super and sub classes after their ultimate functional purpose is determined.

===More Techniques===
There many more techniques than those that are listed above. Each has its specific purpose, though one must take care to make sure that it is a necessary refactoring.

==Metrics==
It can be hard to decide whether or not to refactor, especially when it’s for something that appears to be working fine with just a surface level smell. Program analysis tools are used to derive various types of code metrics, which allow coders to identify problem areas and future pitfalls of their code base. These tools look at the code in several different ways, including the number of times a source file has been edited to help determine if it is a possible target of [feature envy], duplicate code structure to identify replicated lines, and block depths to suggest possible complexity issues.

===Open Source Ruby Metric Tools===
There are a variety of open source code metric tools that can be employed specifically for Ruby programs. [https://www.ruby-toolbox.com/categories/code_metrics The Ruby Toolbox] contains the most popular of these tools along with ratings.

[http://rubydoc.info/gems/simplecov/frames Simple Cov] is at the top of this list. It was developed specifically to be of use to anyone using any framework. It integrates itself with the project’s own test cases to check the code coverage of them in addition to cucumber features.

===Code Climate===
[https://codeclimate.com Code Climate] is a hosted code metrics tool that analyzes projects in a multitdue of ways. It produces three main metric ratings with grades from A-F that comprise of the methods and classes contained in each file and project.
#Complexity Metric - This is based off of the Assignment, Branches, and Conditions ([http://c2.com/cgi/wiki?AbcMetric ABC]) metric, where the number of assignments, branches, and conditions are counted and analyzed. However, because Code Climate is constructed for Ruby programs, it also takes into account certain types of Ruby constructs that may increase the metric score, but are actually beneficial to the project.
#Duplication Metric - This looks at the syntax trees of the code in order to identify identical and similar code structures. Because the syntax trees are being analyzed, code formatting and different method and class names do not affect the score. <ref>https://codeclimate.com/docs#quality-metrics</ref>
#Churn Method - This integrates with the Git repository to look at the change history of the project’s files. Files with excessively high change histories have a tendency to have a high complexity rating as well, as they can be the result of feature envy, where extra functions are added into a file instead of being added to a new file with it’s own functionality.

==Getting Started with Refactoring==

===First step: Writing tests===
The first step in refactoring is writing solid set of tests for the section of code under consideration, in order to avoid introducing bugs. In Ruby, this can be done using [http://www.ruby-doc.org/stdlib-2.1.0/libdoc/test/unit/rdoc/Test/Unit.html Test::Unit] or [http://rspec.info/ Rspec]. Next step is to make small changes, test, make small changes, test again and so on<ref name='Refactoring Ruby Edition'>http://books.google.com/books?id=6jyOUrJBJHAC</ref>. This ensures that we can revert back to the working version of code if any small refactoring causes the application to stop working.

===When to refactor===
It is always confusing when to start refactoring. If either one of the following conditions is true, it is a good time to start refactoring code<ref name='Refactoring Ruby Edition'/>:
* The Rule of Three - If any code segment gives trouble more than two times, it is time to refactor it
* Adding new function - It might be helpful to refactor when adding new functionality as it would give better understanding of code. Sometimes, revisiting old design might help to accommodate new features better
* Fixing a bug - It is useful to refactor code which had a bug; this might save bug reports from the same piece of code in future
* During code review - Refactoring is useful during code reviews as it can be applied immediately making code reviews more fruitful
* Understanding other's code - If a new member joins the team and is asked to refactor existing code, it helps them to get a better understanding of the code base. It might take extra time to get them started, but trying to refactor will help them contribute to the project better in the long run.

A [http://blog.codeclimate.com/blog/2014/01/09/when-is-it-time-to-refactor/ CodeClimate blog] suggests some other conditions to decide when to refactor code.

===When NOT to refactor:===
* Avoid refactoring when you should ideally be rewriting the entire code. Although a tough call to make, rewriting is inevitable when current code does not work at all or is too buggy to stabilize.
* Avoid refactoring when close to a deadline since productivity gain by refactoring is mostly seen after the deadline and might just cause the project to miss the deadline.
* Avoid refactoring for academic purposes, i.e. avoid changing code in working condition because you do not agree with those lines of code or that is not how you would have implemented it.

==Automated Code Refactoring==
=== RubyMine ===
*[http://www.jetbrains.com/ruby/webhelp/refactoring.html RubyMine] has a built in refactoring menu.
*To perform refactoring, select a code fragment to refactor. Refactorings available for your selection appear under the Refactor Menu in RubyMine. <ref>http://www.jetbrains.com/ruby/webhelp/refactoring-source-code.html#common</ref> [[File:RubyMine_refactoring_menu.png]]

===RFactor ===
*[http://fabiokung.com/2009/02/04/rfactor-ruby-refactoring-for-your-loved-editor/ RFactor] is a Ruby gem, which aims to provide common and simple refactorings for Ruby code for text editors like TextMate
*The first release has only Extract method implemented while other refactorings are coming soon
*It is available on [http://github.com/fabiokung/rfactor-tmbundle/tree/master GitHub]

=== Other IDEs ===
*Some other IDEs with built-in refactoring include [http://www.aptana.com/products/studio3 Aptana Studio], [http://www.aptana.com/products/radrails Aptana RadRails] and [https://netbeans.org/features/ruby/index.html NetBeans 7] (which requires Ruby and Rails [http://plugins.netbeans.org/plugin/38549 plugin])
*A StackOverflow [http://stackoverflow.com/questions/8705144/ide-with-refactoring-support-for-ruby-on-rails post] compares these tools ranking them as RubyMine being the best, followed by NetBeans, RadRails 2 and Aptana Studio 3

==Further Reading==
*[http://en.wikipedia.org/wiki/Code_smell Ways to identify problems in code]

*[http://blog.codeclimate.com/blog/2012/11/14/why-ruby-class-methods-resist-refactoring/ Resistance With Refactoring Ruby Class Methods]

*[http://www.railsinside.com/uncategorized/460-the-first-step-of-refactoring-a-rails-application.html Refactoring a Rails Application]

*[http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ Refactoring Fat Models]

*[https://speakerdeck.com/brianvh/refactoring-views-in-rails Talk on Refactoring Fat Views]

*[http://books.google.com/books?id=i6mZ0HBDPzsC Rails AntiPatterns: Best Practice Ruby on Rails Refactoring]

==References==
<references/>

CSC/ECE 517 Spring 2014/ch1a 1w1e rm

2014-02-19T05:02:04Z

Rjlloyd: /* Background */

This page discusses refactoring techniques and metrics. It also includes tips on refactoring in Ruby and list of tools for automated refactoring.

==Background==

The idea behind [http://en.wikipedia.org/wiki/Code_refactoring code refactoring] is to take a code base and improve its readability, [http://en.wikipedia.org/wiki/Extensibility extensibility], and [http://en.wikipedia.org/wiki/Reusability reusability]. The practice is focused on having a better quality and more standardized code base, and not on fixing bugs or changing functionality.

Refactoring has its difficulties, whether or not it is done using an [http://en.wikipedia.org/wiki/Integrated_development_environment IDE] or whether it is done by hand. There are lots of errors that can be made during refactoring, so it is pertinent to determine when it is necessary to refactor. Code metrics are one method used to determine how badly a file needs refactoring.

==Refactoring Techniques==
Before a coder performs a refactor, they must, either formally or informally, identify their ‘code smells’. A code smell refers to a negative quality of a code base that either implements bad programming practices or slows down code development or runtime. These aren't typically bugs, but can increase the chance of bugs later on if not fixed. Based on the type of code smell, a different refactoring technique is used to fix it.

===Duplicate Code===
Duplicate code can be a tricky concept when refactoring. Large sections of duplicated code can be easy to find and fixed by pulling it out and creating a single centralized method to call, however it is usually not that easy. Sometimes it may only be one or two lines of code that are duplicated which calls for an assessment of whether or not it is in the best interest to create a new method for a couple lines of code. Other times, code is not duplicate, rather it is similar enough that a generic method could be created to serve various purposes.
Some specific techniques to deal with this are:
*Extract Method / Pull-up Method
**If common code is used in multiple places, simply pull it out and make a method that can be called from all of the necessary places. Variables can be passed in if slight variations are needed between calls.
**If the code is used in various subclasses, put the common code in a method in the superclass, so that it can be seen and called by its children.<ref>http://www.refactoring.com/catalog/extractMethod.html Extract Method Example</ref>
Before Refactor
<pre>
class Cat
end

class Lion < Mammal
def likes
puts "Boxes"
end
end
class HouseCat < Mammal
def likes
puts "Boxes"
end
end
</pre>
After Pull Up Refactor
<pre>
class Cat
def likes
puts "Boxes"
end
end

class Lion < Mammal
end
class HouseCat < Mammal
end
</pre>

*Form Template Method
**If two methods in subclasses perform similar steps in the same order, but the steps are different, then get the steps into methods with the same signature, so that the original methods become the same. Then pull them up. <ref>http://www.refactoring.com/catalog/formTemplateMethod.html</ref>
Before Refactor
<pre>
class Cat
end
class Tiger < Cat
def live
puts “Wake up”
puts “Catch deer”
puts “Eat deer”
puts “Sleep in sun”
end
end
class HouseCat < Cat
def live
puts “Wake up”
puts “Wake human up”
puts “Eat food”
puts “Sleep in sun”
end
end
</pre>
After Form Template Refactor
<pre>
class Cat
def live
puts “Wake up”
do_morning_routine
puts “Sleep in the sun”
end
end
class Tiger < Cat
def do_morning_routine
puts “Catch deer”
puts “Eat deer”
end
end
class HouseCat < Cat
def do_morning_routine
puts “Wake human up”
puts “Eat food”
end
end
</pre>

===Large Method/Class===
If a project is not planned out well enough in advance, it is easy for methods and classes to become populated with excess functionality. While functionality of a block of code may be necessary for the project, the code block might not really pertain to the method or class it is included in.
*Extract Method
**This can be used when duplicate code occurs, as discussed above. But it can also be used when a method performs multiple functions that have the ability to be split up into various functions that serve a single purpose.
Before Refactoring
<pre>
def foo
puts "hey"
puts "how are you"
puts "bye!"
end
def bar
puts "bye!"
end
</pre>
After Extract Method Refactor
<pre>
def greet
puts "hey"
puts "how are you"
end
def farewell
puts "bye!"
end
def foo
greet
farewell
end
def bar
greet
end
</pre>
*Extract Class/Subclass/Superclass
**If there are class variables or methods that don’t directly pertain to a class, then it may be necessary to create a new class for those pieces.[http://www.refactoring.com/catalog/extractClass.html Example]
**If there are pieces of a class that are only for a specific subset of instances, then a subclass can be constructed to contain these.[http://www.refactoring.com/catalog/extractSubclass.html Example]
**If there are pieces that multiple classes use, then a superclass can be constructed to handle these generic functions, leaving the subclasses to deal with the remaining differences<ref>http://www.refactoring.com/catalog/extractSuperclass.html Example </ref>
Before Refactoring
<pre>
class Person
def initialize(f,m,l,s)
@firstName = f
@middleName = m
@lastName = l
@SSN = s
end
end
</pre>
After Extract Class Refactoring
<pre>

class FullName
def initialize(f,m,l)
@firstName = f
@middleName = m
@lastName = l
end
end

class Person
def initialize(f,m,l,s)
@name = FullName.new(f,m,l)
@SSN = s
end
end
</pre>

===Improving Readability and Clarity===
Many times, refactoring can be used to do simple, yet necessary changes like renaming variables, methods, or classes. As features get added to a project, classes tend to get charged with more uses than originally planned, so sometimes, the original naming scheme no longer applies and a new one needs to be instilled.

Moving methods and parameters around to where they have the best accessibility also has its uses. Classes also tend to be promoted or demoted to super and sub classes after their ultimate functional purpose is determined.

===More Techniques===
There many more techniques than those that are listed above. Each has its specific purpose, though one must take care to make sure that it is a necessary refactoring.

==Metrics==
It can be hard to decide whether or not to refactor, especially when it’s for something that appears to be working fine with just a surface level smell. Program analysis tools are used to derive various types of code metrics, which allow coders to identify problem areas and future pitfalls of their code base. These tools look at the code in several different ways, including the number of times a source file has been edited to help determine if it is a possible target of [feature envy], duplicate code structure to identify replicated lines, and block depths to suggest possible complexity issues.

===Open Source Ruby Metric Tools===
There are a variety of open source code metric tools that can be employed specifically for Ruby programs. [https://www.ruby-toolbox.com/categories/code_metrics The Ruby Toolbox] contains the most popular of these tools along with ratings.

[http://rubydoc.info/gems/simplecov/frames Simple Cov] is at the top of this list. It was developed specifically to be of use to anyone using any framework. It integrates itself with the project’s own test cases to check the code coverage of them in addition to cucumber features.

===Code Climate===
[https://codeclimate.com Code Climate] is a hosted code metrics tool that analyzes projects in a multitdue of ways. It produces three main metric ratings with grades from A-F that comprise of the methods and classes contained in each file and project.
#Complexity Metric - This is based off of the Assignment, Branches, and Conditions ([http://c2.com/cgi/wiki?AbcMetric ABC]) metric, where the number of assignments, branches, and conditions are counted and analyzed. However, because Code Climate is constructed for Ruby programs, it also takes into account certain types of Ruby constructs that may increase the metric score, but are actually beneficial to the project.
#Duplication Metric - This looks at the syntax trees of the code in order to identify identical and similar code structures. Because the syntax trees are being analyzed, code formatting and different method and class names do not affect the score. <ref>https://codeclimate.com/docs#quality-metrics</ref>
#Churn Method - This integrates with the Git repository to look at the change history of the project’s files. Files with excessively high change histories have a tendency to have a high complexity rating as well, as they can be the result of feature envy, where extra functions are added into a file instead of being added to a new file with its own functionality.

==Getting Started with Refactoring in Ruby==

===First step: Writing tests===
The first step in refactoring is writing solid set of tests for the section of code under consideration, in order to avoid introducing bugs. In Ruby, this can be done using [http://www.ruby-doc.org/stdlib-2.1.0/libdoc/test/unit/rdoc/Test/Unit.html Test::Unit] or [http://rspec.info/ Rspec]. Next step is to make small changes, test, make small changes, test again and so on<ref name='Refactoring Ruby Edition'>http://www.amazon.com/Refactoring-Edition-Addison-Wesley-Professional-Series/dp/0321984137</ref>. This ensures that we can revert back to the working version of code if any small refactoring causes the application to stop working.

===When to refactor===
It is always confusing when to start refactoring. If either one of the following conditions is true, it is a good time to start refactoring code<ref name='Refactoring Ruby Edition'/>:
* The Rule of Three - If any code segment gives trouble more than two times, it is time to refactor it
* Adding new function - It might be helpful to refactor when adding new functionality as it would give better understanding of code. Sometimes, revisiting old design might help to accommodate new features better
* Fixing a bug - It is useful to refactor code which had a bug; this might save bug reports from the same piece of code in future
* During code review - Refactoring is useful during code reviews as it can be applied immediately making code reviews more fruitful
* Understanding other's code - If a new member joins the team and is asked to refactor existing code, it helps them to get a better understanding of the code base. It might take extra time to get them started, but trying to refactor will help them contribute to the project better in the long run.

A [http://blog.codeclimate.com/blog/2014/01/09/when-is-it-time-to-refactor/ CodeClimate blog] suggests some other conditions to decide when to refactor code.

==Automated Code Refactoring==
=== RubyMine ===
*[http://www.jetbrains.com/ruby/webhelp/refactoring.html RubyMine] has a built in refactoring menu.
*To perform refactoring, select a code fragment to refactor. Refactorings available for your selection appear under the Refactor Menu in RubyMine. <ref>http://www.jetbrains.com/ruby/webhelp/refactoring-source-code.html#common</ref> [[File:RubyMine_refactoring_menu.png]]

===RFactor ===
*[http://fabiokung.com/2009/02/04/rfactor-ruby-refactoring-for-your-loved-editor/ RFactor] is a Ruby gem, which aims to provide common and simple refactorings for Ruby code for text editors like TextMate
*The first release has only Extract method implemented while other refactorings are coming soon
*It is available on [http://github.com/fabiokung/rfactor-tmbundle/tree/master GitHub]

=== Other IDEs ===
*Some other IDEs with built-in refactoring include [http://www.aptana.com/products/studio3 Aptana Studio], [http://www.aptana.com/products/radrails Aptana RadRails] and [https://netbeans.org/features/ruby/index.html NetBeans 7] (which requires Ruby and Rails [http://plugins.netbeans.org/plugin/38549 plugin])
*A StackOverflow [http://stackoverflow.com/questions/8705144/ide-with-refactoring-support-for-ruby-on-rails post] compares these tools ranking them as RubyMine being the best, followed by NetBeans, RadRails 2 and Aptana Studio 3

==Further Reading==
*[http://en.wikipedia.org/wiki/Code_smell Ways to identify problems in code]

*[http://ghendry.net/refactor.html A description of smells with their techniques exists]

*[http://www.refactoring.com/catalog/index.html A list of techniques with examples in Ruby are listed]

*[http://blog.codeclimate.com/blog/2012/11/14/why-ruby-class-methods-resist-refactoring/ Resistance With Refactoring Ruby Class Methods]

*[http://www.railsinside.com/uncategorized/460-the-first-step-of-refactoring-a-rails-application.html Refactoring a Rails Application]

*[http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ Refactoring Fat Models]

*[https://speakerdeck.com/brianvh/refactoring-views-in-rails Talk on Refactoring Fat Views]

*[http://www.amazon.com/Rails-AntiPatterns-Refactoring-Addison-Wesley-Professional/dp/0321604814 Rails AntiPatterns: Best Practice Ruby on Rails Refactoring]

==References==
<references/>

CSC/ECE 517 Spring 2014/ch1a 1w1e rm

2014-02-19T04:55:29Z

Rjlloyd: /* Further Reading */

This page discusses refactoring techniques and metrics. It also includes tips on refactoring in Ruby and list of tools for automated refactoring.

==Background==

The idea behind [http://en.wikipedia.org/wiki/Code_refactoring code refactoring] is to take a code base and improve its readability, [http://en.wikipedia.org/wiki/Extensibility extensibility], and [http://en.wikipedia.org/wiki/Reusability reusability]. The practice is focused on having a better quality and more standardized code base, and not on fixing bugs or changing functionality.

Refactoring has its difficulties, whether or not it is done using an [http://en.wikipedia.org/wiki/Integrated_development_environment IDE] or whether it is done by hand. There are lots of pitfalls and errors that can be made during refactoring, so it is pertinent to determine how important a refactor is to the code. Code metrics are one method used to determine how badly a file needs refactoring.

==Refactoring Techniques==
Before a coder performs a refactor, they must, either formally or informally, identify their ‘code smells’. A code smell refers to a negative quality of a code base that either implements bad programming practices or slows down code development or runtime. These aren't typically bugs, but can increase the chance of bugs later on if not fixed. Based on the type of code smell, a different refactoring technique is used to fix it.

===Duplicate Code===
Duplicate code can be a tricky concept when refactoring. Large sections of duplicated code can be easy to find and fixed by pulling it out and creating a single centralized method to call, however it is usually not that easy. Sometimes it may only be one or two lines of code that are duplicated which calls for an assessment of whether or not it is in the best interest to create a new method for a couple lines of code. Other times, code is not duplicate, rather it is similar enough that a generic method could be created to serve various purposes.
Some specific techniques to deal with this are:
*Extract Method / Pull-up Method
**If common code is used in multiple places, simply pull it out and make a method that can be called from all of the necessary places. Variables can be passed in if slight variations are needed between calls.
**If the code is used in various subclasses, put the common code in a method in the superclass, so that it can be seen and called by its children.<ref>http://www.refactoring.com/catalog/extractMethod.html Extract Method Example</ref>
Before Refactor
<pre>
class Cat
end

class Lion < Mammal
def likes
puts "Boxes"
end
end
class HouseCat < Mammal
def likes
puts "Boxes"
end
end
</pre>
After Pull Up Refactor
<pre>
class Cat
def likes
puts "Boxes"
end
end

class Lion < Mammal
end
class HouseCat < Mammal
end
</pre>

*Form Template Method
**If two methods in subclasses perform similar steps in the same order, but the steps are different, then get the steps into methods with the same signature, so that the original methods become the same. Then pull them up. <ref>http://www.refactoring.com/catalog/formTemplateMethod.html</ref>
Before Refactor
<pre>
class Cat
end
class Tiger < Cat
def live
puts “Wake up”
puts “Catch deer”
puts “Eat deer”
puts “Sleep in sun”
end
end
class HouseCat < Cat
def live
puts “Wake up”
puts “Wake human up”
puts “Eat food”
puts “Sleep in sun”
end
end
</pre>
After Form Template Refactor
<pre>
class Cat
def live
puts “Wake up”
do_morning_routine
puts “Sleep in the sun”
end
end
class Tiger < Cat
def do_morning_routine
puts “Catch deer”
puts “Eat deer”
end
end
class HouseCat < Cat
def do_morning_routine
puts “Wake human up”
puts “Eat food”
end
end
</pre>

===Large Method/Class===
If a project is not planned out well enough in advance, it is easy for methods and classes to become populated with excess functionality. While functionality of a block of code may be necessary for the project, the code block might not really pertain to the method or class it is included in.
*Extract Method
**This can be used when duplicate code occurs, as discussed above. But it can also be used when a method performs multiple functions that have the ability to be split up into various functions that serve a single purpose.
Before Refactoring
<pre>
def foo
puts "hey"
puts "how are you"
puts "bye!"
end
def bar
puts "bye!"
end
</pre>
After Extract Method Refactor
<pre>
def greet
puts "hey"
puts "how are you"
end
def farewell
puts "bye!"
end
def foo
greet
farewell
end
def bar
greet
end
</pre>
*Extract Class/Subclass/Superclass
**If there are class variables or methods that don’t directly pertain to a class, then it may be necessary to create a new class for those pieces.[http://www.refactoring.com/catalog/extractClass.html Example]
**If there are pieces of a class that are only for a specific subset of instances, then a subclass can be constructed to contain these.[http://www.refactoring.com/catalog/extractSubclass.html Example]
**If there are pieces that multiple classes use, then a superclass can be constructed to handle these generic functions, leaving the subclasses to deal with the remaining differences<ref>http://www.refactoring.com/catalog/extractSuperclass.html Example </ref>
Before Refactoring
<pre>
class Person
def initialize(f,m,l,s)
@firstName = f
@middleName = m
@lastName = l
@SSN = s
end
end
</pre>
After Extract Class Refactoring
<pre>

class FullName
def initialize(f,m,l)
@firstName = f
@middleName = m
@lastName = l
end
end

class Person
def initialize(f,m,l,s)
@name = FullName.new(f,m,l)
@SSN = s
end
end
</pre>

===Improving Readability and Clarity===
Many times, refactoring can be used to do simple, yet necessary changes like renaming variables, methods, or classes. As features get added to a project, classes tend to get charged with more uses than originally planned, so sometimes, the original naming scheme no longer applies and a new one needs to be instilled.

Moving methods and parameters around to where they have the best accessibility also has its uses. Classes also tend to be promoted or demoted to super and sub classes after their ultimate functional purpose is determined.

===More Techniques===
There many more techniques than those that are listed above. Each has its specific purpose, though one must take care to make sure that it is a necessary refactoring.

==Metrics==
It can be hard to decide whether or not to refactor, especially when it’s for something that appears to be working fine with just a surface level smell. Program analysis tools are used to derive various types of code metrics, which allow coders to identify problem areas and future pitfalls of their code base. These tools look at the code in several different ways, including the number of times a source file has been edited to help determine if it is a possible target of [feature envy], duplicate code structure to identify replicated lines, and block depths to suggest possible complexity issues.

===Open Source Ruby Metric Tools===
There are a variety of open source code metric tools that can be employed specifically for Ruby programs. [https://www.ruby-toolbox.com/categories/code_metrics The Ruby Toolbox] contains the most popular of these tools along with ratings.

[http://rubydoc.info/gems/simplecov/frames Simple Cov] is at the top of this list. It was developed specifically to be of use to anyone using any framework. It integrates itself with the project’s own test cases to check the code coverage of them in addition to cucumber features.

===Code Climate===
[https://codeclimate.com Code Climate] is a hosted code metrics tool that analyzes projects in a multitdue of ways. It produces three main metric ratings with grades from A-F that comprise of the methods and classes contained in each file and project.
#Complexity Metric - This is based off of the Assignment, Branches, and Conditions ([http://c2.com/cgi/wiki?AbcMetric ABC]) metric, where the number of assignments, branches, and conditions are counted and analyzed. However, because Code Climate is constructed for Ruby programs, it also takes into account certain types of Ruby constructs that may increase the metric score, but are actually beneficial to the project.
#Duplication Metric - This looks at the syntax trees of the code in order to identify identical and similar code structures. Because the syntax trees are being analyzed, code formatting and different method and class names do not affect the score. <ref>https://codeclimate.com/docs#quality-metrics</ref>
#Churn Method - This integrates with the Git repository to look at the change history of the project’s files. Files with excessively high change histories have a tendency to have a high complexity rating as well, as they can be the result of feature envy, where extra functions are added into a file instead of being added to a new file with its own functionality.

==Getting Started with Refactoring in Ruby==

===First step: Writing tests===
The first step in refactoring is writing solid set of tests for the section of code under consideration, in order to avoid introducing bugs. In Ruby, this can be done using [http://www.ruby-doc.org/stdlib-2.1.0/libdoc/test/unit/rdoc/Test/Unit.html Test::Unit] or [http://rspec.info/ Rspec]. Next step is to make small changes, test, make small changes, test again and so on<ref name='Refactoring Ruby Edition'>http://www.amazon.com/Refactoring-Edition-Addison-Wesley-Professional-Series/dp/0321984137</ref>. This ensures that we can revert back to the working version of code if any small refactoring causes the application to stop working.

===When to refactor===
It is always confusing when to start refactoring. If either one of the following conditions is true, it is a good time to start refactoring code<ref name='Refactoring Ruby Edition'/>:
* The Rule of Three - If any code segment gives trouble more than two times, it is time to refactor it
* Adding new function - It might be helpful to refactor when adding new functionality as it would give better understanding of code. Sometimes, revisiting old design might help to accommodate new features better
* Fixing a bug - It is useful to refactor code which had a bug; this might save bug reports from the same piece of code in future
* During code review - Refactoring is useful during code reviews as it can be applied immediately making code reviews more fruitful
* Understanding other's code - If a new member joins the team and is asked to refactor existing code, it helps them to get a better understanding of the code base. It might take extra time to get them started, but trying to refactor will help them contribute to the project better in the long run.

A [http://blog.codeclimate.com/blog/2014/01/09/when-is-it-time-to-refactor/ CodeClimate blog] suggests some other conditions to decide when to refactor code.

==Automated Code Refactoring==
=== RubyMine ===
*[http://www.jetbrains.com/ruby/webhelp/refactoring.html RubyMine] has a built in refactoring menu.
*To perform refactoring, select a code fragment to refactor. Refactorings available for your selection appear under the Refactor Menu in RubyMine. <ref>http://www.jetbrains.com/ruby/webhelp/refactoring-source-code.html#common</ref> [[File:RubyMine_refactoring_menu.png]]

===RFactor ===
*[http://fabiokung.com/2009/02/04/rfactor-ruby-refactoring-for-your-loved-editor/ RFactor] is a Ruby gem, which aims to provide common and simple refactorings for Ruby code for text editors like TextMate
*The first release has only Extract method implemented while other refactorings are coming soon
*It is available on [http://github.com/fabiokung/rfactor-tmbundle/tree/master GitHub]

=== Other IDEs ===
*Some other IDEs with built-in refactoring include [http://www.aptana.com/products/studio3 Aptana Studio], [http://www.aptana.com/products/radrails Aptana RadRails] and [https://netbeans.org/features/ruby/index.html NetBeans 7] (which requires Ruby and Rails [http://plugins.netbeans.org/plugin/38549 plugin])
*A StackOverflow [http://stackoverflow.com/questions/8705144/ide-with-refactoring-support-for-ruby-on-rails post] compares these tools ranking them as RubyMine being the best, followed by NetBeans, RadRails 2 and Aptana Studio 3

==Further Reading==
*[http://en.wikipedia.org/wiki/Code_smell Ways to identify problems in code]

*[http://ghendry.net/refactor.html A description of smells with their techniques exists]

*[http://www.refactoring.com/catalog/index.html A list of techniques with examples in Ruby are listed]

*[http://blog.codeclimate.com/blog/2012/11/14/why-ruby-class-methods-resist-refactoring/ Resistance With Refactoring Ruby Class Methods]

*[http://www.railsinside.com/uncategorized/460-the-first-step-of-refactoring-a-rails-application.html Refactoring a Rails Application]

*[http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ Refactoring Fat Models]

*[https://speakerdeck.com/brianvh/refactoring-views-in-rails Talk on Refactoring Fat Views]

*[http://www.amazon.com/Rails-AntiPatterns-Refactoring-Addison-Wesley-Professional/dp/0321604814 Rails AntiPatterns: Best Practice Ruby on Rails Refactoring]

==References==
<references/>

CSC/ECE 517 Spring 2014/ch1a 1w1e rm

2014-02-19T04:54:55Z

Rjlloyd: /* More Techniques */

This page discusses refactoring techniques and metrics. It also includes tips on refactoring in Ruby and list of tools for automated refactoring.

==Background==

The idea behind [http://en.wikipedia.org/wiki/Code_refactoring code refactoring] is to take a code base and improve its readability, [http://en.wikipedia.org/wiki/Extensibility extensibility], and [http://en.wikipedia.org/wiki/Reusability reusability]. The practice is focused on having a better quality and more standardized code base, and not on fixing bugs or changing functionality.

Refactoring has its difficulties, whether or not it is done using an [http://en.wikipedia.org/wiki/Integrated_development_environment IDE] or whether it is done by hand. There are lots of pitfalls and errors that can be made during refactoring, so it is pertinent to determine how important a refactor is to the code. Code metrics are one method used to determine how badly a file needs refactoring.

==Refactoring Techniques==
Before a coder performs a refactor, they must, either formally or informally, identify their ‘code smells’. A code smell refers to a negative quality of a code base that either implements bad programming practices or slows down code development or runtime. These aren't typically bugs, but can increase the chance of bugs later on if not fixed. Based on the type of code smell, a different refactoring technique is used to fix it.

===Duplicate Code===
Duplicate code can be a tricky concept when refactoring. Large sections of duplicated code can be easy to find and fixed by pulling it out and creating a single centralized method to call, however it is usually not that easy. Sometimes it may only be one or two lines of code that are duplicated which calls for an assessment of whether or not it is in the best interest to create a new method for a couple lines of code. Other times, code is not duplicate, rather it is similar enough that a generic method could be created to serve various purposes.
Some specific techniques to deal with this are:
*Extract Method / Pull-up Method
**If common code is used in multiple places, simply pull it out and make a method that can be called from all of the necessary places. Variables can be passed in if slight variations are needed between calls.
**If the code is used in various subclasses, put the common code in a method in the superclass, so that it can be seen and called by its children.<ref>http://www.refactoring.com/catalog/extractMethod.html Extract Method Example</ref>
Before Refactor
<pre>
class Cat
end

class Lion < Mammal
def likes
puts "Boxes"
end
end
class HouseCat < Mammal
def likes
puts "Boxes"
end
end
</pre>
After Pull Up Refactor
<pre>
class Cat
def likes
puts "Boxes"
end
end

class Lion < Mammal
end
class HouseCat < Mammal
end
</pre>

*Form Template Method
**If two methods in subclasses perform similar steps in the same order, but the steps are different, then get the steps into methods with the same signature, so that the original methods become the same. Then pull them up. <ref>http://www.refactoring.com/catalog/formTemplateMethod.html</ref>
Before Refactor
<pre>
class Cat
end
class Tiger < Cat
def live
puts “Wake up”
puts “Catch deer”
puts “Eat deer”
puts “Sleep in sun”
end
end
class HouseCat < Cat
def live
puts “Wake up”
puts “Wake human up”
puts “Eat food”
puts “Sleep in sun”
end
end
</pre>
After Form Template Refactor
<pre>
class Cat
def live
puts “Wake up”
do_morning_routine
puts “Sleep in the sun”
end
end
class Tiger < Cat
def do_morning_routine
puts “Catch deer”
puts “Eat deer”
end
end
class HouseCat < Cat
def do_morning_routine
puts “Wake human up”
puts “Eat food”
end
end
</pre>

===Large Method/Class===
If a project is not planned out well enough in advance, it is easy for methods and classes to become populated with excess functionality. While functionality of a block of code may be necessary for the project, the code block might not really pertain to the method or class it is included in.
*Extract Method
**This can be used when duplicate code occurs, as discussed above. But it can also be used when a method performs multiple functions that have the ability to be split up into various functions that serve a single purpose.
Before Refactoring
<pre>
def foo
puts "hey"
puts "how are you"
puts "bye!"
end
def bar
puts "bye!"
end
</pre>
After Extract Method Refactor
<pre>
def greet
puts "hey"
puts "how are you"
end
def farewell
puts "bye!"
end
def foo
greet
farewell
end
def bar
greet
end
</pre>
*Extract Class/Subclass/Superclass
**If there are class variables or methods that don’t directly pertain to a class, then it may be necessary to create a new class for those pieces.[http://www.refactoring.com/catalog/extractClass.html Example]
**If there are pieces of a class that are only for a specific subset of instances, then a subclass can be constructed to contain these.[http://www.refactoring.com/catalog/extractSubclass.html Example]
**If there are pieces that multiple classes use, then a superclass can be constructed to handle these generic functions, leaving the subclasses to deal with the remaining differences<ref>http://www.refactoring.com/catalog/extractSuperclass.html Example </ref>
Before Refactoring
<pre>
class Person
def initialize(f,m,l,s)
@firstName = f
@middleName = m
@lastName = l
@SSN = s
end
end
</pre>
After Extract Class Refactoring
<pre>

class FullName
def initialize(f,m,l)
@firstName = f
@middleName = m
@lastName = l
end
end

class Person
def initialize(f,m,l,s)
@name = FullName.new(f,m,l)
@SSN = s
end
end
</pre>

===Improving Readability and Clarity===
Many times, refactoring can be used to do simple, yet necessary changes like renaming variables, methods, or classes. As features get added to a project, classes tend to get charged with more uses than originally planned, so sometimes, the original naming scheme no longer applies and a new one needs to be instilled.

Moving methods and parameters around to where they have the best accessibility also has its uses. Classes also tend to be promoted or demoted to super and sub classes after their ultimate functional purpose is determined.

===More Techniques===
There many more techniques than those that are listed above. Each has its specific purpose, though one must take care to make sure that it is a necessary refactoring.

==Metrics==
It can be hard to decide whether or not to refactor, especially when it’s for something that appears to be working fine with just a surface level smell. Program analysis tools are used to derive various types of code metrics, which allow coders to identify problem areas and future pitfalls of their code base. These tools look at the code in several different ways, including the number of times a source file has been edited to help determine if it is a possible target of [feature envy], duplicate code structure to identify replicated lines, and block depths to suggest possible complexity issues.

===Open Source Ruby Metric Tools===
There are a variety of open source code metric tools that can be employed specifically for Ruby programs. [https://www.ruby-toolbox.com/categories/code_metrics The Ruby Toolbox] contains the most popular of these tools along with ratings.

[http://rubydoc.info/gems/simplecov/frames Simple Cov] is at the top of this list. It was developed specifically to be of use to anyone using any framework. It integrates itself with the project’s own test cases to check the code coverage of them in addition to cucumber features.

===Code Climate===
[https://codeclimate.com Code Climate] is a hosted code metrics tool that analyzes projects in a multitdue of ways. It produces three main metric ratings with grades from A-F that comprise of the methods and classes contained in each file and project.
#Complexity Metric - This is based off of the Assignment, Branches, and Conditions ([http://c2.com/cgi/wiki?AbcMetric ABC]) metric, where the number of assignments, branches, and conditions are counted and analyzed. However, because Code Climate is constructed for Ruby programs, it also takes into account certain types of Ruby constructs that may increase the metric score, but are actually beneficial to the project.
#Duplication Metric - This looks at the syntax trees of the code in order to identify identical and similar code structures. Because the syntax trees are being analyzed, code formatting and different method and class names do not affect the score. <ref>https://codeclimate.com/docs#quality-metrics</ref>
#Churn Method - This integrates with the Git repository to look at the change history of the project’s files. Files with excessively high change histories have a tendency to have a high complexity rating as well, as they can be the result of feature envy, where extra functions are added into a file instead of being added to a new file with its own functionality.

==Getting Started with Refactoring in Ruby==

===First step: Writing tests===
The first step in refactoring is writing solid set of tests for the section of code under consideration, in order to avoid introducing bugs. In Ruby, this can be done using [http://www.ruby-doc.org/stdlib-2.1.0/libdoc/test/unit/rdoc/Test/Unit.html Test::Unit] or [http://rspec.info/ Rspec]. Next step is to make small changes, test, make small changes, test again and so on<ref name='Refactoring Ruby Edition'>http://www.amazon.com/Refactoring-Edition-Addison-Wesley-Professional-Series/dp/0321984137</ref>. This ensures that we can revert back to the working version of code if any small refactoring causes the application to stop working.

===When to refactor===
It is always confusing when to start refactoring. If either one of the following conditions is true, it is a good time to start refactoring code<ref name='Refactoring Ruby Edition'/>:
* The Rule of Three - If any code segment gives trouble more than two times, it is time to refactor it
* Adding new function - It might be helpful to refactor when adding new functionality as it would give better understanding of code. Sometimes, revisiting old design might help to accommodate new features better
* Fixing a bug - It is useful to refactor code which had a bug; this might save bug reports from the same piece of code in future
* During code review - Refactoring is useful during code reviews as it can be applied immediately making code reviews more fruitful
* Understanding other's code - If a new member joins the team and is asked to refactor existing code, it helps them to get a better understanding of the code base. It might take extra time to get them started, but trying to refactor will help them contribute to the project better in the long run.

A [http://blog.codeclimate.com/blog/2014/01/09/when-is-it-time-to-refactor/ CodeClimate blog] suggests some other conditions to decide when to refactor code.

==Automated Code Refactoring==
=== RubyMine ===
*[http://www.jetbrains.com/ruby/webhelp/refactoring.html RubyMine] has a built in refactoring menu.
*To perform refactoring, select a code fragment to refactor. Refactorings available for your selection appear under the Refactor Menu in RubyMine. <ref>http://www.jetbrains.com/ruby/webhelp/refactoring-source-code.html#common</ref> [[File:RubyMine_refactoring_menu.png]]

===RFactor ===
*[http://fabiokung.com/2009/02/04/rfactor-ruby-refactoring-for-your-loved-editor/ RFactor] is a Ruby gem, which aims to provide common and simple refactorings for Ruby code for text editors like TextMate
*The first release has only Extract method implemented while other refactorings are coming soon
*It is available on [http://github.com/fabiokung/rfactor-tmbundle/tree/master GitHub]

=== Other IDEs ===
*Some other IDEs with built-in refactoring include [http://www.aptana.com/products/studio3 Aptana Studio], [http://www.aptana.com/products/radrails Aptana RadRails] and [https://netbeans.org/features/ruby/index.html NetBeans 7] (which requires Ruby and Rails [http://plugins.netbeans.org/plugin/38549 plugin])
*A StackOverflow [http://stackoverflow.com/questions/8705144/ide-with-refactoring-support-for-ruby-on-rails post] compares these tools ranking them as RubyMine being the best, followed by NetBeans, RadRails 2 and Aptana Studio 3

==Further Reading==
*[http://en.wikipedia.org/wiki/Code_smell Ways to identify problems in code]

*[http://blog.codeclimate.com/blog/2012/11/14/why-ruby-class-methods-resist-refactoring/ Resistance With Refactoring Ruby Class Methods]

*[http://www.railsinside.com/uncategorized/460-the-first-step-of-refactoring-a-rails-application.html Refactoring a Rails Application]

*[http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ Refactoring Fat Models]

*[https://speakerdeck.com/brianvh/refactoring-views-in-rails Talk on Refactoring Fat Views]

*[http://www.amazon.com/Rails-AntiPatterns-Refactoring-Addison-Wesley-Professional/dp/0321604814 Rails AntiPatterns: Best Practice Ruby on Rails Refactoring]

==References==
<references/>

CSC/ECE 517 Spring 2014/ch1a 1w1e rm

2014-02-19T04:51:01Z

Rjlloyd: /* Code Climate */

This page discusses refactoring techniques and metrics. It also includes tips on refactoring in Ruby and list of tools for automated refactoring.

==Background==

The idea behind [http://en.wikipedia.org/wiki/Code_refactoring code refactoring] is to take a code base and improve its readability, [http://en.wikipedia.org/wiki/Extensibility extensibility], and [http://en.wikipedia.org/wiki/Reusability reusability]. The practice is focused on having a better quality and more standardized code base, and not on fixing bugs or changing functionality.

Refactoring has its difficulties, whether or not it is done using an [http://en.wikipedia.org/wiki/Integrated_development_environment IDE] or whether it is done by hand. There are lots of pitfalls and errors that can be made during refactoring, so it is pertinent to determine how important a refactor is to the code. Code metrics are one method used to determine how badly a file needs refactoring.

==Refactoring Techniques==
Before a coder performs a refactor, they must, either formally or informally, identify their ‘code smells’. A code smell refers to a negative quality of a code base that either implements bad programming practices or slows down code development or runtime. These aren't typically bugs, but can increase the chance of bugs later on if not fixed. Based on the type of code smell, a different refactoring technique is used to fix it.

===Duplicate Code===
Duplicate code can be a tricky concept when refactoring. Large sections of duplicated code can be easy to find and fixed by pulling it out and creating a single centralized method to call, however it is usually not that easy. Sometimes it may only be one or two lines of code that are duplicated which calls for an assessment of whether or not it is in the best interest to create a new method for a couple lines of code. Other times, code is not duplicate, rather it is similar enough that a generic method could be created to serve various purposes.
Some specific techniques to deal with this are:
*Extract Method / Pull-up Method
**If common code is used in multiple places, simply pull it out and make a method that can be called from all of the necessary places. Variables can be passed in if slight variations are needed between calls.
**If the code is used in various subclasses, put the common code in a method in the superclass, so that it can be seen and called by its children.<ref>http://www.refactoring.com/catalog/extractMethod.html Extract Method Example</ref>
Before Refactor
<pre>
class Cat
end

class Lion < Mammal
def likes
puts "Boxes"
end
end
class HouseCat < Mammal
def likes
puts "Boxes"
end
end
</pre>
After Pull Up Refactor
<pre>
class Cat
def likes
puts "Boxes"
end
end

class Lion < Mammal
end
class HouseCat < Mammal
end
</pre>

*Form Template Method
**If two methods in subclasses perform similar steps in the same order, but the steps are different, then get the steps into methods with the same signature, so that the original methods become the same. Then pull them up. <ref>http://www.refactoring.com/catalog/formTemplateMethod.html</ref>
Before Refactor
<pre>
class Cat
end
class Tiger < Cat
def live
puts “Wake up”
puts “Catch deer”
puts “Eat deer”
puts “Sleep in sun”
end
end
class HouseCat < Cat
def live
puts “Wake up”
puts “Wake human up”
puts “Eat food”
puts “Sleep in sun”
end
end
</pre>
After Form Template Refactor
<pre>
class Cat
def live
puts “Wake up”
do_morning_routine
puts “Sleep in the sun”
end
end
class Tiger < Cat
def do_morning_routine
puts “Catch deer”
puts “Eat deer”
end
end
class HouseCat < Cat
def do_morning_routine
puts “Wake human up”
puts “Eat food”
end
end
</pre>

===Large Method/Class===
If a project is not planned out well enough in advance, it is easy for methods and classes to become populated with excess functionality. While functionality of a block of code may be necessary for the project, the code block might not really pertain to the method or class it is included in.
*Extract Method
**This can be used when duplicate code occurs, as discussed above. But it can also be used when a method performs multiple functions that have the ability to be split up into various functions that serve a single purpose.
Before Refactoring
<pre>
def foo
puts "hey"
puts "how are you"
puts "bye!"
end
def bar
puts "bye!"
end
</pre>
After Extract Method Refactor
<pre>
def greet
puts "hey"
puts "how are you"
end
def farewell
puts "bye!"
end
def foo
greet
farewell
end
def bar
greet
end
</pre>
*Extract Class/Subclass/Superclass
**If there are class variables or methods that don’t directly pertain to a class, then it may be necessary to create a new class for those pieces.[http://www.refactoring.com/catalog/extractClass.html Example]
**If there are pieces of a class that are only for a specific subset of instances, then a subclass can be constructed to contain these.[http://www.refactoring.com/catalog/extractSubclass.html Example]
**If there are pieces that multiple classes use, then a superclass can be constructed to handle these generic functions, leaving the subclasses to deal with the remaining differences<ref>http://www.refactoring.com/catalog/extractSuperclass.html Example </ref>
Before Refactoring
<pre>
class Person
def initialize(f,m,l,s)
@firstName = f
@middleName = m
@lastName = l
@SSN = s
end
end
</pre>
After Extract Class Refactoring
<pre>

class FullName
def initialize(f,m,l)
@firstName = f
@middleName = m
@lastName = l
end
end

class Person
def initialize(f,m,l,s)
@name = FullName.new(f,m,l)
@SSN = s
end
end
</pre>

===Improving Readability and Clarity===
Many times, refactoring can be used to do simple, yet necessary changes like renaming variables, methods, or classes. As features get added to a project, classes tend to get charged with more uses than originally planned, so sometimes, the original naming scheme no longer applies and a new one needs to be instilled.

Moving methods and parameters around to where they have the best accessibility also has its uses. Classes also tend to be promoted or demoted to super and sub classes after their ultimate functional purpose is determined.

===More Techniques===
There is an extensive list of coding smells that can be improved through refactoring.

A description of smells with their techniques exists [http://ghendry.net/refactor.html here].

A list of techniques with examples in Ruby are listed [http://www.refactoring.com/catalog/index.html here].

==Metrics==
It can be hard to decide whether or not to refactor, especially when it’s for something that appears to be working fine with just a surface level smell. Program analysis tools are used to derive various types of code metrics, which allow coders to identify problem areas and future pitfalls of their code base. These tools look at the code in several different ways, including the number of times a source file has been edited to help determine if it is a possible target of [feature envy], duplicate code structure to identify replicated lines, and block depths to suggest possible complexity issues.

===Open Source Ruby Metric Tools===
There are a variety of open source code metric tools that can be employed specifically for Ruby programs. [https://www.ruby-toolbox.com/categories/code_metrics The Ruby Toolbox] contains the most popular of these tools along with ratings.

[http://rubydoc.info/gems/simplecov/frames Simple Cov] is at the top of this list. It was developed specifically to be of use to anyone using any framework. It integrates itself with the project’s own test cases to check the code coverage of them in addition to cucumber features.

===Code Climate===
[https://codeclimate.com Code Climate] is a hosted code metrics tool that analyzes projects in a multitdue of ways. It produces three main metric ratings with grades from A-F that comprise of the methods and classes contained in each file and project.
#Complexity Metric - This is based off of the Assignment, Branches, and Conditions ([http://c2.com/cgi/wiki?AbcMetric ABC]) metric, where the number of assignments, branches, and conditions are counted and analyzed. However, because Code Climate is constructed for Ruby programs, it also takes into account certain types of Ruby constructs that may increase the metric score, but are actually beneficial to the project.
#Duplication Metric - This looks at the syntax trees of the code in order to identify identical and similar code structures. Because the syntax trees are being analyzed, code formatting and different method and class names do not affect the score. <ref>https://codeclimate.com/docs#quality-metrics</ref>
#Churn Method - This integrates with the Git repository to look at the change history of the project’s files. Files with excessively high change histories have a tendency to have a high complexity rating as well, as they can be the result of feature envy, where extra functions are added into a file instead of being added to a new file with its own functionality.

==Getting Started with Refactoring in Ruby==

===First step: Writing tests===
The first step in refactoring is writing solid set of tests for the section of code under consideration, in order to avoid introducing bugs. In Ruby, this can be done using [http://www.ruby-doc.org/stdlib-2.1.0/libdoc/test/unit/rdoc/Test/Unit.html Test::Unit] or [http://rspec.info/ Rspec]. Next step is to make small changes, test, make small changes, test again and so on<ref name='Refactoring Ruby Edition'>http://www.amazon.com/Refactoring-Edition-Addison-Wesley-Professional-Series/dp/0321984137</ref>. This ensures that we can revert back to the working version of code if any small refactoring causes the application to stop working.

===When to refactor===
It is always confusing when to start refactoring. If either one of the following conditions is true, it is a good time to start refactoring code<ref name='Refactoring Ruby Edition'/>:
* The Rule of Three - If any code segment gives trouble more than two times, it is time to refactor it
* Adding new function - It might be helpful to refactor when adding new functionality as it would give better understanding of code. Sometimes, revisiting old design might help to accommodate new features better
* Fixing a bug - It is useful to refactor code which had a bug; this might save bug reports from the same piece of code in future
* During code review - Refactoring is useful during code reviews as it can be applied immediately making code reviews more fruitful
* Understanding other's code - If a new member joins the team and is asked to refactor existing code, it helps them to get a better understanding of the code base. It might take extra time to get them started, but trying to refactor will help them contribute to the project better in the long run.

A [http://blog.codeclimate.com/blog/2014/01/09/when-is-it-time-to-refactor/ CodeClimate blog] suggests some other conditions to decide when to refactor code.

==Automated Code Refactoring==
=== RubyMine ===
*[http://www.jetbrains.com/ruby/webhelp/refactoring.html RubyMine] has a built in refactoring menu.
*To perform refactoring, select a code fragment to refactor. Refactorings available for your selection appear under the Refactor Menu in RubyMine. <ref>http://www.jetbrains.com/ruby/webhelp/refactoring-source-code.html#common</ref> [[File:RubyMine_refactoring_menu.png]]

===RFactor ===
*[http://fabiokung.com/2009/02/04/rfactor-ruby-refactoring-for-your-loved-editor/ RFactor] is a Ruby gem, which aims to provide common and simple refactorings for Ruby code for text editors like TextMate
*The first release has only Extract method implemented while other refactorings are coming soon
*It is available on [http://github.com/fabiokung/rfactor-tmbundle/tree/master GitHub]

=== Other IDEs ===
*Some other IDEs with built-in refactoring include [http://www.aptana.com/products/studio3 Aptana Studio], [http://www.aptana.com/products/radrails Aptana RadRails] and [https://netbeans.org/features/ruby/index.html NetBeans 7] (which requires Ruby and Rails [http://plugins.netbeans.org/plugin/38549 plugin])
*A StackOverflow [http://stackoverflow.com/questions/8705144/ide-with-refactoring-support-for-ruby-on-rails post] compares these tools ranking them as RubyMine being the best, followed by NetBeans, RadRails 2 and Aptana Studio 3

==Further Reading==
*[http://en.wikipedia.org/wiki/Code_smell Ways to identify problems in code]

*[http://blog.codeclimate.com/blog/2012/11/14/why-ruby-class-methods-resist-refactoring/ Resistance With Refactoring Ruby Class Methods]

*[http://www.railsinside.com/uncategorized/460-the-first-step-of-refactoring-a-rails-application.html Refactoring a Rails Application]

*[http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ Refactoring Fat Models]

*[https://speakerdeck.com/brianvh/refactoring-views-in-rails Talk on Refactoring Fat Views]

*[http://www.amazon.com/Rails-AntiPatterns-Refactoring-Addison-Wesley-Professional/dp/0321604814 Rails AntiPatterns: Best Practice Ruby on Rails Refactoring]

==References==
<references/>

CSC/ECE 517 Spring 2014/ch1a 1w1e rm

2014-02-19T04:50:40Z

Rjlloyd: /* Duplicate Code */

This page discusses refactoring techniques and metrics. It also includes tips on refactoring in Ruby and list of tools for automated refactoring.

==Background==

The idea behind [http://en.wikipedia.org/wiki/Code_refactoring code refactoring] is to take a code base and improve its readability, [http://en.wikipedia.org/wiki/Extensibility extensibility], and [http://en.wikipedia.org/wiki/Reusability reusability]. The practice is focused on having a better quality and more standardized code base, and not on fixing bugs or changing functionality.

Refactoring has its difficulties, whether or not it is done using an [http://en.wikipedia.org/wiki/Integrated_development_environment IDE] or whether it is done by hand. There are lots of pitfalls and errors that can be made during refactoring, so it is pertinent to determine how important a refactor is to the code. Code metrics are one method used to determine how badly a file needs refactoring.

==Refactoring Techniques==
Before a coder performs a refactor, they must, either formally or informally, identify their ‘code smells’. A code smell refers to a negative quality of a code base that either implements bad programming practices or slows down code development or runtime. These aren't typically bugs, but can increase the chance of bugs later on if not fixed. Based on the type of code smell, a different refactoring technique is used to fix it.

===Duplicate Code===
Duplicate code can be a tricky concept when refactoring. Large sections of duplicated code can be easy to find and fixed by pulling it out and creating a single centralized method to call, however it is usually not that easy. Sometimes it may only be one or two lines of code that are duplicated which calls for an assessment of whether or not it is in the best interest to create a new method for a couple lines of code. Other times, code is not duplicate, rather it is similar enough that a generic method could be created to serve various purposes.
Some specific techniques to deal with this are:
*Extract Method / Pull-up Method
**If common code is used in multiple places, simply pull it out and make a method that can be called from all of the necessary places. Variables can be passed in if slight variations are needed between calls.
**If the code is used in various subclasses, put the common code in a method in the superclass, so that it can be seen and called by its children.<ref>http://www.refactoring.com/catalog/extractMethod.html Extract Method Example</ref>
Before Refactor
<pre>
class Cat
end

class Lion < Mammal
def likes
puts "Boxes"
end
end
class HouseCat < Mammal
def likes
puts "Boxes"
end
end
</pre>
After Pull Up Refactor
<pre>
class Cat
def likes
puts "Boxes"
end
end

class Lion < Mammal
end
class HouseCat < Mammal
end
</pre>

*Form Template Method
**If two methods in subclasses perform similar steps in the same order, but the steps are different, then get the steps into methods with the same signature, so that the original methods become the same. Then pull them up. <ref>http://www.refactoring.com/catalog/formTemplateMethod.html</ref>
Before Refactor
<pre>
class Cat
end
class Tiger < Cat
def live
puts “Wake up”
puts “Catch deer”
puts “Eat deer”
puts “Sleep in sun”
end
end
class HouseCat < Cat
def live
puts “Wake up”
puts “Wake human up”
puts “Eat food”
puts “Sleep in sun”
end
end
</pre>
After Form Template Refactor
<pre>
class Cat
def live
puts “Wake up”
do_morning_routine
puts “Sleep in the sun”
end
end
class Tiger < Cat
def do_morning_routine
puts “Catch deer”
puts “Eat deer”
end
end
class HouseCat < Cat
def do_morning_routine
puts “Wake human up”
puts “Eat food”
end
end
</pre>

===Large Method/Class===
If a project is not planned out well enough in advance, it is easy for methods and classes to become populated with excess functionality. While functionality of a block of code may be necessary for the project, the code block might not really pertain to the method or class it is included in.
*Extract Method
**This can be used when duplicate code occurs, as discussed above. But it can also be used when a method performs multiple functions that have the ability to be split up into various functions that serve a single purpose.
Before Refactoring
<pre>
def foo
puts "hey"
puts "how are you"
puts "bye!"
end
def bar
puts "bye!"
end
</pre>
After Extract Method Refactor
<pre>
def greet
puts "hey"
puts "how are you"
end
def farewell
puts "bye!"
end
def foo
greet
farewell
end
def bar
greet
end
</pre>
*Extract Class/Subclass/Superclass
**If there are class variables or methods that don’t directly pertain to a class, then it may be necessary to create a new class for those pieces.[http://www.refactoring.com/catalog/extractClass.html Example]
**If there are pieces of a class that are only for a specific subset of instances, then a subclass can be constructed to contain these.[http://www.refactoring.com/catalog/extractSubclass.html Example]
**If there are pieces that multiple classes use, then a superclass can be constructed to handle these generic functions, leaving the subclasses to deal with the remaining differences<ref>http://www.refactoring.com/catalog/extractSuperclass.html Example </ref>
Before Refactoring
<pre>
class Person
def initialize(f,m,l,s)
@firstName = f
@middleName = m
@lastName = l
@SSN = s
end
end
</pre>
After Extract Class Refactoring
<pre>

class FullName
def initialize(f,m,l)
@firstName = f
@middleName = m
@lastName = l
end
end

class Person
def initialize(f,m,l,s)
@name = FullName.new(f,m,l)
@SSN = s
end
end
</pre>

===Improving Readability and Clarity===
Many times, refactoring can be used to do simple, yet necessary changes like renaming variables, methods, or classes. As features get added to a project, classes tend to get charged with more uses than originally planned, so sometimes, the original naming scheme no longer applies and a new one needs to be instilled.

Moving methods and parameters around to where they have the best accessibility also has its uses. Classes also tend to be promoted or demoted to super and sub classes after their ultimate functional purpose is determined.

===More Techniques===
There is an extensive list of coding smells that can be improved through refactoring.

A description of smells with their techniques exists [http://ghendry.net/refactor.html here].

A list of techniques with examples in Ruby are listed [http://www.refactoring.com/catalog/index.html here].

==Metrics==
It can be hard to decide whether or not to refactor, especially when it’s for something that appears to be working fine with just a surface level smell. Program analysis tools are used to derive various types of code metrics, which allow coders to identify problem areas and future pitfalls of their code base. These tools look at the code in several different ways, including the number of times a source file has been edited to help determine if it is a possible target of [feature envy], duplicate code structure to identify replicated lines, and block depths to suggest possible complexity issues.

===Open Source Ruby Metric Tools===
There are a variety of open source code metric tools that can be employed specifically for Ruby programs. [https://www.ruby-toolbox.com/categories/code_metrics The Ruby Toolbox] contains the most popular of these tools along with ratings.

[http://rubydoc.info/gems/simplecov/frames Simple Cov] is at the top of this list. It was developed specifically to be of use to anyone using any framework. It integrates itself with the project’s own test cases to check the code coverage of them in addition to cucumber features.

===Code Climate===
[https://codeclimate.com Code Climate] is a hosted code metrics tool that analyzes projects in a multitdue of ways. It produces three main metric ratings with grades from A-F that comprise of the methods and classes contained in each file and project.
#Complexity Metric - This is based off of the Assignment, Branches, and Conditions ([http://c2.com/cgi/wiki?AbcMetric ABC]) metric, where the number of assignments, branches, and conditions are counted and analyzed. However, because Code Climate is constructed for Ruby programs, it also takes into account certain types of Ruby constructs that may increase the metric score, but are actually beneficial to the project.
#Duplication Metric - This looks at the syntax trees of the code in order to identify identical and similar code structures. Because the syntax trees are being analyzed, code formatting and different method and class names do not affect the score. <ref>https://codeclimate.com/docs#quality-metrics</ref>
#Churn Method - This integrates with the Git repository to look at the change history of the project’s files. Files with excessively high change histories have a tendency to have a high complexity rating as well, as they can be the result of feature envy, where extra functions are added into a file instead of being added to a new file with it’s own functionality.

==Getting Started with Refactoring in Ruby==

===First step: Writing tests===
The first step in refactoring is writing solid set of tests for the section of code under consideration, in order to avoid introducing bugs. In Ruby, this can be done using [http://www.ruby-doc.org/stdlib-2.1.0/libdoc/test/unit/rdoc/Test/Unit.html Test::Unit] or [http://rspec.info/ Rspec]. Next step is to make small changes, test, make small changes, test again and so on<ref name='Refactoring Ruby Edition'>http://www.amazon.com/Refactoring-Edition-Addison-Wesley-Professional-Series/dp/0321984137</ref>. This ensures that we can revert back to the working version of code if any small refactoring causes the application to stop working.

===When to refactor===
It is always confusing when to start refactoring. If either one of the following conditions is true, it is a good time to start refactoring code<ref name='Refactoring Ruby Edition'/>:
* The Rule of Three - If any code segment gives trouble more than two times, it is time to refactor it
* Adding new function - It might be helpful to refactor when adding new functionality as it would give better understanding of code. Sometimes, revisiting old design might help to accommodate new features better
* Fixing a bug - It is useful to refactor code which had a bug; this might save bug reports from the same piece of code in future
* During code review - Refactoring is useful during code reviews as it can be applied immediately making code reviews more fruitful
* Understanding other's code - If a new member joins the team and is asked to refactor existing code, it helps them to get a better understanding of the code base. It might take extra time to get them started, but trying to refactor will help them contribute to the project better in the long run.

A [http://blog.codeclimate.com/blog/2014/01/09/when-is-it-time-to-refactor/ CodeClimate blog] suggests some other conditions to decide when to refactor code.

==Automated Code Refactoring==
=== RubyMine ===
*[http://www.jetbrains.com/ruby/webhelp/refactoring.html RubyMine] has a built in refactoring menu.
*To perform refactoring, select a code fragment to refactor. Refactorings available for your selection appear under the Refactor Menu in RubyMine. <ref>http://www.jetbrains.com/ruby/webhelp/refactoring-source-code.html#common</ref> [[File:RubyMine_refactoring_menu.png]]

===RFactor ===
*[http://fabiokung.com/2009/02/04/rfactor-ruby-refactoring-for-your-loved-editor/ RFactor] is a Ruby gem, which aims to provide common and simple refactorings for Ruby code for text editors like TextMate
*The first release has only Extract method implemented while other refactorings are coming soon
*It is available on [http://github.com/fabiokung/rfactor-tmbundle/tree/master GitHub]

=== Other IDEs ===
*Some other IDEs with built-in refactoring include [http://www.aptana.com/products/studio3 Aptana Studio], [http://www.aptana.com/products/radrails Aptana RadRails] and [https://netbeans.org/features/ruby/index.html NetBeans 7] (which requires Ruby and Rails [http://plugins.netbeans.org/plugin/38549 plugin])
*A StackOverflow [http://stackoverflow.com/questions/8705144/ide-with-refactoring-support-for-ruby-on-rails post] compares these tools ranking them as RubyMine being the best, followed by NetBeans, RadRails 2 and Aptana Studio 3

==Further Reading==
*[http://en.wikipedia.org/wiki/Code_smell Ways to identify problems in code]

*[http://blog.codeclimate.com/blog/2012/11/14/why-ruby-class-methods-resist-refactoring/ Resistance With Refactoring Ruby Class Methods]

*[http://www.railsinside.com/uncategorized/460-the-first-step-of-refactoring-a-rails-application.html Refactoring a Rails Application]

*[http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ Refactoring Fat Models]

*[https://speakerdeck.com/brianvh/refactoring-views-in-rails Talk on Refactoring Fat Views]

*[http://www.amazon.com/Rails-AntiPatterns-Refactoring-Addison-Wesley-Professional/dp/0321604814 Rails AntiPatterns: Best Practice Ruby on Rails Refactoring]

==References==
<references/>

CSC/ECE 517 Spring 2014/ch1a 1w1e rm

2014-02-19T04:50:26Z

Rjlloyd: /* Background */

This page discusses refactoring techniques and metrics. It also includes tips on refactoring in Ruby and list of tools for automated refactoring.

==Background==

The idea behind [http://en.wikipedia.org/wiki/Code_refactoring code refactoring] is to take a code base and improve its readability, [http://en.wikipedia.org/wiki/Extensibility extensibility], and [http://en.wikipedia.org/wiki/Reusability reusability]. The practice is focused on having a better quality and more standardized code base, and not on fixing bugs or changing functionality.

Refactoring has its difficulties, whether or not it is done using an [http://en.wikipedia.org/wiki/Integrated_development_environment IDE] or whether it is done by hand. There are lots of pitfalls and errors that can be made during refactoring, so it is pertinent to determine how important a refactor is to the code. Code metrics are one method used to determine how badly a file needs refactoring.

==Refactoring Techniques==
Before a coder performs a refactor, they must, either formally or informally, identify their ‘code smells’. A code smell refers to a negative quality of a code base that either implements bad programming practices or slows down code development or runtime. These aren't typically bugs, but can increase the chance of bugs later on if not fixed. Based on the type of code smell, a different refactoring technique is used to fix it.

===Duplicate Code===
Duplicate code can be a tricky concept when refactoring. Large sections of duplicated code can be easy to find and fixed by pulling it out and creating a single centralized method to call, however it is usually not that easy. Sometimes it may only be one or two lines of code that are duplicated which calls for an assessment of whether or not it is in the best interest to create a new method for a couple lines of code. Other times, code is not duplicate, rather it is similar enough that a generic method could be created to serve various purposes.
Some specific techniques to deal with this are:
*Extract Method / Pull-up Method
**If common code is used in multiple places, simply pull it out and make a method that can be called from all of the necessary places. Variables can be passed in if slight variations are needed between calls.
**If the code is used in various subclasses, put the common code in a method in the superclass, so that it can be seen and called by it’s children.<ref>http://www.refactoring.com/catalog/extractMethod.html Extract Method Example</ref>
Before Refactor
<pre>
class Cat
end

class Lion < Mammal
def likes
puts "Boxes"
end
end
class HouseCat < Mammal
def likes
puts "Boxes"
end
end
</pre>
After Pull Up Refactor
<pre>
class Cat
def likes
puts "Boxes"
end
end

class Lion < Mammal
end
class HouseCat < Mammal
end
</pre>

*Form Template Method
**If two methods in subclasses perform similar steps in the same order, but the steps are different, then get the steps into methods with the same signature, so that the original methods become the same. Then pull them up. <ref>http://www.refactoring.com/catalog/formTemplateMethod.html</ref>
Before Refactor
<pre>
class Cat
end
class Tiger < Cat
def live
puts “Wake up”
puts “Catch deer”
puts “Eat deer”
puts “Sleep in sun”
end
end
class HouseCat < Cat
def live
puts “Wake up”
puts “Wake human up”
puts “Eat food”
puts “Sleep in sun”
end
end
</pre>
After Form Template Refactor
<pre>
class Cat
def live
puts “Wake up”
do_morning_routine
puts “Sleep in the sun”
end
end
class Tiger < Cat
def do_morning_routine
puts “Catch deer”
puts “Eat deer”
end
end
class HouseCat < Cat
def do_morning_routine
puts “Wake human up”
puts “Eat food”
end
end
</pre>

===Large Method/Class===
If a project is not planned out well enough in advance, it is easy for methods and classes to become populated with excess functionality. While functionality of a block of code may be necessary for the project, the code block might not really pertain to the method or class it is included in.
*Extract Method
**This can be used when duplicate code occurs, as discussed above. But it can also be used when a method performs multiple functions that have the ability to be split up into various functions that serve a single purpose.
Before Refactoring
<pre>
def foo
puts "hey"
puts "how are you"
puts "bye!"
end
def bar
puts "bye!"
end
</pre>
After Extract Method Refactor
<pre>
def greet
puts "hey"
puts "how are you"
end
def farewell
puts "bye!"
end
def foo
greet
farewell
end
def bar
greet
end
</pre>
*Extract Class/Subclass/Superclass
**If there are class variables or methods that don’t directly pertain to a class, then it may be necessary to create a new class for those pieces.[http://www.refactoring.com/catalog/extractClass.html Example]
**If there are pieces of a class that are only for a specific subset of instances, then a subclass can be constructed to contain these.[http://www.refactoring.com/catalog/extractSubclass.html Example]
**If there are pieces that multiple classes use, then a superclass can be constructed to handle these generic functions, leaving the subclasses to deal with the remaining differences<ref>http://www.refactoring.com/catalog/extractSuperclass.html Example </ref>
Before Refactoring
<pre>
class Person
def initialize(f,m,l,s)
@firstName = f
@middleName = m
@lastName = l
@SSN = s
end
end
</pre>
After Extract Class Refactoring
<pre>

class FullName
def initialize(f,m,l)
@firstName = f
@middleName = m
@lastName = l
end
end

class Person
def initialize(f,m,l,s)
@name = FullName.new(f,m,l)
@SSN = s
end
end
</pre>

===Improving Readability and Clarity===
Many times, refactoring can be used to do simple, yet necessary changes like renaming variables, methods, or classes. As features get added to a project, classes tend to get charged with more uses than originally planned, so sometimes, the original naming scheme no longer applies and a new one needs to be instilled.

Moving methods and parameters around to where they have the best accessibility also has its uses. Classes also tend to be promoted or demoted to super and sub classes after their ultimate functional purpose is determined.

===More Techniques===
There is an extensive list of coding smells that can be improved through refactoring.

A description of smells with their techniques exists [http://ghendry.net/refactor.html here].

A list of techniques with examples in Ruby are listed [http://www.refactoring.com/catalog/index.html here].

==Metrics==
It can be hard to decide whether or not to refactor, especially when it’s for something that appears to be working fine with just a surface level smell. Program analysis tools are used to derive various types of code metrics, which allow coders to identify problem areas and future pitfalls of their code base. These tools look at the code in several different ways, including the number of times a source file has been edited to help determine if it is a possible target of [feature envy], duplicate code structure to identify replicated lines, and block depths to suggest possible complexity issues.

===Open Source Ruby Metric Tools===
There are a variety of open source code metric tools that can be employed specifically for Ruby programs. [https://www.ruby-toolbox.com/categories/code_metrics The Ruby Toolbox] contains the most popular of these tools along with ratings.

[http://rubydoc.info/gems/simplecov/frames Simple Cov] is at the top of this list. It was developed specifically to be of use to anyone using any framework. It integrates itself with the project’s own test cases to check the code coverage of them in addition to cucumber features.

===Code Climate===
[https://codeclimate.com Code Climate] is a hosted code metrics tool that analyzes projects in a multitdue of ways. It produces three main metric ratings with grades from A-F that comprise of the methods and classes contained in each file and project.
#Complexity Metric - This is based off of the Assignment, Branches, and Conditions ([http://c2.com/cgi/wiki?AbcMetric ABC]) metric, where the number of assignments, branches, and conditions are counted and analyzed. However, because Code Climate is constructed for Ruby programs, it also takes into account certain types of Ruby constructs that may increase the metric score, but are actually beneficial to the project.
#Duplication Metric - This looks at the syntax trees of the code in order to identify identical and similar code structures. Because the syntax trees are being analyzed, code formatting and different method and class names do not affect the score. <ref>https://codeclimate.com/docs#quality-metrics</ref>
#Churn Method - This integrates with the Git repository to look at the change history of the project’s files. Files with excessively high change histories have a tendency to have a high complexity rating as well, as they can be the result of feature envy, where extra functions are added into a file instead of being added to a new file with it’s own functionality.

==Getting Started with Refactoring in Ruby==

===First step: Writing tests===
The first step in refactoring is writing solid set of tests for the section of code under consideration, in order to avoid introducing bugs. In Ruby, this can be done using [http://www.ruby-doc.org/stdlib-2.1.0/libdoc/test/unit/rdoc/Test/Unit.html Test::Unit] or [http://rspec.info/ Rspec]. Next step is to make small changes, test, make small changes, test again and so on<ref name='Refactoring Ruby Edition'>http://www.amazon.com/Refactoring-Edition-Addison-Wesley-Professional-Series/dp/0321984137</ref>. This ensures that we can revert back to the working version of code if any small refactoring causes the application to stop working.

===When to refactor===
It is always confusing when to start refactoring. If either one of the following conditions is true, it is a good time to start refactoring code<ref name='Refactoring Ruby Edition'/>:
* The Rule of Three - If any code segment gives trouble more than two times, it is time to refactor it
* Adding new function - It might be helpful to refactor when adding new functionality as it would give better understanding of code. Sometimes, revisiting old design might help to accommodate new features better
* Fixing a bug - It is useful to refactor code which had a bug; this might save bug reports from the same piece of code in future
* During code review - Refactoring is useful during code reviews as it can be applied immediately making code reviews more fruitful
* Understanding other's code - If a new member joins the team and is asked to refactor existing code, it helps them to get a better understanding of the code base. It might take extra time to get them started, but trying to refactor will help them contribute to the project better in the long run.

A [http://blog.codeclimate.com/blog/2014/01/09/when-is-it-time-to-refactor/ CodeClimate blog] suggests some other conditions to decide when to refactor code.

==Automated Code Refactoring==
=== RubyMine ===
*[http://www.jetbrains.com/ruby/webhelp/refactoring.html RubyMine] has a built in refactoring menu.
*To perform refactoring, select a code fragment to refactor. Refactorings available for your selection appear under the Refactor Menu in RubyMine. <ref>http://www.jetbrains.com/ruby/webhelp/refactoring-source-code.html#common</ref> [[File:RubyMine_refactoring_menu.png]]

===RFactor ===
*[http://fabiokung.com/2009/02/04/rfactor-ruby-refactoring-for-your-loved-editor/ RFactor] is a Ruby gem, which aims to provide common and simple refactorings for Ruby code for text editors like TextMate
*The first release has only Extract method implemented while other refactorings are coming soon
*It is available on [http://github.com/fabiokung/rfactor-tmbundle/tree/master GitHub]

=== Other IDEs ===
*Some other IDEs with built-in refactoring include [http://www.aptana.com/products/studio3 Aptana Studio], [http://www.aptana.com/products/radrails Aptana RadRails] and [https://netbeans.org/features/ruby/index.html NetBeans 7] (which requires Ruby and Rails [http://plugins.netbeans.org/plugin/38549 plugin])
*A StackOverflow [http://stackoverflow.com/questions/8705144/ide-with-refactoring-support-for-ruby-on-rails post] compares these tools ranking them as RubyMine being the best, followed by NetBeans, RadRails 2 and Aptana Studio 3

==Further Reading==
*[http://en.wikipedia.org/wiki/Code_smell Ways to identify problems in code]

*[http://blog.codeclimate.com/blog/2012/11/14/why-ruby-class-methods-resist-refactoring/ Resistance With Refactoring Ruby Class Methods]

*[http://www.railsinside.com/uncategorized/460-the-first-step-of-refactoring-a-rails-application.html Refactoring a Rails Application]

*[http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ Refactoring Fat Models]

*[https://speakerdeck.com/brianvh/refactoring-views-in-rails Talk on Refactoring Fat Views]

*[http://www.amazon.com/Rails-AntiPatterns-Refactoring-Addison-Wesley-Professional/dp/0321604814 Rails AntiPatterns: Best Practice Ruby on Rails Refactoring]

==References==
<references/>

CSC/ECE 517 Spring 2014/ch1a 1w1e rm

2014-02-19T04:49:29Z

Rjlloyd: /* Large Method/Class */

This page discusses refactoring techniques and metrics. It also includes tips on refactoring in Ruby and list of tools for automated refactoring.

==Background==

The idea behind [http://en.wikipedia.org/wiki/Code_refactoring code refactoring] is to take a code base and improve it's readability, [http://en.wikipedia.org/wiki/Extensibility extensibility], and [http://en.wikipedia.org/wiki/Reusability reusability]. The practice is focused on having a better quality and more standardized code base, and not on fixing bugs or changing functionality.

Refactoring has its difficulties, whether or not it is done using an [http://en.wikipedia.org/wiki/Integrated_development_environment IDE] or whether it is done by hand. There are lots of pitfalls and errors that can be made during refactoring, so it is pertinent to determine how important a refactor is to the code. Code metrics are one method used to determine how badly a file needs refactoring.

==Refactoring Techniques==
Before a coder performs a refactor, they must, either formally or informally, identify their ‘code smells’. A code smell refers to a negative quality of a code base that either implements bad programming practices or slows down code development or runtime. These aren't typically bugs, but can increase the chance of bugs later on if not fixed. Based on the type of code smell, a different refactoring technique is used to fix it.

===Duplicate Code===
Duplicate code can be a tricky concept when refactoring. Large sections of duplicated code can be easy to find and fixed by pulling it out and creating a single centralized method to call, however it is usually not that easy. Sometimes it may only be one or two lines of code that are duplicated which calls for an assessment of whether or not it is in the best interest to create a new method for a couple lines of code. Other times, code is not duplicate, rather it is similar enough that a generic method could be created to serve various purposes.
Some specific techniques to deal with this are:
*Extract Method / Pull-up Method
**If common code is used in multiple places, simply pull it out and make a method that can be called from all of the necessary places. Variables can be passed in if slight variations are needed between calls.
**If the code is used in various subclasses, put the common code in a method in the superclass, so that it can be seen and called by it’s children.<ref>http://www.refactoring.com/catalog/extractMethod.html Extract Method Example</ref>
Before Refactor
<pre>
class Cat
end

class Lion < Mammal
def likes
puts "Boxes"
end
end
class HouseCat < Mammal
def likes
puts "Boxes"
end
end
</pre>
After Pull Up Refactor
<pre>
class Cat
def likes
puts "Boxes"
end
end

class Lion < Mammal
end
class HouseCat < Mammal
end
</pre>

*Form Template Method
**If two methods in subclasses perform similar steps in the same order, but the steps are different, then get the steps into methods with the same signature, so that the original methods become the same. Then pull them up. <ref>http://www.refactoring.com/catalog/formTemplateMethod.html</ref>
Before Refactor
<pre>
class Cat
end
class Tiger < Cat
def live
puts “Wake up”
puts “Catch deer”
puts “Eat deer”
puts “Sleep in sun”
end
end
class HouseCat < Cat
def live
puts “Wake up”
puts “Wake human up”
puts “Eat food”
puts “Sleep in sun”
end
end
</pre>
After Form Template Refactor
<pre>
class Cat
def live
puts “Wake up”
do_morning_routine
puts “Sleep in the sun”
end
end
class Tiger < Cat
def do_morning_routine
puts “Catch deer”
puts “Eat deer”
end
end
class HouseCat < Cat
def do_morning_routine
puts “Wake human up”
puts “Eat food”
end
end
</pre>

===Large Method/Class===
If a project is not planned out well enough in advance, it is easy for methods and classes to become populated with excess functionality. While functionality of a block of code may be necessary for the project, the code block might not really pertain to the method or class it is included in.
*Extract Method
**This can be used when duplicate code occurs, as discussed above. But it can also be used when a method performs multiple functions that have the ability to be split up into various functions that serve a single purpose.
Before Refactoring
<pre>
def foo
puts "hey"
puts "how are you"
puts "bye!"
end
def bar
puts "bye!"
end
</pre>
After Extract Method Refactor
<pre>
def greet
puts "hey"
puts "how are you"
end
def farewell
puts "bye!"
end
def foo
greet
farewell
end
def bar
greet
end
</pre>
*Extract Class/Subclass/Superclass
**If there are class variables or methods that don’t directly pertain to a class, then it may be necessary to create a new class for those pieces.[http://www.refactoring.com/catalog/extractClass.html Example]
**If there are pieces of a class that are only for a specific subset of instances, then a subclass can be constructed to contain these.[http://www.refactoring.com/catalog/extractSubclass.html Example]
**If there are pieces that multiple classes use, then a superclass can be constructed to handle these generic functions, leaving the subclasses to deal with the remaining differences<ref>http://www.refactoring.com/catalog/extractSuperclass.html Example </ref>
Before Refactoring
<pre>
class Person
def initialize(f,m,l,s)
@firstName = f
@middleName = m
@lastName = l
@SSN = s
end
end
</pre>
After Extract Class Refactoring
<pre>

class FullName
def initialize(f,m,l)
@firstName = f
@middleName = m
@lastName = l
end
end

class Person
def initialize(f,m,l,s)
@name = FullName.new(f,m,l)
@SSN = s
end
end
</pre>

===Improving Readability and Clarity===
Many times, refactoring can be used to do simple, yet necessary changes like renaming variables, methods, or classes. As features get added to a project, classes tend to get charged with more uses than originally planned, so sometimes, the original naming scheme no longer applies and a new one needs to be instilled.

Moving methods and parameters around to where they have the best accessibility also has its uses. Classes also tend to be promoted or demoted to super and sub classes after their ultimate functional purpose is determined.

===More Techniques===
There is an extensive list of coding smells that can be improved through refactoring.

A description of smells with their techniques exists [http://ghendry.net/refactor.html here].

A list of techniques with examples in Ruby are listed [http://www.refactoring.com/catalog/index.html here].

==Metrics==
It can be hard to decide whether or not to refactor, especially when it’s for something that appears to be working fine with just a surface level smell. Program analysis tools are used to derive various types of code metrics, which allow coders to identify problem areas and future pitfalls of their code base. These tools look at the code in several different ways, including the number of times a source file has been edited to help determine if it is a possible target of [feature envy], duplicate code structure to identify replicated lines, and block depths to suggest possible complexity issues.

===Open Source Ruby Metric Tools===
There are a variety of open source code metric tools that can be employed specifically for Ruby programs. [https://www.ruby-toolbox.com/categories/code_metrics The Ruby Toolbox] contains the most popular of these tools along with ratings.

[http://rubydoc.info/gems/simplecov/frames Simple Cov] is at the top of this list. It was developed specifically to be of use to anyone using any framework. It integrates itself with the project’s own test cases to check the code coverage of them in addition to cucumber features.

===Code Climate===
[https://codeclimate.com Code Climate] is a hosted code metrics tool that analyzes projects in a multitdue of ways. It produces three main metric ratings with grades from A-F that comprise of the methods and classes contained in each file and project.
#Complexity Metric - This is based off of the Assignment, Branches, and Conditions ([http://c2.com/cgi/wiki?AbcMetric ABC]) metric, where the number of assignments, branches, and conditions are counted and analyzed. However, because Code Climate is constructed for Ruby programs, it also takes into account certain types of Ruby constructs that may increase the metric score, but are actually beneficial to the project.
#Duplication Metric - This looks at the syntax trees of the code in order to identify identical and similar code structures. Because the syntax trees are being analyzed, code formatting and different method and class names do not affect the score. <ref>https://codeclimate.com/docs#quality-metrics</ref>
#Churn Method - This integrates with the Git repository to look at the change history of the project’s files. Files with excessively high change histories have a tendency to have a high complexity rating as well, as they can be the result of feature envy, where extra functions are added into a file instead of being added to a new file with it’s own functionality.

==Getting Started with Refactoring in Ruby==

===First step: Writing tests===
The first step in refactoring is writing solid set of tests for the section of code under consideration, in order to avoid introducing bugs. In Ruby, this can be done using [http://www.ruby-doc.org/stdlib-2.1.0/libdoc/test/unit/rdoc/Test/Unit.html Test::Unit] or [http://rspec.info/ Rspec]. Next step is to make small changes, test, make small changes, test again and so on<ref name='Refactoring Ruby Edition'>http://www.amazon.com/Refactoring-Edition-Addison-Wesley-Professional-Series/dp/0321984137</ref>. This ensures that we can revert back to the working version of code if any small refactoring causes the application to stop working.

===When to refactor===
It is always confusing when to start refactoring. If either one of the following conditions is true, it is a good time to start refactoring code<ref name='Refactoring Ruby Edition'/>:
* The Rule of Three - If any code segment gives trouble more than two times, it is time to refactor it
* Adding new function - It might be helpful to refactor when adding new functionality as it would give better understanding of code. Sometimes, revisiting old design might help to accommodate new features better
* Fixing a bug - It is useful to refactor code which had a bug; this might save bug reports from the same piece of code in future
* During code review - Refactoring is useful during code reviews as it can be applied immediately making code reviews more fruitful
* Understanding other's code - If a new member joins the team and is asked to refactor existing code, it helps them to get a better understanding of the code base. It might take extra time to get them started, but trying to refactor will help them contribute to the project better in the long run.

A [http://blog.codeclimate.com/blog/2014/01/09/when-is-it-time-to-refactor/ CodeClimate blog] suggests some other conditions to decide when to refactor code.

==Automated Code Refactoring==
=== RubyMine ===
*[http://www.jetbrains.com/ruby/webhelp/refactoring.html RubyMine] has a built in refactoring menu.
*To perform refactoring, select a code fragment to refactor. Refactorings available for your selection appear under the Refactor Menu in RubyMine. <ref>http://www.jetbrains.com/ruby/webhelp/refactoring-source-code.html#common</ref> [[File:RubyMine_refactoring_menu.png]]

===RFactor ===
*[http://fabiokung.com/2009/02/04/rfactor-ruby-refactoring-for-your-loved-editor/ RFactor] is a Ruby gem, which aims to provide common and simple refactorings for Ruby code for text editors like TextMate
*The first release has only Extract method implemented while other refactorings are coming soon
*It is available on [http://github.com/fabiokung/rfactor-tmbundle/tree/master GitHub]

=== Other IDEs ===
*Some other IDEs with built-in refactoring include [http://www.aptana.com/products/studio3 Aptana Studio], [http://www.aptana.com/products/radrails Aptana RadRails] and [https://netbeans.org/features/ruby/index.html NetBeans 7] (which requires Ruby and Rails [http://plugins.netbeans.org/plugin/38549 plugin])
*A StackOverflow [http://stackoverflow.com/questions/8705144/ide-with-refactoring-support-for-ruby-on-rails post] compares these tools ranking them as RubyMine being the best, followed by NetBeans, RadRails 2 and Aptana Studio 3

==Further Reading==
*[http://en.wikipedia.org/wiki/Code_smell Ways to identify problems in code]

*[http://blog.codeclimate.com/blog/2012/11/14/why-ruby-class-methods-resist-refactoring/ Resistance With Refactoring Ruby Class Methods]

*[http://www.railsinside.com/uncategorized/460-the-first-step-of-refactoring-a-rails-application.html Refactoring a Rails Application]

*[http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ Refactoring Fat Models]

*[https://speakerdeck.com/brianvh/refactoring-views-in-rails Talk on Refactoring Fat Views]

*[http://www.amazon.com/Rails-AntiPatterns-Refactoring-Addison-Wesley-Professional/dp/0321604814 Rails AntiPatterns: Best Practice Ruby on Rails Refactoring]

==References==
<references/>

CSC/ECE 517 Spring 2014/ch1a 1w1e rm

2014-02-19T04:41:46Z

Rjlloyd: /* Large Method/Class */

This page discusses refactoring techniques and metrics. It also includes tips on refactoring in Ruby and list of tools for automated refactoring.

==Background==

The idea behind [http://en.wikipedia.org/wiki/Code_refactoring code refactoring] is to take a code base and improve it's readability, [http://en.wikipedia.org/wiki/Extensibility extensibility], and [http://en.wikipedia.org/wiki/Reusability reusability]. The practice is focused on having a better quality and more standardized code base, and not on fixing bugs or changing functionality.

Refactoring has its difficulties, whether or not it is done using an [http://en.wikipedia.org/wiki/Integrated_development_environment IDE] or whether it is done by hand. There are lots of pitfalls and errors that can be made during refactoring, so it is pertinent to determine how important a refactor is to the code. Code metrics are one method used to determine how badly a file needs refactoring.

==Refactoring Techniques==
Before a coder performs a refactor, they must, either formally or informally, identify their ‘code smells’. A code smell refers to a negative quality of a code base that either implements bad programming practices or slows down code development or runtime. These aren't typically bugs, but can increase the chance of bugs later on if not fixed. Based on the type of code smell, a different refactoring technique is used to fix it.

===Duplicate Code===
Duplicate code can be a tricky concept when refactoring. Large sections of duplicated code can be easy to find and fixed by pulling it out and creating a single centralized method to call, however it is usually not that easy. Sometimes it may only be one or two lines of code that are duplicated which calls for an assessment of whether or not it is in the best interest to create a new method for a couple lines of code. Other times, code is not duplicate, rather it is similar enough that a generic method could be created to serve various purposes.
Some specific techniques to deal with this are:
*Extract Method / Pull-up Method
**If common code is used in multiple places, simply pull it out and make a method that can be called from all of the necessary places. Variables can be passed in if slight variations are needed between calls.
**If the code is used in various subclasses, put the common code in a method in the superclass, so that it can be seen and called by it’s children.<ref>http://www.refactoring.com/catalog/extractMethod.html Extract Method Example</ref>
Before Refactor
<pre>
class Cat
end

class Lion < Mammal
def likes
puts "Boxes"
end
end
class HouseCat < Mammal
def likes
puts "Boxes"
end
end
</pre>
After Pull Up Refactor
<pre>
class Cat
def likes
puts "Boxes"
end
end

class Lion < Mammal
end
class HouseCat < Mammal
end
</pre>

*Form Template Method
**If two methods in subclasses perform similar steps in the same order, but the steps are different, then get the steps into methods with the same signature, so that the original methods become the same. Then pull them up. <ref>http://www.refactoring.com/catalog/formTemplateMethod.html</ref>
Before Refactor
<pre>
class Cat
end
class Tiger < Cat
def live
puts “Wake up”
puts “Catch deer”
puts “Eat deer”
puts “Sleep in sun”
end
end
class HouseCat < Cat
def live
puts “Wake up”
puts “Wake human up”
puts “Eat food”
puts “Sleep in sun”
end
end
</pre>
After Form Template Refactor
<pre>
class Cat
def live
puts “Wake up”
do_morning_routine
puts “Sleep in the sun”
end
end
class Tiger < Cat
def do_morning_routine
puts “Catch deer”
puts “Eat deer”
end
end
class HouseCat < Cat
def do_morning_routine
puts “Wake human up”
puts “Eat food”
end
end
</pre>

===Large Method/Class===
If a project is not planned out well enough in advance, it is easy for methods and classes to become populated with excess functionality. While functionality of a block of code may be necessary for the project, the code block might not really pertain to the method or class it is included in.
*Extract Method
**This can be used when duplicate code occurs, as discussed above. But it can also be used when a method performs multiple functions that have the ability to be split up into various functions that serve a single purpose.
*Extract Class/Subclass/Superclass
**If there are class variables or methods that don’t directly pertain to a class, then it may be necessary to create a new class for those pieces.[http://www.refactoring.com/catalog/extractClass.html Example]
**If there are pieces of a class that are only for a specific subset of instances, then a subclass can be constructed to contain these.[http://www.refactoring.com/catalog/extractSubclass.html Example]
**If there are pieces that multiple classes use, then a superclass can be constructed to handle these generic functions, leaving the subclasses to deal with the remaining differences<ref>http://www.refactoring.com/catalog/extractSuperclass.html Example </ref>
Before Refactoring
<pre>
class Person
def initialize(f,m,l,s)
@firstName = f
@middleName = m
@lastName = l
@SSN = s
end
end
</pre>
After Extract Class Refactoring
<pre>

class FullName
def initialize(f,m,l)
@firstName = f
@middleName = m
@lastName = l
end
end

class Person
def initialize(f,m,l,s)
@name = FullName.new(f,m,l)
@SSN = s
end
end
</pre>

===Improving Readability and Clarity===
Many times, refactoring can be used to do simple, yet necessary changes like renaming variables, methods, or classes. As features get added to a project, classes tend to get charged with more uses than originally planned, so sometimes, the original naming scheme no longer applies and a new one needs to be instilled.

Moving methods and parameters around to where they have the best accessibility also has its uses. Classes also tend to be promoted or demoted to super and sub classes after their ultimate functional purpose is determined.

===More Techniques===
There is an extensive list of coding smells that can be improved through refactoring.

A description of smells with their techniques exists [http://ghendry.net/refactor.html here].

A list of techniques with examples in Ruby are listed [http://www.refactoring.com/catalog/index.html here].

==Metrics==
It can be hard to decide whether or not to refactor, especially when it’s for something that appears to be working fine with just a surface level smell. Program analysis tools are used to derive various types of code metrics, which allow coders to identify problem areas and future pitfalls of their code base. These tools look at the code in several different ways, including the number of times a source file has been edited to help determine if it is a possible target of [feature envy], duplicate code structure to identify replicated lines, and block depths to suggest possible complexity issues.

===Open Source Ruby Metric Tools===
There are a variety of open source code metric tools that can be employed specifically for Ruby programs. [https://www.ruby-toolbox.com/categories/code_metrics The Ruby Toolbox] contains the most popular of these tools along with ratings.

[http://rubydoc.info/gems/simplecov/frames Simple Cov] is at the top of this list. It was developed specifically to be of use to anyone using any framework. It integrates itself with the project’s own test cases to check the code coverage of them in addition to cucumber features.

===Code Climate===
[https://codeclimate.com Code Climate] is a hosted code metrics tool that analyzes projects in a multitdue of ways. It produces three main metric ratings with grades from A-F that comprise of the methods and classes contained in each file and project.
#Complexity Metric - This is based off of the Assignment, Branches, and Conditions ([http://c2.com/cgi/wiki?AbcMetric ABC]) metric, where the number of assignments, branches, and conditions are counted and analyzed. However, because Code Climate is constructed for Ruby programs, it also takes into account certain types of Ruby constructs that may increase the metric score, but are actually beneficial to the project.
#Duplication Metric - This looks at the syntax trees of the code in order to identify identical and similar code structures. Because the syntax trees are being analyzed, code formatting and different method and class names do not affect the score. <ref>https://codeclimate.com/docs#quality-metrics</ref>
#Churn Method - This integrates with the Git repository to look at the change history of the project’s files. Files with excessively high change histories have a tendency to have a high complexity rating as well, as they can be the result of feature envy, where extra functions are added into a file instead of being added to a new file with it’s own functionality.

==Getting Started with Refactoring in Ruby==

===First step: Writing tests===
The first step in refactoring is writing solid set of tests for the section of code under consideration, in order to avoid introducing bugs. In Ruby, this can be done using [http://www.ruby-doc.org/stdlib-2.1.0/libdoc/test/unit/rdoc/Test/Unit.html Test::Unit] or [http://rspec.info/ Rspec]. Next step is to make small changes, test, make small changes, test again and so on<ref name='Refactoring Ruby Edition'>http://www.amazon.com/Refactoring-Edition-Addison-Wesley-Professional-Series/dp/0321984137</ref>. This ensures that we can revert back to the working version of code if any small refactoring causes the application to stop working.

===When to refactor===
It is always confusing when to start refactoring. If either one of the following conditions is true, it is a good time to start refactoring code<ref name='Refactoring Ruby Edition'/>:
* The Rule of Three - If any code segment gives trouble more than two times, it is time to refactor it
* Adding new function - It might be helpful to refactor when adding new functionality as it would give better understanding of code. Sometimes, revisiting old design might help to accommodate new features better
* Fixing a bug - It is useful to refactor code which had a bug; this might save bug reports from the same piece of code in future
* During code review - Refactoring is useful during code reviews as it can be applied immediately making code reviews more fruitful
* Understanding other's code - If a new member joins the team and is asked to refactor existing code, it helps them to get a better understanding of the code base. It might take extra time to get them started, but trying to refactor will help them contribute to the project better in the long run.

A [http://blog.codeclimate.com/blog/2014/01/09/when-is-it-time-to-refactor/ CodeClimate blog] suggests some other conditions to decide when to refactor code.

==Automated Code Refactoring==
=== RubyMine ===
*[http://www.jetbrains.com/ruby/webhelp/refactoring.html RubyMine] has a built in refactoring menu.
*To perform refactoring, select a code fragment to refactor. Refactorings available for your selection appear under the Refactor Menu in RubyMine. <ref>http://www.jetbrains.com/ruby/webhelp/refactoring-source-code.html#common</ref> [[File:RubyMine_refactoring_menu.png]]

===RFactor ===
*[http://fabiokung.com/2009/02/04/rfactor-ruby-refactoring-for-your-loved-editor/ RFactor] is a Ruby gem, which aims to provide common and simple refactorings for Ruby code for text editors like TextMate
*The first release has only Extract method implemented while other refactorings are coming soon
*It is available on [http://github.com/fabiokung/rfactor-tmbundle/tree/master GitHub]

=== Other IDEs ===
*Some other IDEs with built-in refactoring include [http://www.aptana.com/products/studio3 Aptana Studio], [http://www.aptana.com/products/radrails Aptana RadRails] and [https://netbeans.org/features/ruby/index.html NetBeans 7] (which requires Ruby and Rails [http://plugins.netbeans.org/plugin/38549 plugin])
*A StackOverflow [http://stackoverflow.com/questions/8705144/ide-with-refactoring-support-for-ruby-on-rails post] compares these tools ranking them as RubyMine being the best, followed by NetBeans, RadRails 2 and Aptana Studio 3

==Further Reading==
*[http://en.wikipedia.org/wiki/Code_smell Ways to identify problems in code]

*[http://blog.codeclimate.com/blog/2012/11/14/why-ruby-class-methods-resist-refactoring/ Resistance With Refactoring Ruby Class Methods]

*[http://www.railsinside.com/uncategorized/460-the-first-step-of-refactoring-a-rails-application.html Refactoring a Rails Application]

*[http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ Refactoring Fat Models]

*[https://speakerdeck.com/brianvh/refactoring-views-in-rails Talk on Refactoring Fat Views]

*[http://www.amazon.com/Rails-AntiPatterns-Refactoring-Addison-Wesley-Professional/dp/0321604814 Rails AntiPatterns: Best Practice Ruby on Rails Refactoring]

==References==
<references/>

CSC/ECE 517 Spring 2014/ch1a 1w1e rm

2014-02-19T04:41:19Z

Rjlloyd: /* Large Method/Class */

This page discusses refactoring techniques and metrics. It also includes tips on refactoring in Ruby and list of tools for automated refactoring.

==Background==

The idea behind [http://en.wikipedia.org/wiki/Code_refactoring code refactoring] is to take a code base and improve it's readability, [http://en.wikipedia.org/wiki/Extensibility extensibility], and [http://en.wikipedia.org/wiki/Reusability reusability]. The practice is focused on having a better quality and more standardized code base, and not on fixing bugs or changing functionality.

Refactoring has its difficulties, whether or not it is done using an [http://en.wikipedia.org/wiki/Integrated_development_environment IDE] or whether it is done by hand. There are lots of pitfalls and errors that can be made during refactoring, so it is pertinent to determine how important a refactor is to the code. Code metrics are one method used to determine how badly a file needs refactoring.

==Refactoring Techniques==
Before a coder performs a refactor, they must, either formally or informally, identify their ‘code smells’. A code smell refers to a negative quality of a code base that either implements bad programming practices or slows down code development or runtime. These aren't typically bugs, but can increase the chance of bugs later on if not fixed. Based on the type of code smell, a different refactoring technique is used to fix it.

===Duplicate Code===
Duplicate code can be a tricky concept when refactoring. Large sections of duplicated code can be easy to find and fixed by pulling it out and creating a single centralized method to call, however it is usually not that easy. Sometimes it may only be one or two lines of code that are duplicated which calls for an assessment of whether or not it is in the best interest to create a new method for a couple lines of code. Other times, code is not duplicate, rather it is similar enough that a generic method could be created to serve various purposes.
Some specific techniques to deal with this are:
*Extract Method / Pull-up Method
**If common code is used in multiple places, simply pull it out and make a method that can be called from all of the necessary places. Variables can be passed in if slight variations are needed between calls.
**If the code is used in various subclasses, put the common code in a method in the superclass, so that it can be seen and called by it’s children.<ref>http://www.refactoring.com/catalog/extractMethod.html Extract Method Example</ref>
Before Refactor
<pre>
class Cat
end

class Lion < Mammal
def likes
puts "Boxes"
end
end
class HouseCat < Mammal
def likes
puts "Boxes"
end
end
</pre>
After Pull Up Refactor
<pre>
class Cat
def likes
puts "Boxes"
end
end

class Lion < Mammal
end
class HouseCat < Mammal
end
</pre>

*Form Template Method
**If two methods in subclasses perform similar steps in the same order, but the steps are different, then get the steps into methods with the same signature, so that the original methods become the same. Then pull them up. <ref>http://www.refactoring.com/catalog/formTemplateMethod.html</ref>
Before Refactor
<pre>
class Cat
end
class Tiger < Cat
def live
puts “Wake up”
puts “Catch deer”
puts “Eat deer”
puts “Sleep in sun”
end
end
class HouseCat < Cat
def live
puts “Wake up”
puts “Wake human up”
puts “Eat food”
puts “Sleep in sun”
end
end
</pre>
After Form Template Refactor
<pre>
class Cat
def live
puts “Wake up”
do_morning_routine
puts “Sleep in the sun”
end
end
class Tiger < Cat
def do_morning_routine
puts “Catch deer”
puts “Eat deer”
end
end
class HouseCat < Cat
def do_morning_routine
puts “Wake human up”
puts “Eat food”
end
end
</pre>

===Large Method/Class===
If a project is not planned out well enough in advance, it is easy for methods and classes to become populated with excess functionality. While functionality of a block of code may be necessary for the project, the code block might not really pertain to the method or class it is included in.
*Extract Method
**This can be used when duplicate code occurs, as discussed above. But it can also be used when a method performs multiple functions that have the ability to be split up into various functions that serve a single purpose.
*Extract Class/Subclass/Superclass
**If there are class variables or methods that don’t directly pertain to a class, then it may be necessary to create a new class for those pieces.[http://www.refactoring.com/catalog/extractClass.html Example]
**If there are pieces of a class that are only for a specific subset of instances, then a subclass can be constructed to contain these.[http://www.refactoring.com/catalog/extractSubclass.html Example]
**If there are pieces that multiple classes use, then a superclass can be constructed to handle these generic functions, leaving the subclasses to deal with the remaining differences <ref>http://www.refactoring.com/catalog/extractSuperclass.html Example </ref>
Before Refactoring
<pre>
class Person
def initialize(f,m,l,s)
@firstName = f
@middleName = m
@lastName = l
@SSN = s
end
end
</pre>
After Extract Class Refactoring
<pre>

class FullName
def initialize(f,m,l)
@firstName = f
@middleName = m
@lastName = l
end
end

class Person
def initialize(f,m,l,s)
@name = FullName.new(f,m,l)
@SSN = s
end
end
</pre>

===Improving Readability and Clarity===
Many times, refactoring can be used to do simple, yet necessary changes like renaming variables, methods, or classes. As features get added to a project, classes tend to get charged with more uses than originally planned, so sometimes, the original naming scheme no longer applies and a new one needs to be instilled.

Moving methods and parameters around to where they have the best accessibility also has its uses. Classes also tend to be promoted or demoted to super and sub classes after their ultimate functional purpose is determined.

===More Techniques===
There is an extensive list of coding smells that can be improved through refactoring.

A description of smells with their techniques exists [http://ghendry.net/refactor.html here].

A list of techniques with examples in Ruby are listed [http://www.refactoring.com/catalog/index.html here].

==Metrics==
It can be hard to decide whether or not to refactor, especially when it’s for something that appears to be working fine with just a surface level smell. Program analysis tools are used to derive various types of code metrics, which allow coders to identify problem areas and future pitfalls of their code base. These tools look at the code in several different ways, including the number of times a source file has been edited to help determine if it is a possible target of [feature envy], duplicate code structure to identify replicated lines, and block depths to suggest possible complexity issues.

===Open Source Ruby Metric Tools===
There are a variety of open source code metric tools that can be employed specifically for Ruby programs. [https://www.ruby-toolbox.com/categories/code_metrics The Ruby Toolbox] contains the most popular of these tools along with ratings.

[http://rubydoc.info/gems/simplecov/frames Simple Cov] is at the top of this list. It was developed specifically to be of use to anyone using any framework. It integrates itself with the project’s own test cases to check the code coverage of them in addition to cucumber features.

===Code Climate===
[https://codeclimate.com Code Climate] is a hosted code metrics tool that analyzes projects in a multitdue of ways. It produces three main metric ratings with grades from A-F that comprise of the methods and classes contained in each file and project.
#Complexity Metric - This is based off of the Assignment, Branches, and Conditions ([http://c2.com/cgi/wiki?AbcMetric ABC]) metric, where the number of assignments, branches, and conditions are counted and analyzed. However, because Code Climate is constructed for Ruby programs, it also takes into account certain types of Ruby constructs that may increase the metric score, but are actually beneficial to the project.
#Duplication Metric - This looks at the syntax trees of the code in order to identify identical and similar code structures. Because the syntax trees are being analyzed, code formatting and different method and class names do not affect the score. <ref>https://codeclimate.com/docs#quality-metrics</ref>
#Churn Method - This integrates with the Git repository to look at the change history of the project’s files. Files with excessively high change histories have a tendency to have a high complexity rating as well, as they can be the result of feature envy, where extra functions are added into a file instead of being added to a new file with it’s own functionality.

==Getting Started with Refactoring in Ruby==

===First step: Writing tests===
The first step in refactoring is writing solid set of tests for the section of code under consideration, in order to avoid introducing bugs. In Ruby, this can be done using [http://www.ruby-doc.org/stdlib-2.1.0/libdoc/test/unit/rdoc/Test/Unit.html Test::Unit] or [http://rspec.info/ Rspec]. Next step is to make small changes, test, make small changes, test again and so on<ref name='Refactoring Ruby Edition'>http://www.amazon.com/Refactoring-Edition-Addison-Wesley-Professional-Series/dp/0321984137</ref>. This ensures that we can revert back to the working version of code if any small refactoring causes the application to stop working.

===When to refactor===
It is always confusing when to start refactoring. If either one of the following conditions is true, it is a good time to start refactoring code<ref name='Refactoring Ruby Edition'/>:
* The Rule of Three - If any code segment gives trouble more than two times, it is time to refactor it
* Adding new function - It might be helpful to refactor when adding new functionality as it would give better understanding of code. Sometimes, revisiting old design might help to accommodate new features better
* Fixing a bug - It is useful to refactor code which had a bug; this might save bug reports from the same piece of code in future
* During code review - Refactoring is useful during code reviews as it can be applied immediately making code reviews more fruitful
* Understanding other's code - If a new member joins the team and is asked to refactor existing code, it helps them to get a better understanding of the code base. It might take extra time to get them started, but trying to refactor will help them contribute to the project better in the long run.

A [http://blog.codeclimate.com/blog/2014/01/09/when-is-it-time-to-refactor/ CodeClimate blog] suggests some other conditions to decide when to refactor code.

==Automated Code Refactoring==
=== RubyMine ===
*[http://www.jetbrains.com/ruby/webhelp/refactoring.html RubyMine] has a built in refactoring menu.
*To perform refactoring, select a code fragment to refactor. Refactorings available for your selection appear under the Refactor Menu in RubyMine. <ref>http://www.jetbrains.com/ruby/webhelp/refactoring-source-code.html#common</ref> [[File:RubyMine_refactoring_menu.png]]

===RFactor ===
*[http://fabiokung.com/2009/02/04/rfactor-ruby-refactoring-for-your-loved-editor/ RFactor] is a Ruby gem, which aims to provide common and simple refactorings for Ruby code for text editors like TextMate
*The first release has only Extract method implemented while other refactorings are coming soon
*It is available on [http://github.com/fabiokung/rfactor-tmbundle/tree/master GitHub]

=== Other IDEs ===
*Some other IDEs with built-in refactoring include [http://www.aptana.com/products/studio3 Aptana Studio], [http://www.aptana.com/products/radrails Aptana RadRails] and [https://netbeans.org/features/ruby/index.html NetBeans 7] (which requires Ruby and Rails [http://plugins.netbeans.org/plugin/38549 plugin])
*A StackOverflow [http://stackoverflow.com/questions/8705144/ide-with-refactoring-support-for-ruby-on-rails post] compares these tools ranking them as RubyMine being the best, followed by NetBeans, RadRails 2 and Aptana Studio 3

==Further Reading==
*[http://en.wikipedia.org/wiki/Code_smell Ways to identify problems in code]

*[http://blog.codeclimate.com/blog/2012/11/14/why-ruby-class-methods-resist-refactoring/ Resistance With Refactoring Ruby Class Methods]

*[http://www.railsinside.com/uncategorized/460-the-first-step-of-refactoring-a-rails-application.html Refactoring a Rails Application]

*[http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ Refactoring Fat Models]

*[https://speakerdeck.com/brianvh/refactoring-views-in-rails Talk on Refactoring Fat Views]

*[http://www.amazon.com/Rails-AntiPatterns-Refactoring-Addison-Wesley-Professional/dp/0321604814 Rails AntiPatterns: Best Practice Ruby on Rails Refactoring]

==References==
<references/>

CSC/ECE 517 Spring 2014/ch1a 1w1e rm

2014-02-19T04:40:02Z

Rjlloyd: /* Duplicate Code */

This page discusses refactoring techniques and metrics. It also includes tips on refactoring in Ruby and list of tools for automated refactoring.

==Background==

The idea behind [http://en.wikipedia.org/wiki/Code_refactoring code refactoring] is to take a code base and improve it's readability, [http://en.wikipedia.org/wiki/Extensibility extensibility], and [http://en.wikipedia.org/wiki/Reusability reusability]. The practice is focused on having a better quality and more standardized code base, and not on fixing bugs or changing functionality.

Refactoring has its difficulties, whether or not it is done using an [http://en.wikipedia.org/wiki/Integrated_development_environment IDE] or whether it is done by hand. There are lots of pitfalls and errors that can be made during refactoring, so it is pertinent to determine how important a refactor is to the code. Code metrics are one method used to determine how badly a file needs refactoring.

==Refactoring Techniques==
Before a coder performs a refactor, they must, either formally or informally, identify their ‘code smells’. A code smell refers to a negative quality of a code base that either implements bad programming practices or slows down code development or runtime. These aren't typically bugs, but can increase the chance of bugs later on if not fixed. Based on the type of code smell, a different refactoring technique is used to fix it.

===Duplicate Code===
Duplicate code can be a tricky concept when refactoring. Large sections of duplicated code can be easy to find and fixed by pulling it out and creating a single centralized method to call, however it is usually not that easy. Sometimes it may only be one or two lines of code that are duplicated which calls for an assessment of whether or not it is in the best interest to create a new method for a couple lines of code. Other times, code is not duplicate, rather it is similar enough that a generic method could be created to serve various purposes.
Some specific techniques to deal with this are:
*Extract Method / Pull-up Method
**If common code is used in multiple places, simply pull it out and make a method that can be called from all of the necessary places. Variables can be passed in if slight variations are needed between calls.
**If the code is used in various subclasses, put the common code in a method in the superclass, so that it can be seen and called by it’s children.<ref>http://www.refactoring.com/catalog/extractMethod.html Extract Method Example</ref>
Before Refactor
<pre>
class Cat
end

class Lion < Mammal
def likes
puts "Boxes"
end
end
class HouseCat < Mammal
def likes
puts "Boxes"
end
end
</pre>
After Pull Up Refactor
<pre>
class Cat
def likes
puts "Boxes"
end
end

class Lion < Mammal
end
class HouseCat < Mammal
end
</pre>

*Form Template Method
**If two methods in subclasses perform similar steps in the same order, but the steps are different, then get the steps into methods with the same signature, so that the original methods become the same. Then pull them up. <ref>http://www.refactoring.com/catalog/formTemplateMethod.html</ref>
Before Refactor
<pre>
class Cat
end
class Tiger < Cat
def live
puts “Wake up”
puts “Catch deer”
puts “Eat deer”
puts “Sleep in sun”
end
end
class HouseCat < Cat
def live
puts “Wake up”
puts “Wake human up”
puts “Eat food”
puts “Sleep in sun”
end
end
</pre>
After Form Template Refactor
<pre>
class Cat
def live
puts “Wake up”
do_morning_routine
puts “Sleep in the sun”
end
end
class Tiger < Cat
def do_morning_routine
puts “Catch deer”
puts “Eat deer”
end
end
class HouseCat < Cat
def do_morning_routine
puts “Wake human up”
puts “Eat food”
end
end
</pre>

===Large Method/Class===
If a project is not planned out well enough in advance, it is easy for methods and classes to become populated with excess functionality. While functionality of a block of code may be necessary for the project, the code block might not really pertain to the method or class it is included in.
*Extract Method
**This can be used when duplicate code occurs, as discussed above. But it can also be used when a method performs multiple functions that have the ability to be split up into various functions that serve a single purpose.
*Extract Class/Subclass/Superclass
**If there are class variables or methods that don’t directly pertain to a class, then it may be necessary to create a new class for those pieces.[http://www.refactoring.com/catalog/extractClass.html Example]
**If there are pieces of a class that are only for a specific subset of instances, then a subclass can be constructed to contain these.[http://www.refactoring.com/catalog/extractSubclass.html Example]
**If there are pieces that multiple classes use, then a superclass can be constructed to handle these generic functions, leaving the subclasses to deal with the remaining differences [http://www.refactoring.com/catalog/extractSuperclass.html Example]

===Improving Readability and Clarity===
Many times, refactoring can be used to do simple, yet necessary changes like renaming variables, methods, or classes. As features get added to a project, classes tend to get charged with more uses than originally planned, so sometimes, the original naming scheme no longer applies and a new one needs to be instilled.

Moving methods and parameters around to where they have the best accessibility also has its uses. Classes also tend to be promoted or demoted to super and sub classes after their ultimate functional purpose is determined.

===More Techniques===
There is an extensive list of coding smells that can be improved through refactoring.

A description of smells with their techniques exists [http://ghendry.net/refactor.html here].

A list of techniques with examples in Ruby are listed [http://www.refactoring.com/catalog/index.html here].

==Metrics==
It can be hard to decide whether or not to refactor, especially when it’s for something that appears to be working fine with just a surface level smell. Program analysis tools are used to derive various types of code metrics, which allow coders to identify problem areas and future pitfalls of their code base. These tools look at the code in several different ways, including the number of times a source file has been edited to help determine if it is a possible target of [feature envy], duplicate code structure to identify replicated lines, and block depths to suggest possible complexity issues.

===Open Source Ruby Metric Tools===
There are a variety of open source code metric tools that can be employed specifically for Ruby programs. [https://www.ruby-toolbox.com/categories/code_metrics The Ruby Toolbox] contains the most popular of these tools along with ratings.

[http://rubydoc.info/gems/simplecov/frames Simple Cov] is at the top of this list. It was developed specifically to be of use to anyone using any framework. It integrates itself with the project’s own test cases to check the code coverage of them in addition to cucumber features.

===Code Climate===
[https://codeclimate.com Code Climate] is a hosted code metrics tool that analyzes projects in a multitdue of ways. It produces three main metric ratings with grades from A-F that comprise of the methods and classes contained in each file and project.
#Complexity Metric - This is based off of the Assignment, Branches, and Conditions ([http://c2.com/cgi/wiki?AbcMetric ABC]) metric, where the number of assignments, branches, and conditions are counted and analyzed. However, because Code Climate is constructed for Ruby programs, it also takes into account certain types of Ruby constructs that may increase the metric score, but are actually beneficial to the project.
#Duplication Metric - This looks at the syntax trees of the code in order to identify identical and similar code structures. Because the syntax trees are being analyzed, code formatting and different method and class names do not affect the score. <ref>https://codeclimate.com/docs#quality-metrics</ref>
#Churn Method - This integrates with the Git repository to look at the change history of the project’s files. Files with excessively high change histories have a tendency to have a high complexity rating as well, as they can be the result of feature envy, where extra functions are added into a file instead of being added to a new file with it’s own functionality.

==Getting Started with Refactoring in Ruby==

===First step: Writing tests===
The first step in refactoring is writing solid set of tests for the section of code under consideration, in order to avoid introducing bugs. In Ruby, this can be done using [http://www.ruby-doc.org/stdlib-2.1.0/libdoc/test/unit/rdoc/Test/Unit.html Test::Unit] or [http://rspec.info/ Rspec]. Next step is to make small changes, test, make small changes, test again and so on<ref name='Refactoring Ruby Edition'>http://www.amazon.com/Refactoring-Edition-Addison-Wesley-Professional-Series/dp/0321984137</ref>. This ensures that we can revert back to the working version of code if any small refactoring causes the application to stop working.

===When to refactor===
It is always confusing when to start refactoring. If either one of the following conditions is true, it is a good time to start refactoring code<ref name='Refactoring Ruby Edition'/>:
* The Rule of Three - If any code segment gives trouble more than two times, it is time to refactor it
* Adding new function - It might be helpful to refactor when adding new functionality as it would give better understanding of code. Sometimes, revisiting old design might help to accommodate new features better
* Fixing a bug - It is useful to refactor code which had a bug; this might save bug reports from the same piece of code in future
* During code review - Refactoring is useful during code reviews as it can be applied immediately making code reviews more fruitful
* Understanding other's code - If a new member joins the team and is asked to refactor existing code, it helps them to get a better understanding of the code base. It might take extra time to get them started, but trying to refactor will help them contribute to the project better in the long run.

A [http://blog.codeclimate.com/blog/2014/01/09/when-is-it-time-to-refactor/ CodeClimate blog] suggests some other conditions to decide when to refactor code.

==Automated Code Refactoring==
=== RubyMine ===
*[http://www.jetbrains.com/ruby/webhelp/refactoring.html RubyMine] has a built in refactoring menu.
*To perform refactoring, select a code fragment to refactor. Refactorings available for your selection appear under the Refactor Menu in RubyMine. <ref>http://www.jetbrains.com/ruby/webhelp/refactoring-source-code.html#common</ref> [[File:RubyMine_refactoring_menu.png]]

===RFactor ===
*[http://fabiokung.com/2009/02/04/rfactor-ruby-refactoring-for-your-loved-editor/ RFactor] is a Ruby gem, which aims to provide common and simple refactorings for Ruby code for text editors like TextMate
*The first release has only Extract method implemented while other refactorings are coming soon
*It is available on [http://github.com/fabiokung/rfactor-tmbundle/tree/master GitHub]

=== Other IDEs ===
*Some other IDEs with built-in refactoring include [http://www.aptana.com/products/studio3 Aptana Studio], [http://www.aptana.com/products/radrails Aptana RadRails] and [https://netbeans.org/features/ruby/index.html NetBeans 7] (which requires Ruby and Rails [http://plugins.netbeans.org/plugin/38549 plugin])
*A StackOverflow [http://stackoverflow.com/questions/8705144/ide-with-refactoring-support-for-ruby-on-rails post] compares these tools ranking them as RubyMine being the best, followed by NetBeans, RadRails 2 and Aptana Studio 3

==Further Reading==
*[http://en.wikipedia.org/wiki/Code_smell Ways to identify problems in code]

*[http://blog.codeclimate.com/blog/2012/11/14/why-ruby-class-methods-resist-refactoring/ Resistance With Refactoring Ruby Class Methods]

*[http://www.railsinside.com/uncategorized/460-the-first-step-of-refactoring-a-rails-application.html Refactoring a Rails Application]

*[http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ Refactoring Fat Models]

*[https://speakerdeck.com/brianvh/refactoring-views-in-rails Talk on Refactoring Fat Views]

*[http://www.amazon.com/Rails-AntiPatterns-Refactoring-Addison-Wesley-Professional/dp/0321604814 Rails AntiPatterns: Best Practice Ruby on Rails Refactoring]

==References==
<references/>

CSC/ECE 517 Spring 2014/ch1a 1w1e rm

2014-02-19T04:39:41Z

Rjlloyd: /* Duplicate Code */

This page discusses refactoring techniques and metrics. It also includes tips on refactoring in Ruby and list of tools for automated refactoring.

==Background==

The idea behind [http://en.wikipedia.org/wiki/Code_refactoring code refactoring] is to take a code base and improve it's readability, [http://en.wikipedia.org/wiki/Extensibility extensibility], and [http://en.wikipedia.org/wiki/Reusability reusability]. The practice is focused on having a better quality and more standardized code base, and not on fixing bugs or changing functionality.

Refactoring has its difficulties, whether or not it is done using an [http://en.wikipedia.org/wiki/Integrated_development_environment IDE] or whether it is done by hand. There are lots of pitfalls and errors that can be made during refactoring, so it is pertinent to determine how important a refactor is to the code. Code metrics are one method used to determine how badly a file needs refactoring.

==Refactoring Techniques==
Before a coder performs a refactor, they must, either formally or informally, identify their ‘code smells’. A code smell refers to a negative quality of a code base that either implements bad programming practices or slows down code development or runtime. These aren't typically bugs, but can increase the chance of bugs later on if not fixed. Based on the type of code smell, a different refactoring technique is used to fix it.

===Duplicate Code===
Duplicate code can be a tricky concept when refactoring. Large sections of duplicated code can be easy to find and fixed by pulling it out and creating a single centralized method to call, however it is usually not that easy. Sometimes it may only be one or two lines of code that are duplicated which calls for an assessment of whether or not it is in the best interest to create a new method for a couple lines of code. Other times, code is not duplicate, rather it is similar enough that a generic method could be created to serve various purposes.
Some specific techniques to deal with this are:
*Extract Method / Pull-up Method
**If common code is used in multiple places, simply pull it out and make a method that can be called from all of the necessary places. Variables can be passed in if slight variations are needed between calls.
**If the code is used in various subclasses, put the common code in a method in the superclass, so that it can be seen and called by it’s children.<ref>http://www.refactoring.com/catalog/extractMethod.html Extract Method Example</ref>
**Before Refactor
<pre>
class Cat
end

class Lion < Mammal
def likes
puts "Boxes"
end
end
class HouseCat < Mammal
def likes
puts "Boxes"
end
end
</pre>
After Pull Up Refactor
<pre>
class Cat
def likes
puts "Boxes"
end
end

class Lion < Mammal
end
class HouseCat < Mammal
end
</pre>

*Form Template Method
**If two methods in subclasses perform similar steps in the same order, but the steps are different, then get the steps into methods with the same signature, so that the original methods become the same. Then pull them up. <ref>http://www.refactoring.com/catalog/formTemplateMethod.html</ref>
**Before Refactor
<pre>
class Cat
end
class Tiger < Cat
def live
puts “Wake up”
puts “Catch deer”
puts “Eat deer”
puts “Sleep in sun”
end
end
class HouseCat < Cat
def live
puts “Wake up”
puts “Wake human up”
puts “Eat food”
puts “Sleep in sun”
end
end
</pre>
After Form Template Refactor
<pre>
class Cat
def live
puts “Wake up”
do_morning_routine
puts “Sleep in the sun”
end
end
class Tiger < Cat
def do_morning_routine
puts “Catch deer”
puts “Eat deer”
end
end
class HouseCat < Cat
def do_morning_routine
puts “Wake human up”
puts “Eat food”
end
end
</pre>

===Large Method/Class===
If a project is not planned out well enough in advance, it is easy for methods and classes to become populated with excess functionality. While functionality of a block of code may be necessary for the project, the code block might not really pertain to the method or class it is included in.
*Extract Method
**This can be used when duplicate code occurs, as discussed above. But it can also be used when a method performs multiple functions that have the ability to be split up into various functions that serve a single purpose.
*Extract Class/Subclass/Superclass
**If there are class variables or methods that don’t directly pertain to a class, then it may be necessary to create a new class for those pieces.[http://www.refactoring.com/catalog/extractClass.html Example]
**If there are pieces of a class that are only for a specific subset of instances, then a subclass can be constructed to contain these.[http://www.refactoring.com/catalog/extractSubclass.html Example]
**If there are pieces that multiple classes use, then a superclass can be constructed to handle these generic functions, leaving the subclasses to deal with the remaining differences [http://www.refactoring.com/catalog/extractSuperclass.html Example]

===Improving Readability and Clarity===
Many times, refactoring can be used to do simple, yet necessary changes like renaming variables, methods, or classes. As features get added to a project, classes tend to get charged with more uses than originally planned, so sometimes, the original naming scheme no longer applies and a new one needs to be instilled.

Moving methods and parameters around to where they have the best accessibility also has its uses. Classes also tend to be promoted or demoted to super and sub classes after their ultimate functional purpose is determined.

===More Techniques===
There is an extensive list of coding smells that can be improved through refactoring.

A description of smells with their techniques exists [http://ghendry.net/refactor.html here].

A list of techniques with examples in Ruby are listed [http://www.refactoring.com/catalog/index.html here].

==Metrics==
It can be hard to decide whether or not to refactor, especially when it’s for something that appears to be working fine with just a surface level smell. Program analysis tools are used to derive various types of code metrics, which allow coders to identify problem areas and future pitfalls of their code base. These tools look at the code in several different ways, including the number of times a source file has been edited to help determine if it is a possible target of [feature envy], duplicate code structure to identify replicated lines, and block depths to suggest possible complexity issues.

===Open Source Ruby Metric Tools===
There are a variety of open source code metric tools that can be employed specifically for Ruby programs. [https://www.ruby-toolbox.com/categories/code_metrics The Ruby Toolbox] contains the most popular of these tools along with ratings.

[http://rubydoc.info/gems/simplecov/frames Simple Cov] is at the top of this list. It was developed specifically to be of use to anyone using any framework. It integrates itself with the project’s own test cases to check the code coverage of them in addition to cucumber features.

===Code Climate===
[https://codeclimate.com Code Climate] is a hosted code metrics tool that analyzes projects in a multitdue of ways. It produces three main metric ratings with grades from A-F that comprise of the methods and classes contained in each file and project.
#Complexity Metric - This is based off of the Assignment, Branches, and Conditions ([http://c2.com/cgi/wiki?AbcMetric ABC]) metric, where the number of assignments, branches, and conditions are counted and analyzed. However, because Code Climate is constructed for Ruby programs, it also takes into account certain types of Ruby constructs that may increase the metric score, but are actually beneficial to the project.
#Duplication Metric - This looks at the syntax trees of the code in order to identify identical and similar code structures. Because the syntax trees are being analyzed, code formatting and different method and class names do not affect the score. <ref>https://codeclimate.com/docs#quality-metrics</ref>
#Churn Method - This integrates with the Git repository to look at the change history of the project’s files. Files with excessively high change histories have a tendency to have a high complexity rating as well, as they can be the result of feature envy, where extra functions are added into a file instead of being added to a new file with it’s own functionality.

==Getting Started with Refactoring in Ruby==

===First step: Writing tests===
The first step in refactoring is writing solid set of tests for the section of code under consideration, in order to avoid introducing bugs. In Ruby, this can be done using [http://www.ruby-doc.org/stdlib-2.1.0/libdoc/test/unit/rdoc/Test/Unit.html Test::Unit] or [http://rspec.info/ Rspec]. Next step is to make small changes, test, make small changes, test again and so on<ref name='Refactoring Ruby Edition'>http://www.amazon.com/Refactoring-Edition-Addison-Wesley-Professional-Series/dp/0321984137</ref>. This ensures that we can revert back to the working version of code if any small refactoring causes the application to stop working.

===When to refactor===
It is always confusing when to start refactoring. If either one of the following conditions is true, it is a good time to start refactoring code<ref name='Refactoring Ruby Edition'/>:
* The Rule of Three - If any code segment gives trouble more than two times, it is time to refactor it
* Adding new function - It might be helpful to refactor when adding new functionality as it would give better understanding of code. Sometimes, revisiting old design might help to accommodate new features better
* Fixing a bug - It is useful to refactor code which had a bug; this might save bug reports from the same piece of code in future
* During code review - Refactoring is useful during code reviews as it can be applied immediately making code reviews more fruitful
* Understanding other's code - If a new member joins the team and is asked to refactor existing code, it helps them to get a better understanding of the code base. It might take extra time to get them started, but trying to refactor will help them contribute to the project better in the long run.

A [http://blog.codeclimate.com/blog/2014/01/09/when-is-it-time-to-refactor/ CodeClimate blog] suggests some other conditions to decide when to refactor code.

==Automated Code Refactoring==
=== RubyMine ===
*[http://www.jetbrains.com/ruby/webhelp/refactoring.html RubyMine] has a built in refactoring menu.
*To perform refactoring, select a code fragment to refactor. Refactorings available for your selection appear under the Refactor Menu in RubyMine. <ref>http://www.jetbrains.com/ruby/webhelp/refactoring-source-code.html#common</ref> [[File:RubyMine_refactoring_menu.png]]

===RFactor ===
*[http://fabiokung.com/2009/02/04/rfactor-ruby-refactoring-for-your-loved-editor/ RFactor] is a Ruby gem, which aims to provide common and simple refactorings for Ruby code for text editors like TextMate
*The first release has only Extract method implemented while other refactorings are coming soon
*It is available on [http://github.com/fabiokung/rfactor-tmbundle/tree/master GitHub]

=== Other IDEs ===
*Some other IDEs with built-in refactoring include [http://www.aptana.com/products/studio3 Aptana Studio], [http://www.aptana.com/products/radrails Aptana RadRails] and [https://netbeans.org/features/ruby/index.html NetBeans 7] (which requires Ruby and Rails [http://plugins.netbeans.org/plugin/38549 plugin])
*A StackOverflow [http://stackoverflow.com/questions/8705144/ide-with-refactoring-support-for-ruby-on-rails post] compares these tools ranking them as RubyMine being the best, followed by NetBeans, RadRails 2 and Aptana Studio 3

==Further Reading==
*[http://en.wikipedia.org/wiki/Code_smell Ways to identify problems in code]

*[http://blog.codeclimate.com/blog/2012/11/14/why-ruby-class-methods-resist-refactoring/ Resistance With Refactoring Ruby Class Methods]

*[http://www.railsinside.com/uncategorized/460-the-first-step-of-refactoring-a-rails-application.html Refactoring a Rails Application]

*[http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ Refactoring Fat Models]

*[https://speakerdeck.com/brianvh/refactoring-views-in-rails Talk on Refactoring Fat Views]

*[http://www.amazon.com/Rails-AntiPatterns-Refactoring-Addison-Wesley-Professional/dp/0321604814 Rails AntiPatterns: Best Practice Ruby on Rails Refactoring]

==References==
<references/>

CSC/ECE 517 Spring 2014/ch1a 1w1e rm

2014-02-19T04:39:10Z

Rjlloyd: /* Duplicate Code */

This page discusses refactoring techniques and metrics. It also includes tips on refactoring in Ruby and list of tools for automated refactoring.

==Background==

The idea behind [http://en.wikipedia.org/wiki/Code_refactoring code refactoring] is to take a code base and improve it's readability, [http://en.wikipedia.org/wiki/Extensibility extensibility], and [http://en.wikipedia.org/wiki/Reusability reusability]. The practice is focused on having a better quality and more standardized code base, and not on fixing bugs or changing functionality.

Refactoring has its difficulties, whether or not it is done using an [http://en.wikipedia.org/wiki/Integrated_development_environment IDE] or whether it is done by hand. There are lots of pitfalls and errors that can be made during refactoring, so it is pertinent to determine how important a refactor is to the code. Code metrics are one method used to determine how badly a file needs refactoring.

==Refactoring Techniques==
Before a coder performs a refactor, they must, either formally or informally, identify their ‘code smells’. A code smell refers to a negative quality of a code base that either implements bad programming practices or slows down code development or runtime. These aren't typically bugs, but can increase the chance of bugs later on if not fixed. Based on the type of code smell, a different refactoring technique is used to fix it.

===Duplicate Code===
Duplicate code can be a tricky concept when refactoring. Large sections of duplicated code can be easy to find and fixed by pulling it out and creating a single centralized method to call, however it is usually not that easy. Sometimes it may only be one or two lines of code that are duplicated which calls for an assessment of whether or not it is in the best interest to create a new method for a couple lines of code. Other times, code is not duplicate, rather it is similar enough that a generic method could be created to serve various purposes.
Some specific techniques to deal with this are:
*Extract Method / Pull-up Method
**If common code is used in multiple places, simply pull it out and make a method that can be called from all of the necessary places. Variables can be passed in if slight variations are needed between calls.
**If the code is used in various subclasses, put the common code in a method in the superclass, so that it can be seen and called by it’s children.<ref>http://www.refactoring.com/catalog/extractMethod.html Extract Method Example</ref>
**Before Refactor
<pre>
class Cat
end

class Lion < Mammal
def likes
puts "Boxes"
end
end
class HouseCat < Mammal
def likes
puts "Boxes"
end
end
</pre>
**After Pull Up Refactor
<pre>
class Cat
def likes
puts "Boxes"
end
end

class Lion < Mammal
end
class HouseCat < Mammal
end
</pre>

*Form Template Method
**If two methods in subclasses perform similar steps in the same order, but the steps are different, then get the steps into methods with the same signature, so that the original methods become the same. Then pull them up. <ref>http://www.refactoring.com/catalog/formTemplateMethod.html</ref>
**Before Refactor
<pre>
class Cat
end
class Tiger < Cat
def live
puts “Wake up”
puts “Catch deer”
puts “Eat deer”
puts “Sleep in sun”
end
end
class HouseCat < Cat
def live
puts “Wake up”
puts “Wake human up”
puts “Eat food”
puts “Sleep in sun”
end
end
</pre>
**After Form Template Refactor
<pre>
class Cat
def live
puts “Wake up”
do_morning_routine
puts “Sleep in the sun”
end
end
class Tiger < Cat
def do_morning_routine
puts “Catch deer”
puts “Eat deer”
end
end
class HouseCat < Cat
def do_morning_routine
puts “Wake human up”
puts “Eat food”
end
end
</pre>

===Large Method/Class===
If a project is not planned out well enough in advance, it is easy for methods and classes to become populated with excess functionality. While functionality of a block of code may be necessary for the project, the code block might not really pertain to the method or class it is included in.
*Extract Method
**This can be used when duplicate code occurs, as discussed above. But it can also be used when a method performs multiple functions that have the ability to be split up into various functions that serve a single purpose.
*Extract Class/Subclass/Superclass
**If there are class variables or methods that don’t directly pertain to a class, then it may be necessary to create a new class for those pieces.[http://www.refactoring.com/catalog/extractClass.html Example]
**If there are pieces of a class that are only for a specific subset of instances, then a subclass can be constructed to contain these.[http://www.refactoring.com/catalog/extractSubclass.html Example]
**If there are pieces that multiple classes use, then a superclass can be constructed to handle these generic functions, leaving the subclasses to deal with the remaining differences [http://www.refactoring.com/catalog/extractSuperclass.html Example]

===Improving Readability and Clarity===
Many times, refactoring can be used to do simple, yet necessary changes like renaming variables, methods, or classes. As features get added to a project, classes tend to get charged with more uses than originally planned, so sometimes, the original naming scheme no longer applies and a new one needs to be instilled.

Moving methods and parameters around to where they have the best accessibility also has its uses. Classes also tend to be promoted or demoted to super and sub classes after their ultimate functional purpose is determined.

===More Techniques===
There is an extensive list of coding smells that can be improved through refactoring.

A description of smells with their techniques exists [http://ghendry.net/refactor.html here].

A list of techniques with examples in Ruby are listed [http://www.refactoring.com/catalog/index.html here].

==Metrics==
It can be hard to decide whether or not to refactor, especially when it’s for something that appears to be working fine with just a surface level smell. Program analysis tools are used to derive various types of code metrics, which allow coders to identify problem areas and future pitfalls of their code base. These tools look at the code in several different ways, including the number of times a source file has been edited to help determine if it is a possible target of [feature envy], duplicate code structure to identify replicated lines, and block depths to suggest possible complexity issues.

===Open Source Ruby Metric Tools===
There are a variety of open source code metric tools that can be employed specifically for Ruby programs. [https://www.ruby-toolbox.com/categories/code_metrics The Ruby Toolbox] contains the most popular of these tools along with ratings.

[http://rubydoc.info/gems/simplecov/frames Simple Cov] is at the top of this list. It was developed specifically to be of use to anyone using any framework. It integrates itself with the project’s own test cases to check the code coverage of them in addition to cucumber features.

===Code Climate===
[https://codeclimate.com Code Climate] is a hosted code metrics tool that analyzes projects in a multitdue of ways. It produces three main metric ratings with grades from A-F that comprise of the methods and classes contained in each file and project.
#Complexity Metric - This is based off of the Assignment, Branches, and Conditions ([http://c2.com/cgi/wiki?AbcMetric ABC]) metric, where the number of assignments, branches, and conditions are counted and analyzed. However, because Code Climate is constructed for Ruby programs, it also takes into account certain types of Ruby constructs that may increase the metric score, but are actually beneficial to the project.
#Duplication Metric - This looks at the syntax trees of the code in order to identify identical and similar code structures. Because the syntax trees are being analyzed, code formatting and different method and class names do not affect the score. <ref>https://codeclimate.com/docs#quality-metrics</ref>
#Churn Method - This integrates with the Git repository to look at the change history of the project’s files. Files with excessively high change histories have a tendency to have a high complexity rating as well, as they can be the result of feature envy, where extra functions are added into a file instead of being added to a new file with it’s own functionality.

==Getting Started with Refactoring in Ruby==

===First step: Writing tests===
The first step in refactoring is writing solid set of tests for the section of code under consideration, in order to avoid introducing bugs. In Ruby, this can be done using [http://www.ruby-doc.org/stdlib-2.1.0/libdoc/test/unit/rdoc/Test/Unit.html Test::Unit] or [http://rspec.info/ Rspec]. Next step is to make small changes, test, make small changes, test again and so on<ref name='Refactoring Ruby Edition'>http://www.amazon.com/Refactoring-Edition-Addison-Wesley-Professional-Series/dp/0321984137</ref>. This ensures that we can revert back to the working version of code if any small refactoring causes the application to stop working.

===When to refactor===
It is always confusing when to start refactoring. If either one of the following conditions is true, it is a good time to start refactoring code<ref name='Refactoring Ruby Edition'/>:
* The Rule of Three - If any code segment gives trouble more than two times, it is time to refactor it
* Adding new function - It might be helpful to refactor when adding new functionality as it would give better understanding of code. Sometimes, revisiting old design might help to accommodate new features better
* Fixing a bug - It is useful to refactor code which had a bug; this might save bug reports from the same piece of code in future
* During code review - Refactoring is useful during code reviews as it can be applied immediately making code reviews more fruitful
* Understanding other's code - If a new member joins the team and is asked to refactor existing code, it helps them to get a better understanding of the code base. It might take extra time to get them started, but trying to refactor will help them contribute to the project better in the long run.

A [http://blog.codeclimate.com/blog/2014/01/09/when-is-it-time-to-refactor/ CodeClimate blog] suggests some other conditions to decide when to refactor code.

==Automated Code Refactoring==
=== RubyMine ===
*[http://www.jetbrains.com/ruby/webhelp/refactoring.html RubyMine] has a built in refactoring menu.
*To perform refactoring, select a code fragment to refactor. Refactorings available for your selection appear under the Refactor Menu in RubyMine. <ref>http://www.jetbrains.com/ruby/webhelp/refactoring-source-code.html#common</ref> [[File:RubyMine_refactoring_menu.png]]

===RFactor ===
*[http://fabiokung.com/2009/02/04/rfactor-ruby-refactoring-for-your-loved-editor/ RFactor] is a Ruby gem, which aims to provide common and simple refactorings for Ruby code for text editors like TextMate
*The first release has only Extract method implemented while other refactorings are coming soon
*It is available on [http://github.com/fabiokung/rfactor-tmbundle/tree/master GitHub]

=== Other IDEs ===
*Some other IDEs with built-in refactoring include [http://www.aptana.com/products/studio3 Aptana Studio], [http://www.aptana.com/products/radrails Aptana RadRails] and [https://netbeans.org/features/ruby/index.html NetBeans 7] (which requires Ruby and Rails [http://plugins.netbeans.org/plugin/38549 plugin])
*A StackOverflow [http://stackoverflow.com/questions/8705144/ide-with-refactoring-support-for-ruby-on-rails post] compares these tools ranking them as RubyMine being the best, followed by NetBeans, RadRails 2 and Aptana Studio 3

==Further Reading==
*[http://en.wikipedia.org/wiki/Code_smell Ways to identify problems in code]

*[http://blog.codeclimate.com/blog/2012/11/14/why-ruby-class-methods-resist-refactoring/ Resistance With Refactoring Ruby Class Methods]

*[http://www.railsinside.com/uncategorized/460-the-first-step-of-refactoring-a-rails-application.html Refactoring a Rails Application]

*[http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ Refactoring Fat Models]

*[https://speakerdeck.com/brianvh/refactoring-views-in-rails Talk on Refactoring Fat Views]

*[http://www.amazon.com/Rails-AntiPatterns-Refactoring-Addison-Wesley-Professional/dp/0321604814 Rails AntiPatterns: Best Practice Ruby on Rails Refactoring]

==References==
<references/>

CSC/ECE 517 Spring 2014/ch1a 1w1e rm

2014-02-19T04:38:17Z

Rjlloyd: /* Duplicate Code */

This page discusses refactoring techniques and metrics. It also includes tips on refactoring in Ruby and list of tools for automated refactoring.

==Background==

The idea behind [http://en.wikipedia.org/wiki/Code_refactoring code refactoring] is to take a code base and improve it's readability, [http://en.wikipedia.org/wiki/Extensibility extensibility], and [http://en.wikipedia.org/wiki/Reusability reusability]. The practice is focused on having a better quality and more standardized code base, and not on fixing bugs or changing functionality.

Refactoring has its difficulties, whether or not it is done using an [http://en.wikipedia.org/wiki/Integrated_development_environment IDE] or whether it is done by hand. There are lots of pitfalls and errors that can be made during refactoring, so it is pertinent to determine how important a refactor is to the code. Code metrics are one method used to determine how badly a file needs refactoring.

==Refactoring Techniques==
Before a coder performs a refactor, they must, either formally or informally, identify their ‘code smells’. A code smell refers to a negative quality of a code base that either implements bad programming practices or slows down code development or runtime. These aren't typically bugs, but can increase the chance of bugs later on if not fixed. Based on the type of code smell, a different refactoring technique is used to fix it.

===Duplicate Code===
Duplicate code can be a tricky concept when refactoring. Large sections of duplicated code can be easy to find and fixed by pulling it out and creating a single centralized method to call, however it is usually not that easy. Sometimes it may only be one or two lines of code that are duplicated which calls for an assessment of whether or not it is in the best interest to create a new method for a couple lines of code. Other times, code is not duplicate, rather it is similar enough that a generic method could be created to serve various purposes.
Some specific techniques to deal with this are:
*Extract Method / Pull-up Method
**If common code is used in multiple places, simply pull it out and make a method that can be called from all of the necessary places. Variables can be passed in if slight variations are needed between calls.
**If the code is used in various subclasses, put the common code in a method in the superclass, so that it can be seen and called by it’s children.<ref>http://www.refactoring.com/catalog/extractMethod.html Extract Method Example</ref>
Before Refactor
<pre>
class Cat
end

class Lion < Mammal
def likes
puts "Boxes"
end
end
class HouseCat < Mammal
def likes
puts "Boxes"
end
end
</pre>
After Pull Up Refactor
<pre>
class Cat
def likes
puts "Boxes"
end
end

class Lion < Mammal
end
class HouseCat < Mammal
end
</pre>

*Form Template Method
**If two methods in subclasses perform similar steps in the same order, but the steps are different, then get the steps into methods with the same signature, so that the original methods become the same. Then pull them up. <ref>http://www.refactoring.com/catalog/formTemplateMethod.html</ref>
Before Refactor
<pre>
class Cat
end
class Tiger < Cat
def live
puts “Wake up”
puts “Catch deer”
puts “Eat deer”
puts “Sleep in sun”
end
end
class HouseCat < Cat
def live
puts “Wake up”
puts “Wake human up”
puts “Eat food”
puts “Sleep in sun”
end
end
</pre>
After Form Template Refactor
<pre>
class Cat
def live
puts “Wake up”
do_morning_routine
puts “Sleep in the sun”
end
end
class Tiger < Cat
def do_morning_routine
puts “Catch deer”
puts “Eat deer”
end
end
class HouseCat < Cat
def do_morning_routine
puts “Wake human up”
puts “Eat food”
end
end
</pre>

===Large Method/Class===
If a project is not planned out well enough in advance, it is easy for methods and classes to become populated with excess functionality. While functionality of a block of code may be necessary for the project, the code block might not really pertain to the method or class it is included in.
*Extract Method
**This can be used when duplicate code occurs, as discussed above. But it can also be used when a method performs multiple functions that have the ability to be split up into various functions that serve a single purpose.
*Extract Class/Subclass/Superclass
**If there are class variables or methods that don’t directly pertain to a class, then it may be necessary to create a new class for those pieces.[http://www.refactoring.com/catalog/extractClass.html Example]
**If there are pieces of a class that are only for a specific subset of instances, then a subclass can be constructed to contain these.[http://www.refactoring.com/catalog/extractSubclass.html Example]
**If there are pieces that multiple classes use, then a superclass can be constructed to handle these generic functions, leaving the subclasses to deal with the remaining differences [http://www.refactoring.com/catalog/extractSuperclass.html Example]

===Improving Readability and Clarity===
Many times, refactoring can be used to do simple, yet necessary changes like renaming variables, methods, or classes. As features get added to a project, classes tend to get charged with more uses than originally planned, so sometimes, the original naming scheme no longer applies and a new one needs to be instilled.

Moving methods and parameters around to where they have the best accessibility also has its uses. Classes also tend to be promoted or demoted to super and sub classes after their ultimate functional purpose is determined.

===More Techniques===
There is an extensive list of coding smells that can be improved through refactoring.

A description of smells with their techniques exists [http://ghendry.net/refactor.html here].

A list of techniques with examples in Ruby are listed [http://www.refactoring.com/catalog/index.html here].

==Metrics==
It can be hard to decide whether or not to refactor, especially when it’s for something that appears to be working fine with just a surface level smell. Program analysis tools are used to derive various types of code metrics, which allow coders to identify problem areas and future pitfalls of their code base. These tools look at the code in several different ways, including the number of times a source file has been edited to help determine if it is a possible target of [feature envy], duplicate code structure to identify replicated lines, and block depths to suggest possible complexity issues.

===Open Source Ruby Metric Tools===
There are a variety of open source code metric tools that can be employed specifically for Ruby programs. [https://www.ruby-toolbox.com/categories/code_metrics The Ruby Toolbox] contains the most popular of these tools along with ratings.

[http://rubydoc.info/gems/simplecov/frames Simple Cov] is at the top of this list. It was developed specifically to be of use to anyone using any framework. It integrates itself with the project’s own test cases to check the code coverage of them in addition to cucumber features.

===Code Climate===
[https://codeclimate.com Code Climate] is a hosted code metrics tool that analyzes projects in a multitdue of ways. It produces three main metric ratings with grades from A-F that comprise of the methods and classes contained in each file and project.
#Complexity Metric - This is based off of the Assignment, Branches, and Conditions ([http://c2.com/cgi/wiki?AbcMetric ABC]) metric, where the number of assignments, branches, and conditions are counted and analyzed. However, because Code Climate is constructed for Ruby programs, it also takes into account certain types of Ruby constructs that may increase the metric score, but are actually beneficial to the project.
#Duplication Metric - This looks at the syntax trees of the code in order to identify identical and similar code structures. Because the syntax trees are being analyzed, code formatting and different method and class names do not affect the score. <ref>https://codeclimate.com/docs#quality-metrics</ref>
#Churn Method - This integrates with the Git repository to look at the change history of the project’s files. Files with excessively high change histories have a tendency to have a high complexity rating as well, as they can be the result of feature envy, where extra functions are added into a file instead of being added to a new file with it’s own functionality.

==Getting Started with Refactoring in Ruby==

===First step: Writing tests===
The first step in refactoring is writing solid set of tests for the section of code under consideration, in order to avoid introducing bugs. In Ruby, this can be done using [http://www.ruby-doc.org/stdlib-2.1.0/libdoc/test/unit/rdoc/Test/Unit.html Test::Unit] or [http://rspec.info/ Rspec]. Next step is to make small changes, test, make small changes, test again and so on<ref name='Refactoring Ruby Edition'>http://www.amazon.com/Refactoring-Edition-Addison-Wesley-Professional-Series/dp/0321984137</ref>. This ensures that we can revert back to the working version of code if any small refactoring causes the application to stop working.

===When to refactor===
It is always confusing when to start refactoring. If either one of the following conditions is true, it is a good time to start refactoring code<ref name='Refactoring Ruby Edition'/>:
* The Rule of Three - If any code segment gives trouble more than two times, it is time to refactor it
* Adding new function - It might be helpful to refactor when adding new functionality as it would give better understanding of code. Sometimes, revisiting old design might help to accommodate new features better
* Fixing a bug - It is useful to refactor code which had a bug; this might save bug reports from the same piece of code in future
* During code review - Refactoring is useful during code reviews as it can be applied immediately making code reviews more fruitful
* Understanding other's code - If a new member joins the team and is asked to refactor existing code, it helps them to get a better understanding of the code base. It might take extra time to get them started, but trying to refactor will help them contribute to the project better in the long run.

A [http://blog.codeclimate.com/blog/2014/01/09/when-is-it-time-to-refactor/ CodeClimate blog] suggests some other conditions to decide when to refactor code.

==Automated Code Refactoring==
=== RubyMine ===
*[http://www.jetbrains.com/ruby/webhelp/refactoring.html RubyMine] has a built in refactoring menu.
*To perform refactoring, select a code fragment to refactor. Refactorings available for your selection appear under the Refactor Menu in RubyMine. <ref>http://www.jetbrains.com/ruby/webhelp/refactoring-source-code.html#common</ref> [[File:RubyMine_refactoring_menu.png]]

===RFactor ===
*[http://fabiokung.com/2009/02/04/rfactor-ruby-refactoring-for-your-loved-editor/ RFactor] is a Ruby gem, which aims to provide common and simple refactorings for Ruby code for text editors like TextMate
*The first release has only Extract method implemented while other refactorings are coming soon
*It is available on [http://github.com/fabiokung/rfactor-tmbundle/tree/master GitHub]

=== Other IDEs ===
*Some other IDEs with built-in refactoring include [http://www.aptana.com/products/studio3 Aptana Studio], [http://www.aptana.com/products/radrails Aptana RadRails] and [https://netbeans.org/features/ruby/index.html NetBeans 7] (which requires Ruby and Rails [http://plugins.netbeans.org/plugin/38549 plugin])
*A StackOverflow [http://stackoverflow.com/questions/8705144/ide-with-refactoring-support-for-ruby-on-rails post] compares these tools ranking them as RubyMine being the best, followed by NetBeans, RadRails 2 and Aptana Studio 3

==Further Reading==
*[http://en.wikipedia.org/wiki/Code_smell Ways to identify problems in code]

*[http://blog.codeclimate.com/blog/2012/11/14/why-ruby-class-methods-resist-refactoring/ Resistance With Refactoring Ruby Class Methods]

*[http://www.railsinside.com/uncategorized/460-the-first-step-of-refactoring-a-rails-application.html Refactoring a Rails Application]

*[http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ Refactoring Fat Models]

*[https://speakerdeck.com/brianvh/refactoring-views-in-rails Talk on Refactoring Fat Views]

*[http://www.amazon.com/Rails-AntiPatterns-Refactoring-Addison-Wesley-Professional/dp/0321604814 Rails AntiPatterns: Best Practice Ruby on Rails Refactoring]

==References==
<references/>

CSC/ECE 517 Spring 2014/ch1a 1w1e rm

2014-02-19T04:36:06Z

Rjlloyd: /* Duplicate Code */

This page discusses refactoring techniques and metrics. It also includes tips on refactoring in Ruby and list of tools for automated refactoring.

==Background==

The idea behind [http://en.wikipedia.org/wiki/Code_refactoring code refactoring] is to take a code base and improve it's readability, [http://en.wikipedia.org/wiki/Extensibility extensibility], and [http://en.wikipedia.org/wiki/Reusability reusability]. The practice is focused on having a better quality and more standardized code base, and not on fixing bugs or changing functionality.

Refactoring has its difficulties, whether or not it is done using an [http://en.wikipedia.org/wiki/Integrated_development_environment IDE] or whether it is done by hand. There are lots of pitfalls and errors that can be made during refactoring, so it is pertinent to determine how important a refactor is to the code. Code metrics are one method used to determine how badly a file needs refactoring.

==Refactoring Techniques==
Before a coder performs a refactor, they must, either formally or informally, identify their ‘code smells’. A code smell refers to a negative quality of a code base that either implements bad programming practices or slows down code development or runtime. These aren't typically bugs, but can increase the chance of bugs later on if not fixed. Based on the type of code smell, a different refactoring technique is used to fix it.

===Duplicate Code===
Duplicate code can be a tricky concept when refactoring. Large sections of duplicated code can be easy to find and fixed by pulling it out and creating a single centralized method to call, however it is usually not that easy. Sometimes it may only be one or two lines of code that are duplicated which calls for an assessment of whether or not it is in the best interest to create a new method for a couple lines of code. Other times, code is not duplicate, rather it is similar enough that a generic method could be created to serve various purposes.
Some specific techniques to deal with this are:
*Extract Method / Pull-up Method
**If common code is used in multiple places, simply pull it out and make a method that can be called from all of the necessary places. Variables can be passed in if slight variations are needed between calls.
**If the code is used in various subclasses, put the common code in a method in the superclass, so that it can be seen and called by it’s children.<ref>http://www.refactoring.com/catalog/extractMethod.html Extract Method Example</ref>
Before Refactor
<pre>
class Cat
end

class Lion < Mammal
...
def likes
puts "Boxes"
end
end
class HouseCat < Mammal
...
def likes
puts "Boxes"
end
end
</pre>
After Pull Up Refactor
<pre>
class Cat
def likes
puts "Boxes"
end
end

class Lion < Mammal
end
class HouseCat < Mammal
end
</pre>

*Form Template Method
**If two methods in subclasses perform similar steps in the same order, but the steps are different, then get the steps into methods with the same signature, so that the original methods become the same. Then pull them up. <ref>http://www.refactoring.com/catalog/formTemplateMethod.html</ref>
**[http://www.integralist.co.uk/posts/refactoring-techniques/#form-template-method Form Template Method Example]

===Large Method/Class===
If a project is not planned out well enough in advance, it is easy for methods and classes to become populated with excess functionality. While functionality of a block of code may be necessary for the project, the code block might not really pertain to the method or class it is included in.
*Extract Method
**This can be used when duplicate code occurs, as discussed above. But it can also be used when a method performs multiple functions that have the ability to be split up into various functions that serve a single purpose.
*Extract Class/Subclass/Superclass
**If there are class variables or methods that don’t directly pertain to a class, then it may be necessary to create a new class for those pieces.[http://www.refactoring.com/catalog/extractClass.html Example]
**If there are pieces of a class that are only for a specific subset of instances, then a subclass can be constructed to contain these.[http://www.refactoring.com/catalog/extractSubclass.html Example]
**If there are pieces that multiple classes use, then a superclass can be constructed to handle these generic functions, leaving the subclasses to deal with the remaining differences [http://www.refactoring.com/catalog/extractSuperclass.html Example]

===Improving Readability and Clarity===
Many times, refactoring can be used to do simple, yet necessary changes like renaming variables, methods, or classes. As features get added to a project, classes tend to get charged with more uses than originally planned, so sometimes, the original naming scheme no longer applies and a new one needs to be instilled.

Moving methods and parameters around to where they have the best accessibility also has its uses. Classes also tend to be promoted or demoted to super and sub classes after their ultimate functional purpose is determined.

===More Techniques===
There is an extensive list of coding smells that can be improved through refactoring.

A description of smells with their techniques exists [http://ghendry.net/refactor.html here].

A list of techniques with examples in Ruby are listed [http://www.refactoring.com/catalog/index.html here].

==Metrics==
It can be hard to decide whether or not to refactor, especially when it’s for something that appears to be working fine with just a surface level smell. Program analysis tools are used to derive various types of code metrics, which allow coders to identify problem areas and future pitfalls of their code base. These tools look at the code in several different ways, including the number of times a source file has been edited to help determine if it is a possible target of [feature envy], duplicate code structure to identify replicated lines, and block depths to suggest possible complexity issues.

===Open Source Ruby Metric Tools===
There are a variety of open source code metric tools that can be employed specifically for Ruby programs. [https://www.ruby-toolbox.com/categories/code_metrics The Ruby Toolbox] contains the most popular of these tools along with ratings.

[http://rubydoc.info/gems/simplecov/frames Simple Cov] is at the top of this list. It was developed specifically to be of use to anyone using any framework. It integrates itself with the project’s own test cases to check the code coverage of them in addition to cucumber features.

===Code Climate===
[https://codeclimate.com Code Climate] is a hosted code metrics tool that analyzes projects in a multitdue of ways. It produces three main metric ratings with grades from A-F that comprise of the methods and classes contained in each file and project.
#Complexity Metric - This is based off of the Assignment, Branches, and Conditions ([http://c2.com/cgi/wiki?AbcMetric ABC]) metric, where the number of assignments, branches, and conditions are counted and analyzed. However, because Code Climate is constructed for Ruby programs, it also takes into account certain types of Ruby constructs that may increase the metric score, but are actually beneficial to the project.
#Duplication Metric - This looks at the syntax trees of the code in order to identify identical and similar code structures. Because the syntax trees are being analyzed, code formatting and different method and class names do not affect the score. <ref>https://codeclimate.com/docs#quality-metrics</ref>
#Churn Method - This integrates with the Git repository to look at the change history of the project’s files. Files with excessively high change histories have a tendency to have a high complexity rating as well, as they can be the result of feature envy, where extra functions are added into a file instead of being added to a new file with it’s own functionality.

==Getting Started with Refactoring in Ruby==

===First step: Writing tests===
The first step in refactoring is writing solid set of tests for the section of code under consideration, in order to avoid introducing bugs. In Ruby, this can be done using [http://www.ruby-doc.org/stdlib-2.1.0/libdoc/test/unit/rdoc/Test/Unit.html Test::Unit] or [http://rspec.info/ Rspec]. Next step is to make small changes, test, make small changes, test again and so on<ref name='Refactoring Ruby Edition'>http://www.amazon.com/Refactoring-Edition-Addison-Wesley-Professional-Series/dp/0321984137</ref>. This ensures that we can revert back to the working version of code if any small refactoring causes the application to stop working.

===When to refactor===
It is always confusing when to start refactoring. If either one of the following conditions is true, it is a good time to start refactoring code<ref name='Refactoring Ruby Edition'/>:
* The Rule of Three - If any code segment gives trouble more than two times, it is time to refactor it
* Adding new function - It might be helpful to refactor when adding new functionality as it would give better understanding of code. Sometimes, revisiting old design might help to accommodate new features better
* Fixing a bug - It is useful to refactor code which had a bug; this might save bug reports from the same piece of code in future
* During code review - Refactoring is useful during code reviews as it can be applied immediately making code reviews more fruitful
* Understanding other's code - If a new member joins the team and is asked to refactor existing code, it helps them to get a better understanding of the code base. It might take extra time to get them started, but trying to refactor will help them contribute to the project better in the long run.

A [http://blog.codeclimate.com/blog/2014/01/09/when-is-it-time-to-refactor/ CodeClimate blog] suggests some other conditions to decide when to refactor code.

==Automated Code Refactoring==
=== RubyMine ===
*[http://www.jetbrains.com/ruby/webhelp/refactoring.html RubyMine] has a built in refactoring menu.
*To perform refactoring, select a code fragment to refactor. Refactorings available for your selection appear under the Refactor Menu in RubyMine. <ref>http://www.jetbrains.com/ruby/webhelp/refactoring-source-code.html#common</ref> [[File:RubyMine_refactoring_menu.png]]

===RFactor ===
*[http://fabiokung.com/2009/02/04/rfactor-ruby-refactoring-for-your-loved-editor/ RFactor] is a Ruby gem, which aims to provide common and simple refactorings for Ruby code for text editors like TextMate
*The first release has only Extract method implemented while other refactorings are coming soon
*It is available on [http://github.com/fabiokung/rfactor-tmbundle/tree/master GitHub]

=== Other IDEs ===
*Some other IDEs with built-in refactoring include [http://www.aptana.com/products/studio3 Aptana Studio], [http://www.aptana.com/products/radrails Aptana RadRails] and [https://netbeans.org/features/ruby/index.html NetBeans 7] (which requires Ruby and Rails [http://plugins.netbeans.org/plugin/38549 plugin])
*A StackOverflow [http://stackoverflow.com/questions/8705144/ide-with-refactoring-support-for-ruby-on-rails post] compares these tools ranking them as RubyMine being the best, followed by NetBeans, RadRails 2 and Aptana Studio 3

==Further Reading==
*[http://en.wikipedia.org/wiki/Code_smell Ways to identify problems in code]

*[http://blog.codeclimate.com/blog/2012/11/14/why-ruby-class-methods-resist-refactoring/ Resistance With Refactoring Ruby Class Methods]

*[http://www.railsinside.com/uncategorized/460-the-first-step-of-refactoring-a-rails-application.html Refactoring a Rails Application]

*[http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ Refactoring Fat Models]

*[https://speakerdeck.com/brianvh/refactoring-views-in-rails Talk on Refactoring Fat Views]

*[http://www.amazon.com/Rails-AntiPatterns-Refactoring-Addison-Wesley-Professional/dp/0321604814 Rails AntiPatterns: Best Practice Ruby on Rails Refactoring]

==References==
<references/>

CSC/ECE 517 Spring 2014/ch1a 1w1e rm

2014-02-19T04:35:12Z

Rjlloyd: /* Duplicate Code */

This page discusses refactoring techniques and metrics. It also includes tips on refactoring in Ruby and list of tools for automated refactoring.

==Background==

The idea behind [http://en.wikipedia.org/wiki/Code_refactoring code refactoring] is to take a code base and improve it's readability, [http://en.wikipedia.org/wiki/Extensibility extensibility], and [http://en.wikipedia.org/wiki/Reusability reusability]. The practice is focused on having a better quality and more standardized code base, and not on fixing bugs or changing functionality.

Refactoring has its difficulties, whether or not it is done using an [http://en.wikipedia.org/wiki/Integrated_development_environment IDE] or whether it is done by hand. There are lots of pitfalls and errors that can be made during refactoring, so it is pertinent to determine how important a refactor is to the code. Code metrics are one method used to determine how badly a file needs refactoring.

==Refactoring Techniques==
Before a coder performs a refactor, they must, either formally or informally, identify their ‘code smells’. A code smell refers to a negative quality of a code base that either implements bad programming practices or slows down code development or runtime. These aren't typically bugs, but can increase the chance of bugs later on if not fixed. Based on the type of code smell, a different refactoring technique is used to fix it.

===Duplicate Code===
Duplicate code can be a tricky concept when refactoring. Large sections of duplicated code can be easy to find and fixed by pulling it out and creating a single centralized method to call, however it is usually not that easy. Sometimes it may only be one or two lines of code that are duplicated which calls for an assessment of whether or not it is in the best interest to create a new method for a couple lines of code. Other times, code is not duplicate, rather it is similar enough that a generic method could be created to serve various purposes.
Some specific techniques to deal with this are:
*Extract Method / Pull-up Method
**If common code is used in multiple places, simply pull it out and make a method that can be called from all of the necessary places. Variables can be passed in if slight variations are needed between calls.
**If the code is used in various subclasses, put the common code in a method in the superclass, so that it can be seen and called by it’s children.<ref>http://www.refactoring.com/catalog/extractMethod.html Extract Method Example</ref>
Before Refactor
<pre>
class Cat
....
end

class Lion < Mammal
...
def likes
puts "Boxes"
end
end
class HouseCat < Mammal
...
def likes
puts "Boxes"
end
end
</pre>
After Pull Up Refactor
<pre>
class Cat
...
def likes
puts "Boxes"
end
end

class Lion < Mammal
...
end
class HouseCat < Mammal
...
end
</pre>

*Form Template Method
**If two methods in subclasses perform similar steps in the same order, but the steps are different, then get the steps into methods with the same signature, so that the original methods become the same. Then pull them up. <ref>http://www.refactoring.com/catalog/formTemplateMethod.html</ref>
**[http://www.integralist.co.uk/posts/refactoring-techniques/#form-template-method Form Template Method Example]

===Large Method/Class===
If a project is not planned out well enough in advance, it is easy for methods and classes to become populated with excess functionality. While functionality of a block of code may be necessary for the project, the code block might not really pertain to the method or class it is included in.
*Extract Method
**This can be used when duplicate code occurs, as discussed above. But it can also be used when a method performs multiple functions that have the ability to be split up into various functions that serve a single purpose.
*Extract Class/Subclass/Superclass
**If there are class variables or methods that don’t directly pertain to a class, then it may be necessary to create a new class for those pieces.[http://www.refactoring.com/catalog/extractClass.html Example]
**If there are pieces of a class that are only for a specific subset of instances, then a subclass can be constructed to contain these.[http://www.refactoring.com/catalog/extractSubclass.html Example]
**If there are pieces that multiple classes use, then a superclass can be constructed to handle these generic functions, leaving the subclasses to deal with the remaining differences [http://www.refactoring.com/catalog/extractSuperclass.html Example]

===Improving Readability and Clarity===
Many times, refactoring can be used to do simple, yet necessary changes like renaming variables, methods, or classes. As features get added to a project, classes tend to get charged with more uses than originally planned, so sometimes, the original naming scheme no longer applies and a new one needs to be instilled.

Moving methods and parameters around to where they have the best accessibility also has its uses. Classes also tend to be promoted or demoted to super and sub classes after their ultimate functional purpose is determined.

===More Techniques===
There is an extensive list of coding smells that can be improved through refactoring.

A description of smells with their techniques exists [http://ghendry.net/refactor.html here].

A list of techniques with examples in Ruby are listed [http://www.refactoring.com/catalog/index.html here].

==Metrics==
It can be hard to decide whether or not to refactor, especially when it’s for something that appears to be working fine with just a surface level smell. Program analysis tools are used to derive various types of code metrics, which allow coders to identify problem areas and future pitfalls of their code base. These tools look at the code in several different ways, including the number of times a source file has been edited to help determine if it is a possible target of [feature envy], duplicate code structure to identify replicated lines, and block depths to suggest possible complexity issues.

===Open Source Ruby Metric Tools===
There are a variety of open source code metric tools that can be employed specifically for Ruby programs. [https://www.ruby-toolbox.com/categories/code_metrics The Ruby Toolbox] contains the most popular of these tools along with ratings.

[http://rubydoc.info/gems/simplecov/frames Simple Cov] is at the top of this list. It was developed specifically to be of use to anyone using any framework. It integrates itself with the project’s own test cases to check the code coverage of them in addition to cucumber features.

===Code Climate===
[https://codeclimate.com Code Climate] is a hosted code metrics tool that analyzes projects in a multitdue of ways. It produces three main metric ratings with grades from A-F that comprise of the methods and classes contained in each file and project.
#Complexity Metric - This is based off of the Assignment, Branches, and Conditions ([http://c2.com/cgi/wiki?AbcMetric ABC]) metric, where the number of assignments, branches, and conditions are counted and analyzed. However, because Code Climate is constructed for Ruby programs, it also takes into account certain types of Ruby constructs that may increase the metric score, but are actually beneficial to the project.
#Duplication Metric - This looks at the syntax trees of the code in order to identify identical and similar code structures. Because the syntax trees are being analyzed, code formatting and different method and class names do not affect the score. <ref>https://codeclimate.com/docs#quality-metrics</ref>
#Churn Method - This integrates with the Git repository to look at the change history of the project’s files. Files with excessively high change histories have a tendency to have a high complexity rating as well, as they can be the result of feature envy, where extra functions are added into a file instead of being added to a new file with it’s own functionality.

==Getting Started with Refactoring in Ruby==

===First step: Writing tests===
The first step in refactoring is writing solid set of tests for the section of code under consideration, in order to avoid introducing bugs. In Ruby, this can be done using [http://www.ruby-doc.org/stdlib-2.1.0/libdoc/test/unit/rdoc/Test/Unit.html Test::Unit] or [http://rspec.info/ Rspec]. Next step is to make small changes, test, make small changes, test again and so on<ref name='Refactoring Ruby Edition'>http://www.amazon.com/Refactoring-Edition-Addison-Wesley-Professional-Series/dp/0321984137</ref>. This ensures that we can revert back to the working version of code if any small refactoring causes the application to stop working.

===When to refactor===
It is always confusing when to start refactoring. If either one of the following conditions is true, it is a good time to start refactoring code<ref name='Refactoring Ruby Edition'/>:
* The Rule of Three - If any code segment gives trouble more than two times, it is time to refactor it
* Adding new function - It might be helpful to refactor when adding new functionality as it would give better understanding of code. Sometimes, revisiting old design might help to accommodate new features better
* Fixing a bug - It is useful to refactor code which had a bug; this might save bug reports from the same piece of code in future
* During code review - Refactoring is useful during code reviews as it can be applied immediately making code reviews more fruitful
* Understanding other's code - If a new member joins the team and is asked to refactor existing code, it helps them to get a better understanding of the code base. It might take extra time to get them started, but trying to refactor will help them contribute to the project better in the long run.

A [http://blog.codeclimate.com/blog/2014/01/09/when-is-it-time-to-refactor/ CodeClimate blog] suggests some other conditions to decide when to refactor code.

==Automated Code Refactoring==
=== RubyMine ===
*[http://www.jetbrains.com/ruby/webhelp/refactoring.html RubyMine] has a built in refactoring menu.
*To perform refactoring, select a code fragment to refactor. Refactorings available for your selection appear under the Refactor Menu in RubyMine. <ref>http://www.jetbrains.com/ruby/webhelp/refactoring-source-code.html#common</ref> [[File:RubyMine_refactoring_menu.png]]

===RFactor ===
*[http://fabiokung.com/2009/02/04/rfactor-ruby-refactoring-for-your-loved-editor/ RFactor] is a Ruby gem, which aims to provide common and simple refactorings for Ruby code for text editors like TextMate
*The first release has only Extract method implemented while other refactorings are coming soon
*It is available on [http://github.com/fabiokung/rfactor-tmbundle/tree/master GitHub]

=== Other IDEs ===
*Some other IDEs with built-in refactoring include [http://www.aptana.com/products/studio3 Aptana Studio], [http://www.aptana.com/products/radrails Aptana RadRails] and [https://netbeans.org/features/ruby/index.html NetBeans 7] (which requires Ruby and Rails [http://plugins.netbeans.org/plugin/38549 plugin])
*A StackOverflow [http://stackoverflow.com/questions/8705144/ide-with-refactoring-support-for-ruby-on-rails post] compares these tools ranking them as RubyMine being the best, followed by NetBeans, RadRails 2 and Aptana Studio 3

==Further Reading==
*[http://en.wikipedia.org/wiki/Code_smell Ways to identify problems in code]

*[http://blog.codeclimate.com/blog/2012/11/14/why-ruby-class-methods-resist-refactoring/ Resistance With Refactoring Ruby Class Methods]

*[http://www.railsinside.com/uncategorized/460-the-first-step-of-refactoring-a-rails-application.html Refactoring a Rails Application]

*[http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ Refactoring Fat Models]

*[https://speakerdeck.com/brianvh/refactoring-views-in-rails Talk on Refactoring Fat Views]

*[http://www.amazon.com/Rails-AntiPatterns-Refactoring-Addison-Wesley-Professional/dp/0321604814 Rails AntiPatterns: Best Practice Ruby on Rails Refactoring]

==References==
<references/>

CSC/ECE 517 Spring 2014

2014-02-12T05:47:17Z

Rjlloyd:

*[[CSC/ECE_517_Fall_2012/example_page]]
*[[CSC/ECE 517 Spring 2014/ch1a 1e rm]]
*[[CSC/ECE 517 Spring 2014/ch1 1w1h jg ]]
*[[CSC/ECE 517 Spring 2014/ch1 1w1b np]]
*[[CSC/ECE 517 Spring 2014/ch1 1w1f mj]]
*[[CSC/ECE 517 Spring 2014/ch1a 1d mm]]
*[[CSC/ECE 517 Spring 2014/ch1a 1c yj]]

CSC/ECE 517 Spring 2014/ch1a 1e rm1

2014-02-12T05:42:54Z

Rjlloyd: moved CSC/ECE 517 Spring 2014/ch1a 1e rm1 to CSC/ECE 517 Spring 2014/ch1a 1e rm over redirect

#REDIRECT [[CSC/ECE 517 Spring 2014/ch1a 1e rm]]

CSC/ECE 517 Spring 2014/ch1a 1e rm

2014-02-12T05:42:54Z

Rjlloyd: moved CSC/ECE 517 Spring 2014/ch1a 1e rm1 to CSC/ECE 517 Spring 2014/ch1a 1e rm over redirect

This page discusses refactoring techniques and metrics. It also includes tips on refactoring in Ruby and list of tools for automated refactoring.

For the page with a history of edits, go to [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2014/ch1a_1w1e_rm this page].

==Background==

The idea behind [http://en.wikipedia.org/wiki/Code_refactoring code refactoring] is to take a code base and improve it's readability, [http://en.wikipedia.org/wiki/Extensibility extensibility], and [http://en.wikipedia.org/wiki/Reusability reusability]. The practice is focused on having a better quality and more standardized code base, and not on fixing bugs or changing functionality.

Refactoring has its difficulties, whether or not it is done using an [http://en.wikipedia.org/wiki/Integrated_development_environment IDE] or whether it is done by hand. There are lots of pitfalls and errors that can be made during refactoring, so it is pertinent to determine how important a refactor is to the code. Code metrics are one method used to determine how badly a file needs refactoring.

==Refactoring Techniques==
Before a coder performs a refactor, they must, either formally or informally, identify their ‘code smells’. A code smell refers to a negative quality of a code base that either implements bad programming practices or slows down code development or runtime. These aren't typically bugs, but can increase the chance of bugs later on if not fixed. Based on the type of code smell, a different refactoring technique is used to fix it.

===Duplicate Code===
Duplicate code can be a tricky concept when refactoring. Large sections of duplicated code can be easy to find and fixed by pulling it out and creating a single centralized method to call, however it is usually not that easy. Sometimes it may only be one or two lines of code that are duplicated which calls for an assessment of whether or not it is in the best interest to create a new method for a couple lines of code. Other times, code is not duplicate, rather it is similar enough that a generic method could be created to serve various purposes.
Some specific techniques to deal with this are:
*Extract Method / Pull-up Method
**If common code is used in multiple places, simply pull it out and make a method that can be called from all of the necessary places. Variables can be passed in if slight variations are needed between calls.
**If the code is used in various subclasses, put the common code in a method in the superclass, so that it can be seen and called by it’s children.
**[http://www.refactoring.com/catalog/extractMethod.html Extract Method Example]

*Form Template Method
**If two methods in subclasses perform similar steps in the same order, but the steps are different, then get the steps into methods with the same signature, so that the original methods become the same. Then pull them up. <ref>http://www.refactoring.com/catalog/formTemplateMethod.html</ref>
**[http://www.integralist.co.uk/posts/refactoring-techniques/#form-template-method Form Template Method Example]

===Large Method/Class===
If a project is not planned out well enough in advance, it is easy for methods and classes to become populated with excess functionality. While functionality of a block of code may be necessary for the project, the code block might not really pertain to the method or class it is included in.
*Extract Method
**This can be used when duplicate code occurs, as discussed above. But it can also be used when a method performs multiple functions that have the ability to be split up into various functions that serve a single purpose.
*Extract Class/Subclass/Superclass
**If there are class variables or methods that don’t directly pertain to a class, then it may be necessary to create a new class for those pieces.[http://www.refactoring.com/catalog/extractClass.html Example]
**If there are pieces of a class that are only for a specific subset of instances, then a subclass can be constructed to contain these.[http://www.refactoring.com/catalog/extractSubclass.html Example]
**If there are pieces that multiple classes use, then a superclass can be constructed to handle these generic functions, leaving the subclasses to deal with the remaining differences [http://www.refactoring.com/catalog/extractSuperclass.html Example]

===Improving Readability and Clarity===
Many times, refactoring can be used to do simple, yet necessary changes like renaming variables, methods, or classes. As features get added to a project, classes tend to get charged with more uses than originally planned, so sometimes, the original naming scheme no longer applies and a new one needs to be instilled.

Moving methods and parameters around to where they have the best accessibility also has its uses. Classes also tend to be promoted or demoted to super and sub classes after their ultimate functional purpose is determined.

===More Techniques===
There is an extensive list of coding smells that can be improved through refactoring.

A description of smells with their techniques exists [http://ghendry.net/refactor.html here].

A list of techniques with examples in Ruby are listed [http://www.refactoring.com/catalog/index.html here].

==Metrics==
It can be hard to decide whether or not to refactor, especially when it’s for something that appears to be working fine with just a surface level smell. Program analysis tools are used to derive various types of code metrics, which allow coders to identify problem areas and future pitfalls of their code base. These tools look at the code in several different ways, including the number of times a source file has been edited to help determine if it is a possible target of [feature envy], duplicate code structure to identify replicated lines, and block depths to suggest possible complexity issues.

===Open Source Ruby Metric Tools===
There are a variety of open source code metric tools that can be employed specifically for Ruby programs. [https://www.ruby-toolbox.com/categories/code_metrics The Ruby Toolbox] contains the most popular of these tools along with ratings.

[http://rubydoc.info/gems/simplecov/frames Simple Cov] is at the top of this list. It was developed specifically to be of use to anyone using any framework. It integrates itself with the project’s own test cases to check the code coverage of them in addition to cucumber features.

===Code Climate===
[https://codeclimate.com Code Climate] is a hosted code metrics tool that analyzes projects in a multitdue of ways. It produces three main metric ratings with grades from A-F that comprise of the methods and classes contained in each file and project.
#Complexity Metric - This is based off of the Assignment, Branches, and Conditions ([http://c2.com/cgi/wiki?AbcMetric ABC]) metric, where the number of assignments, branches, and conditions are counted and analyzed. However, because Code Climate is constructed for Ruby programs, it also takes into account certain types of Ruby constructs that may increase the metric score, but are actually beneficial to the project.
#Duplication Metric - This looks at the syntax trees of the code in order to identify identical and similar code structures. Because the syntax trees are being analyzed, code formatting and different method and class names do not affect the score. <ref>https://codeclimate.com/docs#quality-metrics</ref>
#Churn Method - This integrates with the Git repository to look at the change history of the project’s files. Files with excessively high change histories have a tendency to have a high complexity rating as well, as they can be the result of feature envy, where extra functions are added into a file instead of being added to a new file with it’s own functionality.

==Getting Started with Refactoring in Ruby==

===First step: Writing tests===
The first step in refactoring is writing solid set of tests for the section of code under consideration, in order to avoid introducing bugs. In Ruby, this can be done using [http://www.ruby-doc.org/stdlib-2.1.0/libdoc/test/unit/rdoc/Test/Unit.html Test::Unit] or [http://rspec.info/ Rspec]. Next step is to make small changes, test, make small changes, test again and so on<ref name='Refactoring Ruby Edition'>http://www.amazon.com/Refactoring-Edition-Addison-Wesley-Professional-Series/dp/0321984137</ref>. This ensures that we can revert back to the working version of code if any small refactoring causes the application to stop working.

===When to refactor===
It is always confusing when to start refactoring. If either one of the following conditions is true, it is a good time to start refactoring code<ref name='Refactoring Ruby Edition'/>:
* The Rule of Three - If any code segment gives trouble more than two times, it is time to refactor it
* Adding new function - It might be helpful to refactor when adding new functionality as it would give better understanding of code. Sometimes, revisiting old design might help to accommodate new features better
* Fixing a bug - It is useful to refactor code which had a bug; this might save bug reports from the same piece of code in future
* During code review - Refactoring is useful during code reviews as it can be applied immediately making code reviews more fruitful
* Understanding other's code - If a new member joins the team and is asked to refactor existing code, it helps them to get a better understanding of the code base. It might take extra time to get them started, but trying to refactor will help them contribute to the project better in the long run.

A [http://blog.codeclimate.com/blog/2014/01/09/when-is-it-time-to-refactor/ CodeClimate blog] suggests some other conditions to decide when to refactor code.

==Automated Code Refactoring==
=== RubyMine ===
*[http://www.jetbrains.com/ruby/webhelp/refactoring.html RubyMine] has a built in refactoring menu.
*To perform refactoring, select a code fragment to refactor. Refactorings available for your selection appear under the Refactor Menu in RubyMine. <ref>http://www.jetbrains.com/ruby/webhelp/refactoring-source-code.html#common</ref> [[File:RubyMine_refactoring_menu.png]]

===RFactor ===
*[http://fabiokung.com/2009/02/04/rfactor-ruby-refactoring-for-your-loved-editor/ RFactor] is a Ruby gem, which aims to provide common and simple refactorings for Ruby code for text editors like TextMate
*The first release has only Extract method implemented while other refactorings are coming soon
*It is available on [http://github.com/fabiokung/rfactor-tmbundle/tree/master GitHub]

=== Other IDEs ===
*Some other IDEs with built-in refactoring include [http://www.aptana.com/products/studio3 Aptana Studio], [http://www.aptana.com/products/radrails Aptana RadRails] and [https://netbeans.org/features/ruby/index.html NetBeans 7] (which requires Ruby and Rails [http://plugins.netbeans.org/plugin/38549 plugin])
*A StackOverflow [http://stackoverflow.com/questions/8705144/ide-with-refactoring-support-for-ruby-on-rails post] compares these tools ranking them as RubyMine being the best, followed by NetBeans, RadRails 2 and Aptana Studio 3

==Further Reading==
*[http://en.wikipedia.org/wiki/Code_smell Ways to identify problems in code]

*[http://blog.codeclimate.com/blog/2012/11/14/why-ruby-class-methods-resist-refactoring/ Resistance With Refactoring Ruby Class Methods]

*[http://www.railsinside.com/uncategorized/460-the-first-step-of-refactoring-a-rails-application.html Refactoring a Rails Application]

*[http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ Refactoring Fat Models]

*[https://speakerdeck.com/brianvh/refactoring-views-in-rails Talk on Refactoring Fat Views]

*[http://www.amazon.com/Rails-AntiPatterns-Refactoring-Addison-Wesley-Professional/dp/0321604814 Rails AntiPatterns: Best Practice Ruby on Rails Refactoring]

==References==
<references/>

CSC/ECE 517 Spring 2014/ch1a 1e rm

2014-02-12T05:42:45Z

Rjlloyd:

This page discusses refactoring techniques and metrics. It also includes tips on refactoring in Ruby and list of tools for automated refactoring.

For the page with a history of edits, go to [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2014/ch1a_1w1e_rm this page].

==Background==

The idea behind [http://en.wikipedia.org/wiki/Code_refactoring code refactoring] is to take a code base and improve it's readability, [http://en.wikipedia.org/wiki/Extensibility extensibility], and [http://en.wikipedia.org/wiki/Reusability reusability]. The practice is focused on having a better quality and more standardized code base, and not on fixing bugs or changing functionality.

Refactoring has its difficulties, whether or not it is done using an [http://en.wikipedia.org/wiki/Integrated_development_environment IDE] or whether it is done by hand. There are lots of pitfalls and errors that can be made during refactoring, so it is pertinent to determine how important a refactor is to the code. Code metrics are one method used to determine how badly a file needs refactoring.

==Refactoring Techniques==
Before a coder performs a refactor, they must, either formally or informally, identify their ‘code smells’. A code smell refers to a negative quality of a code base that either implements bad programming practices or slows down code development or runtime. These aren't typically bugs, but can increase the chance of bugs later on if not fixed. Based on the type of code smell, a different refactoring technique is used to fix it.

===Duplicate Code===
Duplicate code can be a tricky concept when refactoring. Large sections of duplicated code can be easy to find and fixed by pulling it out and creating a single centralized method to call, however it is usually not that easy. Sometimes it may only be one or two lines of code that are duplicated which calls for an assessment of whether or not it is in the best interest to create a new method for a couple lines of code. Other times, code is not duplicate, rather it is similar enough that a generic method could be created to serve various purposes.
Some specific techniques to deal with this are:
*Extract Method / Pull-up Method
**If common code is used in multiple places, simply pull it out and make a method that can be called from all of the necessary places. Variables can be passed in if slight variations are needed between calls.
**If the code is used in various subclasses, put the common code in a method in the superclass, so that it can be seen and called by it’s children.
**[http://www.refactoring.com/catalog/extractMethod.html Extract Method Example]

*Form Template Method
**If two methods in subclasses perform similar steps in the same order, but the steps are different, then get the steps into methods with the same signature, so that the original methods become the same. Then pull them up. <ref>http://www.refactoring.com/catalog/formTemplateMethod.html</ref>
**[http://www.integralist.co.uk/posts/refactoring-techniques/#form-template-method Form Template Method Example]

===Large Method/Class===
If a project is not planned out well enough in advance, it is easy for methods and classes to become populated with excess functionality. While functionality of a block of code may be necessary for the project, the code block might not really pertain to the method or class it is included in.
*Extract Method
**This can be used when duplicate code occurs, as discussed above. But it can also be used when a method performs multiple functions that have the ability to be split up into various functions that serve a single purpose.
*Extract Class/Subclass/Superclass
**If there are class variables or methods that don’t directly pertain to a class, then it may be necessary to create a new class for those pieces.[http://www.refactoring.com/catalog/extractClass.html Example]
**If there are pieces of a class that are only for a specific subset of instances, then a subclass can be constructed to contain these.[http://www.refactoring.com/catalog/extractSubclass.html Example]
**If there are pieces that multiple classes use, then a superclass can be constructed to handle these generic functions, leaving the subclasses to deal with the remaining differences [http://www.refactoring.com/catalog/extractSuperclass.html Example]

===Improving Readability and Clarity===
Many times, refactoring can be used to do simple, yet necessary changes like renaming variables, methods, or classes. As features get added to a project, classes tend to get charged with more uses than originally planned, so sometimes, the original naming scheme no longer applies and a new one needs to be instilled.

Moving methods and parameters around to where they have the best accessibility also has its uses. Classes also tend to be promoted or demoted to super and sub classes after their ultimate functional purpose is determined.

===More Techniques===
There is an extensive list of coding smells that can be improved through refactoring.

A description of smells with their techniques exists [http://ghendry.net/refactor.html here].

A list of techniques with examples in Ruby are listed [http://www.refactoring.com/catalog/index.html here].

==Metrics==
It can be hard to decide whether or not to refactor, especially when it’s for something that appears to be working fine with just a surface level smell. Program analysis tools are used to derive various types of code metrics, which allow coders to identify problem areas and future pitfalls of their code base. These tools look at the code in several different ways, including the number of times a source file has been edited to help determine if it is a possible target of [feature envy], duplicate code structure to identify replicated lines, and block depths to suggest possible complexity issues.

===Open Source Ruby Metric Tools===
There are a variety of open source code metric tools that can be employed specifically for Ruby programs. [https://www.ruby-toolbox.com/categories/code_metrics The Ruby Toolbox] contains the most popular of these tools along with ratings.

[http://rubydoc.info/gems/simplecov/frames Simple Cov] is at the top of this list. It was developed specifically to be of use to anyone using any framework. It integrates itself with the project’s own test cases to check the code coverage of them in addition to cucumber features.

===Code Climate===
[https://codeclimate.com Code Climate] is a hosted code metrics tool that analyzes projects in a multitdue of ways. It produces three main metric ratings with grades from A-F that comprise of the methods and classes contained in each file and project.
#Complexity Metric - This is based off of the Assignment, Branches, and Conditions ([http://c2.com/cgi/wiki?AbcMetric ABC]) metric, where the number of assignments, branches, and conditions are counted and analyzed. However, because Code Climate is constructed for Ruby programs, it also takes into account certain types of Ruby constructs that may increase the metric score, but are actually beneficial to the project.
#Duplication Metric - This looks at the syntax trees of the code in order to identify identical and similar code structures. Because the syntax trees are being analyzed, code formatting and different method and class names do not affect the score. <ref>https://codeclimate.com/docs#quality-metrics</ref>
#Churn Method - This integrates with the Git repository to look at the change history of the project’s files. Files with excessively high change histories have a tendency to have a high complexity rating as well, as they can be the result of feature envy, where extra functions are added into a file instead of being added to a new file with it’s own functionality.

==Getting Started with Refactoring in Ruby==

===First step: Writing tests===
The first step in refactoring is writing solid set of tests for the section of code under consideration, in order to avoid introducing bugs. In Ruby, this can be done using [http://www.ruby-doc.org/stdlib-2.1.0/libdoc/test/unit/rdoc/Test/Unit.html Test::Unit] or [http://rspec.info/ Rspec]. Next step is to make small changes, test, make small changes, test again and so on<ref name='Refactoring Ruby Edition'>http://www.amazon.com/Refactoring-Edition-Addison-Wesley-Professional-Series/dp/0321984137</ref>. This ensures that we can revert back to the working version of code if any small refactoring causes the application to stop working.

===When to refactor===
It is always confusing when to start refactoring. If either one of the following conditions is true, it is a good time to start refactoring code<ref name='Refactoring Ruby Edition'/>:
* The Rule of Three - If any code segment gives trouble more than two times, it is time to refactor it
* Adding new function - It might be helpful to refactor when adding new functionality as it would give better understanding of code. Sometimes, revisiting old design might help to accommodate new features better
* Fixing a bug - It is useful to refactor code which had a bug; this might save bug reports from the same piece of code in future
* During code review - Refactoring is useful during code reviews as it can be applied immediately making code reviews more fruitful
* Understanding other's code - If a new member joins the team and is asked to refactor existing code, it helps them to get a better understanding of the code base. It might take extra time to get them started, but trying to refactor will help them contribute to the project better in the long run.

A [http://blog.codeclimate.com/blog/2014/01/09/when-is-it-time-to-refactor/ CodeClimate blog] suggests some other conditions to decide when to refactor code.

==Automated Code Refactoring==
=== RubyMine ===
*[http://www.jetbrains.com/ruby/webhelp/refactoring.html RubyMine] has a built in refactoring menu.
*To perform refactoring, select a code fragment to refactor. Refactorings available for your selection appear under the Refactor Menu in RubyMine. <ref>http://www.jetbrains.com/ruby/webhelp/refactoring-source-code.html#common</ref> [[File:RubyMine_refactoring_menu.png]]

===RFactor ===
*[http://fabiokung.com/2009/02/04/rfactor-ruby-refactoring-for-your-loved-editor/ RFactor] is a Ruby gem, which aims to provide common and simple refactorings for Ruby code for text editors like TextMate
*The first release has only Extract method implemented while other refactorings are coming soon
*It is available on [http://github.com/fabiokung/rfactor-tmbundle/tree/master GitHub]

=== Other IDEs ===
*Some other IDEs with built-in refactoring include [http://www.aptana.com/products/studio3 Aptana Studio], [http://www.aptana.com/products/radrails Aptana RadRails] and [https://netbeans.org/features/ruby/index.html NetBeans 7] (which requires Ruby and Rails [http://plugins.netbeans.org/plugin/38549 plugin])
*A StackOverflow [http://stackoverflow.com/questions/8705144/ide-with-refactoring-support-for-ruby-on-rails post] compares these tools ranking them as RubyMine being the best, followed by NetBeans, RadRails 2 and Aptana Studio 3

==Further Reading==
*[http://en.wikipedia.org/wiki/Code_smell Ways to identify problems in code]

*[http://blog.codeclimate.com/blog/2012/11/14/why-ruby-class-methods-resist-refactoring/ Resistance With Refactoring Ruby Class Methods]

*[http://www.railsinside.com/uncategorized/460-the-first-step-of-refactoring-a-rails-application.html Refactoring a Rails Application]

*[http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ Refactoring Fat Models]

*[https://speakerdeck.com/brianvh/refactoring-views-in-rails Talk on Refactoring Fat Views]

*[http://www.amazon.com/Rails-AntiPatterns-Refactoring-Addison-Wesley-Professional/dp/0321604814 Rails AntiPatterns: Best Practice Ruby on Rails Refactoring]

==References==
<references/>

CSC/ECE 517 Spring 2014

2014-02-12T05:40:14Z

Rjlloyd:

*[[CSC/ECE_517_Fall_2012/example_page]]
*[[CSC/ECE 517 Spring 2014/ch1a 1w1e rm]]
*[[CSC/ECE 517 Spring 2014/ch1 1w1h jg ]]
*[[CSC/ECE 517 Spring 2014/ch1 1w1b np]]
*[[CSC/ECE 517 Spring 2014/ch1 1w1f mj]]
*[[CSC/ECE 517 Spring 2014/ch1a 1d mm]]
*[[CSC/ECE 517 Spring 2014/ch1a 1c yj]]

CSC/ECE 517 Spring 2014/ch1a 1e rm

2014-02-12T05:34:52Z

Rjlloyd: moved CSC/ECE 517 Spring 2014/ch1a 1e rm to CSC/ECE 517 Spring 2014/ch1a 1e rm1

CSC/ECE 517 Spring 2014/ch1a 1e rm

2014-02-12T05:34:41Z

Rjlloyd: Blanked the page

CSC/ECE 517 Spring 2014/ch1 1w1e rm

2014-02-12T05:33:37Z

Rjlloyd: moved CSC/ECE 517 Spring 2014/ch1 1w1e rm to CSC/ECE 517 Spring 2014/ch1a 1w1e rm: wrong title

#REDIRECT [[CSC/ECE 517 Spring 2014/ch1a 1w1e rm]]

CSC/ECE 517 Spring 2014/ch1a 1w1e rm

2014-02-12T05:33:37Z

Rjlloyd: moved CSC/ECE 517 Spring 2014/ch1 1w1e rm to CSC/ECE 517 Spring 2014/ch1a 1w1e rm: wrong title

This page discusses refactoring techniques and metrics. It also includes tips on refactoring in Ruby and list of tools for automated refactoring.

==Background==

The idea behind [http://en.wikipedia.org/wiki/Code_refactoring code refactoring] is to take a code base and improve it's readability, [http://en.wikipedia.org/wiki/Extensibility extensibility], and [http://en.wikipedia.org/wiki/Reusability reusability]. The practice is focused on having a better quality and more standardized code base, and not on fixing bugs or changing functionality.

Refactoring has its difficulties, whether or not it is done using an [http://en.wikipedia.org/wiki/Integrated_development_environment IDE] or whether it is done by hand. There are lots of pitfalls and errors that can be made during refactoring, so it is pertinent to determine how important a refactor is to the code. Code metrics are one method used to determine how badly a file needs refactoring.

==Refactoring Techniques==
Before a coder performs a refactor, they must, either formally or informally, identify their ‘code smells’. A code smell refers to a negative quality of a code base that either implements bad programming practices or slows down code development or runtime. These aren't typically bugs, but can increase the chance of bugs later on if not fixed. Based on the type of code smell, a different refactoring technique is used to fix it.

===Duplicate Code===
Duplicate code can be a tricky concept when refactoring. Large sections of duplicated code can be easy to find and fixed by pulling it out and creating a single centralized method to call, however it is usually not that easy. Sometimes it may only be one or two lines of code that are duplicated which calls for an assessment of whether or not it is in the best interest to create a new method for a couple lines of code. Other times, code is not duplicate, rather it is similar enough that a generic method could be created to serve various purposes.
Some specific techniques to deal with this are:
*Extract Method / Pull-up Method
**If common code is used in multiple places, simply pull it out and make a method that can be called from all of the necessary places. Variables can be passed in if slight variations are needed between calls.
**If the code is used in various subclasses, put the common code in a method in the superclass, so that it can be seen and called by it’s children.
**[http://www.refactoring.com/catalog/extractMethod.html Extract Method Example]

*Form Template Method
**If two methods in subclasses perform similar steps in the same order, but the steps are different, then get the steps into methods with the same signature, so that the original methods become the same. Then pull them up. <ref>http://www.refactoring.com/catalog/formTemplateMethod.html</ref>
**[http://www.integralist.co.uk/posts/refactoring-techniques/#form-template-method Form Template Method Example]

===Large Method/Class===
If a project is not planned out well enough in advance, it is easy for methods and classes to become populated with excess functionality. While functionality of a block of code may be necessary for the project, the code block might not really pertain to the method or class it is included in.
*Extract Method
**This can be used when duplicate code occurs, as discussed above. But it can also be used when a method performs multiple functions that have the ability to be split up into various functions that serve a single purpose.
*Extract Class/Subclass/Superclass
**If there are class variables or methods that don’t directly pertain to a class, then it may be necessary to create a new class for those pieces.[http://www.refactoring.com/catalog/extractClass.html Example]
**If there are pieces of a class that are only for a specific subset of instances, then a subclass can be constructed to contain these.[http://www.refactoring.com/catalog/extractSubclass.html Example]
**If there are pieces that multiple classes use, then a superclass can be constructed to handle these generic functions, leaving the subclasses to deal with the remaining differences [http://www.refactoring.com/catalog/extractSuperclass.html Example]

===Improving Readability and Clarity===
Many times, refactoring can be used to do simple, yet necessary changes like renaming variables, methods, or classes. As features get added to a project, classes tend to get charged with more uses than originally planned, so sometimes, the original naming scheme no longer applies and a new one needs to be instilled.

Moving methods and parameters around to where they have the best accessibility also has its uses. Classes also tend to be promoted or demoted to super and sub classes after their ultimate functional purpose is determined.

===More Techniques===
There is an extensive list of coding smells that can be improved through refactoring.

A description of smells with their techniques exists [http://ghendry.net/refactor.html here].

A list of techniques with examples in Ruby are listed [http://www.refactoring.com/catalog/index.html here].

==Metrics==
It can be hard to decide whether or not to refactor, especially when it’s for something that appears to be working fine with just a surface level smell. Program analysis tools are used to derive various types of code metrics, which allow coders to identify problem areas and future pitfalls of their code base. These tools look at the code in several different ways, including the number of times a source file has been edited to help determine if it is a possible target of [feature envy], duplicate code structure to identify replicated lines, and block depths to suggest possible complexity issues.

===Open Source Ruby Metric Tools===
There are a variety of open source code metric tools that can be employed specifically for Ruby programs. [https://www.ruby-toolbox.com/categories/code_metrics The Ruby Toolbox] contains the most popular of these tools along with ratings.

[http://rubydoc.info/gems/simplecov/frames Simple Cov] is at the top of this list. It was developed specifically to be of use to anyone using any framework. It integrates itself with the project’s own test cases to check the code coverage of them in addition to cucumber features.

===Code Climate===
[https://codeclimate.com Code Climate] is a hosted code metrics tool that analyzes projects in a multitdue of ways. It produces three main metric ratings with grades from A-F that comprise of the methods and classes contained in each file and project.
#Complexity Metric - This is based off of the Assignment, Branches, and Conditions ([http://c2.com/cgi/wiki?AbcMetric ABC]) metric, where the number of assignments, branches, and conditions are counted and analyzed. However, because Code Climate is constructed for Ruby programs, it also takes into account certain types of Ruby constructs that may increase the metric score, but are actually beneficial to the project.
#Duplication Metric - This looks at the syntax trees of the code in order to identify identical and similar code structures. Because the syntax trees are being analyzed, code formatting and different method and class names do not affect the score. <ref>https://codeclimate.com/docs#quality-metrics</ref>
#Churn Method - This integrates with the Git repository to look at the change history of the project’s files. Files with excessively high change histories have a tendency to have a high complexity rating as well, as they can be the result of feature envy, where extra functions are added into a file instead of being added to a new file with it’s own functionality.

==Getting Started with Refactoring in Ruby==

===First step: Writing tests===
The first step in refactoring is writing solid set of tests for the section of code under consideration, in order to avoid introducing bugs. In Ruby, this can be done using [http://www.ruby-doc.org/stdlib-2.1.0/libdoc/test/unit/rdoc/Test/Unit.html Test::Unit] or [http://rspec.info/ Rspec]. Next step is to make small changes, test, make small changes, test again and so on<ref name='Refactoring Ruby Edition'>http://www.amazon.com/Refactoring-Edition-Addison-Wesley-Professional-Series/dp/0321984137</ref>. This ensures that we can revert back to the working version of code if any small refactoring causes the application to stop working.

===When to refactor===
It is always confusing when to start refactoring. If either one of the following conditions is true, it is a good time to start refactoring code<ref name='Refactoring Ruby Edition'/>:
* The Rule of Three - If any code segment gives trouble more than two times, it is time to refactor it
* Adding new function - It might be helpful to refactor when adding new functionality as it would give better understanding of code. Sometimes, revisiting old design might help to accommodate new features better
* Fixing a bug - It is useful to refactor code which had a bug; this might save bug reports from the same piece of code in future
* During code review - Refactoring is useful during code reviews as it can be applied immediately making code reviews more fruitful
* Understanding other's code - If a new member joins the team and is asked to refactor existing code, it helps them to get a better understanding of the code base. It might take extra time to get them started, but trying to refactor will help them contribute to the project better in the long run.

A [http://blog.codeclimate.com/blog/2014/01/09/when-is-it-time-to-refactor/ CodeClimate blog] suggests some other conditions to decide when to refactor code.

==Automated Code Refactoring==
=== RubyMine ===
*[http://www.jetbrains.com/ruby/webhelp/refactoring.html RubyMine] has a built in refactoring menu.
*To perform refactoring, select a code fragment to refactor. Refactorings available for your selection appear under the Refactor Menu in RubyMine. <ref>http://www.jetbrains.com/ruby/webhelp/refactoring-source-code.html#common</ref> [[File:RubyMine_refactoring_menu.png]]

===RFactor ===
*[http://fabiokung.com/2009/02/04/rfactor-ruby-refactoring-for-your-loved-editor/ RFactor] is a Ruby gem, which aims to provide common and simple refactorings for Ruby code for text editors like TextMate
*The first release has only Extract method implemented while other refactorings are coming soon
*It is available on [http://github.com/fabiokung/rfactor-tmbundle/tree/master GitHub]

=== Other IDEs ===
*Some other IDEs with built-in refactoring include [http://www.aptana.com/products/studio3 Aptana Studio], [http://www.aptana.com/products/radrails Aptana RadRails] and [https://netbeans.org/features/ruby/index.html NetBeans 7] (which requires Ruby and Rails [http://plugins.netbeans.org/plugin/38549 plugin])
*A StackOverflow [http://stackoverflow.com/questions/8705144/ide-with-refactoring-support-for-ruby-on-rails post] compares these tools ranking them as RubyMine being the best, followed by NetBeans, RadRails 2 and Aptana Studio 3

==Further Reading==
*[http://en.wikipedia.org/wiki/Code_smell Ways to identify problems in code]

*[http://blog.codeclimate.com/blog/2012/11/14/why-ruby-class-methods-resist-refactoring/ Resistance With Refactoring Ruby Class Methods]

*[http://www.railsinside.com/uncategorized/460-the-first-step-of-refactoring-a-rails-application.html Refactoring a Rails Application]

*[http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ Refactoring Fat Models]

*[https://speakerdeck.com/brianvh/refactoring-views-in-rails Talk on Refactoring Fat Views]

*[http://www.amazon.com/Rails-AntiPatterns-Refactoring-Addison-Wesley-Professional/dp/0321604814 Rails AntiPatterns: Best Practice Ruby on Rails Refactoring]

==References==
<references/>

CSC/ECE 517 Spring 2014

2014-02-12T05:31:16Z

Rjlloyd:

*[[CSC/ECE_517_Fall_2012/example_page]]
*[[CSC/ECE 517 Spring 2014/ch1 1w1e rm]]
*[[CSC/ECE 517 Spring 2014/ch1 1w1h jg ]]
*[[CSC/ECE 517 Spring 2014/ch1 1w1b np]]
*[[CSC/ECE 517 Spring 2014/ch1 1w1f mj]]
*[[CSC/ECE 517 Spring 2014/ch1a 1d mm]]
*[[CSC/ECE 517 Spring 2014/ch1a 1c yj]]

CSC/ECE 517 Spring 2014

2014-02-12T05:31:02Z

Rjlloyd:

CSC/ECE 517 Spring 2014/ch1a 1w1e rm

2014-02-11T01:31:13Z

Rjlloyd: /* Code Climate */

This page discusses refactoring techniques and metrics. It also includes tips on refactoring in Ruby and list of tools for automated refactoring.

==Background==

The idea behind [http://en.wikipedia.org/wiki/Code_refactoring code refactoring] is to take a code base and improve it's readability, [http://en.wikipedia.org/wiki/Extensibility extensibility], and [http://en.wikipedia.org/wiki/Reusability reusability]. The practice is focused on having a better quality and more standardized code base, and not on fixing bugs or changing functionality.

Refactoring has its difficulties, whether or not it is done using an [http://en.wikipedia.org/wiki/Integrated_development_environment IDE] or whether it is done by hand. There are lots of pitfalls and errors that can be made during refactoring, so it is pertinent to determine how important a refactor is to the code. Code metrics are one method used to determine how badly a file needs refactoring.

==Refactoring Techniques==
Before a coder performs a refactor, they must, either formally or informally, identify their ‘code smells’. A code smell refers to a negative quality of a code base that either implements bad programming practices or slows down code development or runtime. These aren't typically bugs, but can increase the chance of bugs later on if not fixed. Based on the type of code smell, a different refactoring technique is used to fix it.

===Duplicate Code===
Duplicate code can be a tricky concept when refactoring. Large sections of duplicated code can be easy to find and fixed by pulling it out and creating a single centralized method to call, however it is usually not that easy. Sometimes it may only be one or two lines of code that are duplicated which calls for an assessment of whether or not it is in the best interest to create a new method for a couple lines of code. Other times, code is not duplicate, rather it is similar enough that a generic method could be created to serve various purposes.
Some specific techniques to deal with this are:
*Extract Method / Pull-up Method
**If common code is used in multiple places, simply pull it out and make a method that can be called from all of the necessary places. Variables can be passed in if slight variations are needed between calls.
**If the code is used in various subclasses, put the common code in a method in the superclass, so that it can be seen and called by it’s children.
**[http://www.refactoring.com/catalog/extractMethod.html Extract Method Example]

*Form Template Method
**If two methods in subclasses perform similar steps in the same order, but the steps are different, then get the steps into methods with the same signature, so that the original methods become the same. Then pull them up. <ref>http://www.refactoring.com/catalog/formTemplateMethod.html</ref>
**[http://www.integralist.co.uk/posts/refactoring-techniques/#form-template-method Form Template Method Example]

===Large Method/Class===
If a project is not planned out well enough in advance, it is easy for methods and classes to become populated with excess functionality. While functionality of a block of code may be necessary for the project, the code block might not really pertain to the method or class it is included in.
*Extract Method
**This can be used when duplicate code occurs, as discussed above. But it can also be used when a method performs multiple functions that have the ability to be split up into various functions that serve a single purpose.
*Extract Class/Subclass/Superclass
**If there are class variables or methods that don’t directly pertain to a class, then it may be necessary to create a new class for those pieces.[http://www.refactoring.com/catalog/extractClass.html Example]
**If there are pieces of a class that are only for a specific subset of instances, then a subclass can be constructed to contain these.[http://www.refactoring.com/catalog/extractSubclass.html Example]
**If there are pieces that multiple classes use, then a superclass can be constructed to handle these generic functions, leaving the subclasses to deal with the remaining differences [http://www.refactoring.com/catalog/extractSuperclass.html Example]

===Improving Readability and Clarity===
Many times, refactoring can be used to do simple, yet necessary changes like renaming variables, methods, or classes. As features get added to a project, classes tend to get charged with more uses than originally planned, so sometimes, the original naming scheme no longer applies and a new one needs to be instilled.

Moving methods and parameters around to where they have the best accessibility also has its uses. Classes also tend to be promoted or demoted to super and sub classes after their ultimate functional purpose is determined.

===More Techniques===
There is an extensive list of coding smells that can be improved through refactoring.

A description of smells with their techniques exists [http://ghendry.net/refactor.html here].

A list of techniques with examples in Ruby are listed [http://www.refactoring.com/catalog/index.html here].

==Metrics==
It can be hard to decide whether or not to refactor, especially when it’s for something that appears to be working fine with just a surface level smell. Program analysis tools are used to derive various types of code metrics, which allow coders to identify problem areas and future pitfalls of their code base. These tools look at the code in several different ways, including the number of times a source file has been edited to help determine if it is a possible target of [feature envy], duplicate code structure to identify replicated lines, and block depths to suggest possible complexity issues.

===Open Source Ruby Metric Tools===
There are a variety of open source code metric tools that can be employed specifically for Ruby programs. [https://www.ruby-toolbox.com/categories/code_metrics The Ruby Toolbox] contains the most popular of these tools along with ratings.

[http://rubydoc.info/gems/simplecov/frames Simple Cov] is at the top of this list. It was developed specifically to be of use to anyone using any framework. It integrates itself with the project’s own test cases to check the code coverage of them in addition to cucumber features.

===Code Climate===
[https://codeclimate.com Code Climate] is a hosted code metrics tool that analyzes projects in a multitdue of ways. It produces three main metric ratings with grades from A-F that comprise of the methods and classes contained in each file and project.
*Complexity Metric
This is based off of the Assignment, Branches, and Conditions ([http://c2.com/cgi/wiki?AbcMetric ABC]) metric, where the number of assignments, branches, and conditions are counted and analyzed. However, because Code Climate is constructed for Ruby programs, it also takes into account certain types of Ruby constructs that may increase the metric score, but are actually beneficial to the project.
*Duplication Metric
This looks at the syntax trees of the code in order to identify identical and similar code structures. Because the syntax trees are being analyzed, code formatting and different method and class names do not affect the score. <ref>https://codeclimate.com/docs#quality-metrics</ref>
*Churn Method
This integrates with the Git repository to look at the change history of the project’s files. Files with excessively high change histories have a tendency to have a high complexity rating as well, as they can be the result of feature envy, where extra functions are added into a file instead of being added to a new file with it’s own functionality.

==Getting Started with Refactoring in Ruby==

===First step: Writing tests===
The first step in refactoring is writing solid set of tests for the section of code under consideration, in order to avoid introducing bugs. In Ruby, this can be done using [http://www.ruby-doc.org/stdlib-2.1.0/libdoc/test/unit/rdoc/Test/Unit.html Test::Unit] or [http://rspec.info/ Rspec]. Next step is to make small changes, test, make small changes, test again and so on<ref name='Refactoring Ruby Edition'>http://www.amazon.com/Refactoring-Edition-Addison-Wesley-Professional-Series/dp/0321984137</ref>. This ensures that we can revert back to the working version of code if any small refactoring causes the application to stop working.

===When to refactor===
It is always confusing when to start refactoring. If either one of the following conditions is true, it is a good time to start refactoring code<ref name='Refactoring Ruby Edition'/>:
* The Rule of Three - If any code segment gives trouble more than two times, it is time to refactor it
* Adding new function - It might be helpful to refactor when adding new functionality as it would give better understanding of code. Sometimes, revisiting old design might help to accommodate new features better
* Fixing a bug - It is useful to refactor code which had a bug; this might save bug reports from the same piece of code in future
* During code review - Refactoring is useful during code reviews as it can be applied immediately making code reviews more fruitful
* Understanding other's code - If a new member joins the team and is asked to refactor existing code, it helps them to get a better understanding of the code base. It might take extra time to get them started, but trying to refactor will help them contribute to the project better in the long run.

A [http://blog.codeclimate.com/blog/2014/01/09/when-is-it-time-to-refactor/ CodeClimate blog] suggests some other conditions to decide when to refactor code.

==Automated Code Refactoring==
=== RubyMine ===
*[http://www.jetbrains.com/ruby/webhelp/refactoring.html RubyMine] has a built in refactoring menu.
*To perform refactoring, select a code fragment to refactor. Refactorings available for your selection appear under the Refactor Menu in RubyMine. <ref>http://www.jetbrains.com/ruby/webhelp/refactoring-source-code.html#common</ref> [[File:RubyMine_refactoring_menu.png]]

===RFactor ===
*[http://fabiokung.com/2009/02/04/rfactor-ruby-refactoring-for-your-loved-editor/ RFactor] is a Ruby gem, which aims to provide common and simple refactorings for Ruby code for text editors like TextMate
*The first release has only Extract method implemented while other refactorings are coming soon
*It is available on [http://github.com/fabiokung/rfactor-tmbundle/tree/master GitHub]

=== Other IDEs ===
*Some other IDEs with built-in refactoring include [http://www.aptana.com/products/studio3 Aptana Studio], [http://www.aptana.com/products/radrails Aptana RadRails] and [https://netbeans.org/features/ruby/index.html NetBeans 7] (which requires Ruby and Rails [http://plugins.netbeans.org/plugin/38549 plugin])
*A StackOverflow [http://stackoverflow.com/questions/8705144/ide-with-refactoring-support-for-ruby-on-rails post] compares these tools ranking them as RubyMine being the best, followed by NetBeans, RadRails 2 and Aptana Studio 3

==Further Reading==
*[http://en.wikipedia.org/wiki/Code_smell Ways to identify problems in code]

*[http://blog.codeclimate.com/blog/2012/11/14/why-ruby-class-methods-resist-refactoring/ Resistance With Refactoring Ruby Class Methods]

*[http://www.railsinside.com/uncategorized/460-the-first-step-of-refactoring-a-rails-application.html Refactoring a Rails Application]

*[http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ Refactoring Fat Models]

*[https://speakerdeck.com/brianvh/refactoring-views-in-rails Talk on Refactoring Fat Views]

*[http://www.amazon.com/Rails-AntiPatterns-Refactoring-Addison-Wesley-Professional/dp/0321604814 Rails AntiPatterns: Best Practice Ruby on Rails Refactoring]

==References==
<references/>

CSC/ECE 517 Spring 2014/ch1a 1w1e rm

2014-02-11T01:26:22Z

Rjlloyd: /* Refactoring views */

This page discusses refactoring techniques and metrics. It also includes tips on refactoring in Ruby and list of tools for automated refactoring.

==Background==

The idea behind [http://en.wikipedia.org/wiki/Code_refactoring code refactoring] is to take a code base and improve it's readability, [http://en.wikipedia.org/wiki/Extensibility extensibility], and [http://en.wikipedia.org/wiki/Reusability reusability]. The practice is focused on having a better quality and more standardized code base, and not on fixing bugs or changing functionality.

Refactoring has its difficulties, whether or not it is done using an [http://en.wikipedia.org/wiki/Integrated_development_environment IDE] or whether it is done by hand. There are lots of pitfalls and errors that can be made during refactoring, so it is pertinent to determine how important a refactor is to the code. Code metrics are one method used to determine how badly a file needs refactoring.

==Refactoring Techniques==
Before a coder performs a refactor, they must, either formally or informally, identify their ‘code smells’. A code smell refers to a negative quality of a code base that either implements bad programming practices or slows down code development or runtime. These aren't typically bugs, but can increase the chance of bugs later on if not fixed. Based on the type of code smell, a different refactoring technique is used to fix it.

===Duplicate Code===
Duplicate code can be a tricky concept when refactoring. Large sections of duplicated code can be easy to find and fixed by pulling it out and creating a single centralized method to call, however it is usually not that easy. Sometimes it may only be one or two lines of code that are duplicated which calls for an assessment of whether or not it is in the best interest to create a new method for a couple lines of code. Other times, code is not duplicate, rather it is similar enough that a generic method could be created to serve various purposes.
Some specific techniques to deal with this are:
*Extract Method / Pull-up Method
**If common code is used in multiple places, simply pull it out and make a method that can be called from all of the necessary places. Variables can be passed in if slight variations are needed between calls.
**If the code is used in various subclasses, put the common code in a method in the superclass, so that it can be seen and called by it’s children.
**[http://www.refactoring.com/catalog/extractMethod.html Extract Method Example]

*Form Template Method
**If two methods in subclasses perform similar steps in the same order, but the steps are different, then get the steps into methods with the same signature, so that the original methods become the same. Then pull them up. <ref>http://www.refactoring.com/catalog/formTemplateMethod.html</ref>
**[http://www.integralist.co.uk/posts/refactoring-techniques/#form-template-method Form Template Method Example]

===Large Method/Class===
If a project is not planned out well enough in advance, it is easy for methods and classes to become populated with excess functionality. While functionality of a block of code may be necessary for the project, the code block might not really pertain to the method or class it is included in.
*Extract Method
**This can be used when duplicate code occurs, as discussed above. But it can also be used when a method performs multiple functions that have the ability to be split up into various functions that serve a single purpose.
*Extract Class/Subclass/Superclass
**If there are class variables or methods that don’t directly pertain to a class, then it may be necessary to create a new class for those pieces.[http://www.refactoring.com/catalog/extractClass.html Example]
**If there are pieces of a class that are only for a specific subset of instances, then a subclass can be constructed to contain these.[http://www.refactoring.com/catalog/extractSubclass.html Example]
**If there are pieces that multiple classes use, then a superclass can be constructed to handle these generic functions, leaving the subclasses to deal with the remaining differences [http://www.refactoring.com/catalog/extractSuperclass.html Example]

===Improving Readability and Clarity===
Many times, refactoring can be used to do simple, yet necessary changes like renaming variables, methods, or classes. As features get added to a project, classes tend to get charged with more uses than originally planned, so sometimes, the original naming scheme no longer applies and a new one needs to be instilled.

Moving methods and parameters around to where they have the best accessibility also has its uses. Classes also tend to be promoted or demoted to super and sub classes after their ultimate functional purpose is determined.

===More Techniques===
There is an extensive list of coding smells that can be improved through refactoring.

A description of smells with their techniques exists [http://ghendry.net/refactor.html here].

A list of techniques with examples in Ruby are listed [http://www.refactoring.com/catalog/index.html here].

==Metrics==
It can be hard to decide whether or not to refactor, especially when it’s for something that appears to be working fine with just a surface level smell. Program analysis tools are used to derive various types of code metrics, which allow coders to identify problem areas and future pitfalls of their code base. These tools look at the code in several different ways, including the number of times a source file has been edited to help determine if it is a possible target of [feature envy], duplicate code structure to identify replicated lines, and block depths to suggest possible complexity issues.

===Open Source Ruby Metric Tools===
There are a variety of open source code metric tools that can be employed specifically for Ruby programs. [https://www.ruby-toolbox.com/categories/code_metrics The Ruby Toolbox] contains the most popular of these tools along with ratings.

[http://rubydoc.info/gems/simplecov/frames Simple Cov] is at the top of this list. It was developed specifically to be of use to anyone using any framework. It integrates itself with the project’s own test cases to check the code coverage of them in addition to cucumber features.

===Code Climate===
[https://codeclimate.com Code Climate] is a hosted code metrics tool that analyzes projects in a multitdue of ways. It produces three main metric ratings with grades from A-F that comprise of the methods and classes contained in each file and project.
====Complexity Metric====
This is based off of the Assignment, Branches, and Conditions ([http://c2.com/cgi/wiki?AbcMetric ABC]) metric, where the number of assignments, branches, and conditions are counted and analyzed. However, because Code Climate is constructed for Ruby programs, it also takes into account certain types of Ruby constructs that may increase the metric score, but are actually beneficial to the project.
====Duplication Metric====
This looks at the syntax trees of the code in order to identify identical and similar code structures. Because the syntax trees are being analyzed, code formatting and different method and class names do not affect the score. <ref>https://codeclimate.com/docs#quality-metrics</ref>

====Churn Method====
This integrates with the Git repository to look at the change history of the project’s files. Files with excessively high change histories have a tendency to have a high complexity rating as well, as they can be the result of feature envy, where extra functions are added into a file instead of being added to a new file with it’s own functionality.

==Getting Started with Refactoring in Ruby==

===First step: Writing tests===
The first step in refactoring is writing solid set of tests for the section of code under consideration, in order to avoid introducing bugs. In Ruby, this can be done using [http://www.ruby-doc.org/stdlib-2.1.0/libdoc/test/unit/rdoc/Test/Unit.html Test::Unit] or [http://rspec.info/ Rspec]. Next step is to make small changes, test, make small changes, test again and so on<ref name='Refactoring Ruby Edition'>http://www.amazon.com/Refactoring-Edition-Addison-Wesley-Professional-Series/dp/0321984137</ref>. This ensures that we can revert back to the working version of code if any small refactoring causes the application to stop working.

===When to refactor===
It is always confusing when to start refactoring. If either one of the following conditions is true, it is a good time to start refactoring code<ref name='Refactoring Ruby Edition'/>:
* The Rule of Three - If any code segment gives trouble more than two times, it is time to refactor it
* Adding new function - It might be helpful to refactor when adding new functionality as it would give better understanding of code. Sometimes, revisiting old design might help to accommodate new features better
* Fixing a bug - It is useful to refactor code which had a bug; this might save bug reports from the same piece of code in future
* During code review - Refactoring is useful during code reviews as it can be applied immediately making code reviews more fruitful
* Understanding other's code - If a new member joins the team and is asked to refactor existing code, it helps them to get a better understanding of the code base. It might take extra time to get them started, but trying to refactor will help them contribute to the project better in the long run.

A [http://blog.codeclimate.com/blog/2014/01/09/when-is-it-time-to-refactor/ CodeClimate blog] suggests some other conditions to decide when to refactor code.

==Automated Code Refactoring==
=== RubyMine ===
*[http://www.jetbrains.com/ruby/webhelp/refactoring.html RubyMine] has a built in refactoring menu.
*To perform refactoring, select a code fragment to refactor. Refactorings available for your selection appear under the Refactor Menu in RubyMine. <ref>http://www.jetbrains.com/ruby/webhelp/refactoring-source-code.html#common</ref> [[File:RubyMine_refactoring_menu.png]]

===RFactor ===
*[http://fabiokung.com/2009/02/04/rfactor-ruby-refactoring-for-your-loved-editor/ RFactor] is a Ruby gem, which aims to provide common and simple refactorings for Ruby code for text editors like TextMate
*The first release has only Extract method implemented while other refactorings are coming soon
*It is available on [http://github.com/fabiokung/rfactor-tmbundle/tree/master GitHub]

=== Other IDEs ===
*Some other IDEs with built-in refactoring include [http://www.aptana.com/products/studio3 Aptana Studio], [http://www.aptana.com/products/radrails Aptana RadRails] and [https://netbeans.org/features/ruby/index.html NetBeans 7] (which requires Ruby and Rails [http://plugins.netbeans.org/plugin/38549 plugin])
*A StackOverflow [http://stackoverflow.com/questions/8705144/ide-with-refactoring-support-for-ruby-on-rails post] compares these tools ranking them as RubyMine being the best, followed by NetBeans, RadRails 2 and Aptana Studio 3

==Further Reading==
*[http://en.wikipedia.org/wiki/Code_smell Ways to identify problems in code]

*[http://blog.codeclimate.com/blog/2012/11/14/why-ruby-class-methods-resist-refactoring/ Resistance With Refactoring Ruby Class Methods]

*[http://www.railsinside.com/uncategorized/460-the-first-step-of-refactoring-a-rails-application.html Refactoring a Rails Application]

*[http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ Refactoring Fat Models]

*[https://speakerdeck.com/brianvh/refactoring-views-in-rails Talk on Refactoring Fat Views]

*[http://www.amazon.com/Rails-AntiPatterns-Refactoring-Addison-Wesley-Professional/dp/0321604814 Rails AntiPatterns: Best Practice Ruby on Rails Refactoring]

==References==
<references/>

CSC/ECE 517 Spring 2014/ch1a 1w1e rm

2014-02-11T01:26:10Z

Rjlloyd: /* Refactoring fat models */

This page discusses refactoring techniques and metrics. It also includes tips on refactoring in Ruby and list of tools for automated refactoring.

==Background==

The idea behind [http://en.wikipedia.org/wiki/Code_refactoring code refactoring] is to take a code base and improve it's readability, [http://en.wikipedia.org/wiki/Extensibility extensibility], and [http://en.wikipedia.org/wiki/Reusability reusability]. The practice is focused on having a better quality and more standardized code base, and not on fixing bugs or changing functionality.

Refactoring has its difficulties, whether or not it is done using an [http://en.wikipedia.org/wiki/Integrated_development_environment IDE] or whether it is done by hand. There are lots of pitfalls and errors that can be made during refactoring, so it is pertinent to determine how important a refactor is to the code. Code metrics are one method used to determine how badly a file needs refactoring.

==Refactoring Techniques==
Before a coder performs a refactor, they must, either formally or informally, identify their ‘code smells’. A code smell refers to a negative quality of a code base that either implements bad programming practices or slows down code development or runtime. These aren't typically bugs, but can increase the chance of bugs later on if not fixed. Based on the type of code smell, a different refactoring technique is used to fix it.

===Duplicate Code===
Duplicate code can be a tricky concept when refactoring. Large sections of duplicated code can be easy to find and fixed by pulling it out and creating a single centralized method to call, however it is usually not that easy. Sometimes it may only be one or two lines of code that are duplicated which calls for an assessment of whether or not it is in the best interest to create a new method for a couple lines of code. Other times, code is not duplicate, rather it is similar enough that a generic method could be created to serve various purposes.
Some specific techniques to deal with this are:
*Extract Method / Pull-up Method
**If common code is used in multiple places, simply pull it out and make a method that can be called from all of the necessary places. Variables can be passed in if slight variations are needed between calls.
**If the code is used in various subclasses, put the common code in a method in the superclass, so that it can be seen and called by it’s children.
**[http://www.refactoring.com/catalog/extractMethod.html Extract Method Example]

*Form Template Method
**If two methods in subclasses perform similar steps in the same order, but the steps are different, then get the steps into methods with the same signature, so that the original methods become the same. Then pull them up. <ref>http://www.refactoring.com/catalog/formTemplateMethod.html</ref>
**[http://www.integralist.co.uk/posts/refactoring-techniques/#form-template-method Form Template Method Example]

===Large Method/Class===
If a project is not planned out well enough in advance, it is easy for methods and classes to become populated with excess functionality. While functionality of a block of code may be necessary for the project, the code block might not really pertain to the method or class it is included in.
*Extract Method
**This can be used when duplicate code occurs, as discussed above. But it can also be used when a method performs multiple functions that have the ability to be split up into various functions that serve a single purpose.
*Extract Class/Subclass/Superclass
**If there are class variables or methods that don’t directly pertain to a class, then it may be necessary to create a new class for those pieces.[http://www.refactoring.com/catalog/extractClass.html Example]
**If there are pieces of a class that are only for a specific subset of instances, then a subclass can be constructed to contain these.[http://www.refactoring.com/catalog/extractSubclass.html Example]
**If there are pieces that multiple classes use, then a superclass can be constructed to handle these generic functions, leaving the subclasses to deal with the remaining differences [http://www.refactoring.com/catalog/extractSuperclass.html Example]

===Improving Readability and Clarity===
Many times, refactoring can be used to do simple, yet necessary changes like renaming variables, methods, or classes. As features get added to a project, classes tend to get charged with more uses than originally planned, so sometimes, the original naming scheme no longer applies and a new one needs to be instilled.

Moving methods and parameters around to where they have the best accessibility also has its uses. Classes also tend to be promoted or demoted to super and sub classes after their ultimate functional purpose is determined.

===More Techniques===
There is an extensive list of coding smells that can be improved through refactoring.

A description of smells with their techniques exists [http://ghendry.net/refactor.html here].

A list of techniques with examples in Ruby are listed [http://www.refactoring.com/catalog/index.html here].

==Metrics==
It can be hard to decide whether or not to refactor, especially when it’s for something that appears to be working fine with just a surface level smell. Program analysis tools are used to derive various types of code metrics, which allow coders to identify problem areas and future pitfalls of their code base. These tools look at the code in several different ways, including the number of times a source file has been edited to help determine if it is a possible target of [feature envy], duplicate code structure to identify replicated lines, and block depths to suggest possible complexity issues.

===Open Source Ruby Metric Tools===
There are a variety of open source code metric tools that can be employed specifically for Ruby programs. [https://www.ruby-toolbox.com/categories/code_metrics The Ruby Toolbox] contains the most popular of these tools along with ratings.

[http://rubydoc.info/gems/simplecov/frames Simple Cov] is at the top of this list. It was developed specifically to be of use to anyone using any framework. It integrates itself with the project’s own test cases to check the code coverage of them in addition to cucumber features.

===Code Climate===
[https://codeclimate.com Code Climate] is a hosted code metrics tool that analyzes projects in a multitdue of ways. It produces three main metric ratings with grades from A-F that comprise of the methods and classes contained in each file and project.
====Complexity Metric====
This is based off of the Assignment, Branches, and Conditions ([http://c2.com/cgi/wiki?AbcMetric ABC]) metric, where the number of assignments, branches, and conditions are counted and analyzed. However, because Code Climate is constructed for Ruby programs, it also takes into account certain types of Ruby constructs that may increase the metric score, but are actually beneficial to the project.
====Duplication Metric====
This looks at the syntax trees of the code in order to identify identical and similar code structures. Because the syntax trees are being analyzed, code formatting and different method and class names do not affect the score. <ref>https://codeclimate.com/docs#quality-metrics</ref>

====Churn Method====
This integrates with the Git repository to look at the change history of the project’s files. Files with excessively high change histories have a tendency to have a high complexity rating as well, as they can be the result of feature envy, where extra functions are added into a file instead of being added to a new file with it’s own functionality.

==Getting Started with Refactoring in Ruby==

===First step: Writing tests===
The first step in refactoring is writing solid set of tests for the section of code under consideration, in order to avoid introducing bugs. In Ruby, this can be done using [http://www.ruby-doc.org/stdlib-2.1.0/libdoc/test/unit/rdoc/Test/Unit.html Test::Unit] or [http://rspec.info/ Rspec]. Next step is to make small changes, test, make small changes, test again and so on<ref name='Refactoring Ruby Edition'>http://www.amazon.com/Refactoring-Edition-Addison-Wesley-Professional-Series/dp/0321984137</ref>. This ensures that we can revert back to the working version of code if any small refactoring causes the application to stop working.

===When to refactor===
It is always confusing when to start refactoring. If either one of the following conditions is true, it is a good time to start refactoring code<ref name='Refactoring Ruby Edition'/>:
* The Rule of Three - If any code segment gives trouble more than two times, it is time to refactor it
* Adding new function - It might be helpful to refactor when adding new functionality as it would give better understanding of code. Sometimes, revisiting old design might help to accommodate new features better
* Fixing a bug - It is useful to refactor code which had a bug; this might save bug reports from the same piece of code in future
* During code review - Refactoring is useful during code reviews as it can be applied immediately making code reviews more fruitful
* Understanding other's code - If a new member joins the team and is asked to refactor existing code, it helps them to get a better understanding of the code base. It might take extra time to get them started, but trying to refactor will help them contribute to the project better in the long run.

A [http://blog.codeclimate.com/blog/2014/01/09/when-is-it-time-to-refactor/ CodeClimate blog] suggests some other conditions to decide when to refactor code.

===Refactoring views===
In this [https://speakerdeck.com/brianvh/refactoring-views-in-rails talk], Brian Hughes explains use of patterns to refactor views with bad code smells like using conditionals or formatting data.

==Automated Code Refactoring==
=== RubyMine ===
*[http://www.jetbrains.com/ruby/webhelp/refactoring.html RubyMine] has a built in refactoring menu.
*To perform refactoring, select a code fragment to refactor. Refactorings available for your selection appear under the Refactor Menu in RubyMine. <ref>http://www.jetbrains.com/ruby/webhelp/refactoring-source-code.html#common</ref> [[File:RubyMine_refactoring_menu.png]]

===RFactor ===
*[http://fabiokung.com/2009/02/04/rfactor-ruby-refactoring-for-your-loved-editor/ RFactor] is a Ruby gem, which aims to provide common and simple refactorings for Ruby code for text editors like TextMate
*The first release has only Extract method implemented while other refactorings are coming soon
*It is available on [http://github.com/fabiokung/rfactor-tmbundle/tree/master GitHub]

=== Other IDEs ===
*Some other IDEs with built-in refactoring include [http://www.aptana.com/products/studio3 Aptana Studio], [http://www.aptana.com/products/radrails Aptana RadRails] and [https://netbeans.org/features/ruby/index.html NetBeans 7] (which requires Ruby and Rails [http://plugins.netbeans.org/plugin/38549 plugin])
*A StackOverflow [http://stackoverflow.com/questions/8705144/ide-with-refactoring-support-for-ruby-on-rails post] compares these tools ranking them as RubyMine being the best, followed by NetBeans, RadRails 2 and Aptana Studio 3

==Further Reading==
*[http://en.wikipedia.org/wiki/Code_smell Ways to identify problems in code]

*[http://blog.codeclimate.com/blog/2012/11/14/why-ruby-class-methods-resist-refactoring/ Resistance With Refactoring Ruby Class Methods]

*[http://www.railsinside.com/uncategorized/460-the-first-step-of-refactoring-a-rails-application.html Refactoring a Rails Application]

*[http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ Refactoring Fat Models]

*[https://speakerdeck.com/brianvh/refactoring-views-in-rails Talk on Refactoring Fat Views]

*[http://www.amazon.com/Rails-AntiPatterns-Refactoring-Addison-Wesley-Professional/dp/0321604814 Rails AntiPatterns: Best Practice Ruby on Rails Refactoring]

==References==
<references/>

CSC/ECE 517 Spring 2014/ch1a 1w1e rm

2014-02-11T01:25:59Z

Rjlloyd: /* Further Reading */

This page discusses refactoring techniques and metrics. It also includes tips on refactoring in Ruby and list of tools for automated refactoring.

==Background==

The idea behind [http://en.wikipedia.org/wiki/Code_refactoring code refactoring] is to take a code base and improve it's readability, [http://en.wikipedia.org/wiki/Extensibility extensibility], and [http://en.wikipedia.org/wiki/Reusability reusability]. The practice is focused on having a better quality and more standardized code base, and not on fixing bugs or changing functionality.

Refactoring has its difficulties, whether or not it is done using an [http://en.wikipedia.org/wiki/Integrated_development_environment IDE] or whether it is done by hand. There are lots of pitfalls and errors that can be made during refactoring, so it is pertinent to determine how important a refactor is to the code. Code metrics are one method used to determine how badly a file needs refactoring.

==Refactoring Techniques==
Before a coder performs a refactor, they must, either formally or informally, identify their ‘code smells’. A code smell refers to a negative quality of a code base that either implements bad programming practices or slows down code development or runtime. These aren't typically bugs, but can increase the chance of bugs later on if not fixed. Based on the type of code smell, a different refactoring technique is used to fix it.

===Duplicate Code===
Duplicate code can be a tricky concept when refactoring. Large sections of duplicated code can be easy to find and fixed by pulling it out and creating a single centralized method to call, however it is usually not that easy. Sometimes it may only be one or two lines of code that are duplicated which calls for an assessment of whether or not it is in the best interest to create a new method for a couple lines of code. Other times, code is not duplicate, rather it is similar enough that a generic method could be created to serve various purposes.
Some specific techniques to deal with this are:
*Extract Method / Pull-up Method
**If common code is used in multiple places, simply pull it out and make a method that can be called from all of the necessary places. Variables can be passed in if slight variations are needed between calls.
**If the code is used in various subclasses, put the common code in a method in the superclass, so that it can be seen and called by it’s children.
**[http://www.refactoring.com/catalog/extractMethod.html Extract Method Example]

*Form Template Method
**If two methods in subclasses perform similar steps in the same order, but the steps are different, then get the steps into methods with the same signature, so that the original methods become the same. Then pull them up. <ref>http://www.refactoring.com/catalog/formTemplateMethod.html</ref>
**[http://www.integralist.co.uk/posts/refactoring-techniques/#form-template-method Form Template Method Example]

===Large Method/Class===
If a project is not planned out well enough in advance, it is easy for methods and classes to become populated with excess functionality. While functionality of a block of code may be necessary for the project, the code block might not really pertain to the method or class it is included in.
*Extract Method
**This can be used when duplicate code occurs, as discussed above. But it can also be used when a method performs multiple functions that have the ability to be split up into various functions that serve a single purpose.
*Extract Class/Subclass/Superclass
**If there are class variables or methods that don’t directly pertain to a class, then it may be necessary to create a new class for those pieces.[http://www.refactoring.com/catalog/extractClass.html Example]
**If there are pieces of a class that are only for a specific subset of instances, then a subclass can be constructed to contain these.[http://www.refactoring.com/catalog/extractSubclass.html Example]
**If there are pieces that multiple classes use, then a superclass can be constructed to handle these generic functions, leaving the subclasses to deal with the remaining differences [http://www.refactoring.com/catalog/extractSuperclass.html Example]

===Improving Readability and Clarity===
Many times, refactoring can be used to do simple, yet necessary changes like renaming variables, methods, or classes. As features get added to a project, classes tend to get charged with more uses than originally planned, so sometimes, the original naming scheme no longer applies and a new one needs to be instilled.

Moving methods and parameters around to where they have the best accessibility also has its uses. Classes also tend to be promoted or demoted to super and sub classes after their ultimate functional purpose is determined.

===More Techniques===
There is an extensive list of coding smells that can be improved through refactoring.

A description of smells with their techniques exists [http://ghendry.net/refactor.html here].

A list of techniques with examples in Ruby are listed [http://www.refactoring.com/catalog/index.html here].

==Metrics==
It can be hard to decide whether or not to refactor, especially when it’s for something that appears to be working fine with just a surface level smell. Program analysis tools are used to derive various types of code metrics, which allow coders to identify problem areas and future pitfalls of their code base. These tools look at the code in several different ways, including the number of times a source file has been edited to help determine if it is a possible target of [feature envy], duplicate code structure to identify replicated lines, and block depths to suggest possible complexity issues.

===Open Source Ruby Metric Tools===
There are a variety of open source code metric tools that can be employed specifically for Ruby programs. [https://www.ruby-toolbox.com/categories/code_metrics The Ruby Toolbox] contains the most popular of these tools along with ratings.

[http://rubydoc.info/gems/simplecov/frames Simple Cov] is at the top of this list. It was developed specifically to be of use to anyone using any framework. It integrates itself with the project’s own test cases to check the code coverage of them in addition to cucumber features.

===Code Climate===
[https://codeclimate.com Code Climate] is a hosted code metrics tool that analyzes projects in a multitdue of ways. It produces three main metric ratings with grades from A-F that comprise of the methods and classes contained in each file and project.
====Complexity Metric====
This is based off of the Assignment, Branches, and Conditions ([http://c2.com/cgi/wiki?AbcMetric ABC]) metric, where the number of assignments, branches, and conditions are counted and analyzed. However, because Code Climate is constructed for Ruby programs, it also takes into account certain types of Ruby constructs that may increase the metric score, but are actually beneficial to the project.
====Duplication Metric====
This looks at the syntax trees of the code in order to identify identical and similar code structures. Because the syntax trees are being analyzed, code formatting and different method and class names do not affect the score. <ref>https://codeclimate.com/docs#quality-metrics</ref>

====Churn Method====
This integrates with the Git repository to look at the change history of the project’s files. Files with excessively high change histories have a tendency to have a high complexity rating as well, as they can be the result of feature envy, where extra functions are added into a file instead of being added to a new file with it’s own functionality.

==Getting Started with Refactoring in Ruby==

===First step: Writing tests===
The first step in refactoring is writing solid set of tests for the section of code under consideration, in order to avoid introducing bugs. In Ruby, this can be done using [http://www.ruby-doc.org/stdlib-2.1.0/libdoc/test/unit/rdoc/Test/Unit.html Test::Unit] or [http://rspec.info/ Rspec]. Next step is to make small changes, test, make small changes, test again and so on<ref name='Refactoring Ruby Edition'>http://www.amazon.com/Refactoring-Edition-Addison-Wesley-Professional-Series/dp/0321984137</ref>. This ensures that we can revert back to the working version of code if any small refactoring causes the application to stop working.

===When to refactor===
It is always confusing when to start refactoring. If either one of the following conditions is true, it is a good time to start refactoring code<ref name='Refactoring Ruby Edition'/>:
* The Rule of Three - If any code segment gives trouble more than two times, it is time to refactor it
* Adding new function - It might be helpful to refactor when adding new functionality as it would give better understanding of code. Sometimes, revisiting old design might help to accommodate new features better
* Fixing a bug - It is useful to refactor code which had a bug; this might save bug reports from the same piece of code in future
* During code review - Refactoring is useful during code reviews as it can be applied immediately making code reviews more fruitful
* Understanding other's code - If a new member joins the team and is asked to refactor existing code, it helps them to get a better understanding of the code base. It might take extra time to get them started, but trying to refactor will help them contribute to the project better in the long run.

A [http://blog.codeclimate.com/blog/2014/01/09/when-is-it-time-to-refactor/ CodeClimate blog] suggests some other conditions to decide when to refactor code.

===Refactoring fat models===
As more features get added to the application, the models tend to become bulkier. Such fat models cause maintenance issues. Refer to [http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ CodeClimate blog] for 7 patterns to refactor such fat models.

===Refactoring views===
In this [https://speakerdeck.com/brianvh/refactoring-views-in-rails talk], Brian Hughes explains use of patterns to refactor views with bad code smells like using conditionals or formatting data.

==Automated Code Refactoring==
=== RubyMine ===
*[http://www.jetbrains.com/ruby/webhelp/refactoring.html RubyMine] has a built in refactoring menu.
*To perform refactoring, select a code fragment to refactor. Refactorings available for your selection appear under the Refactor Menu in RubyMine. <ref>http://www.jetbrains.com/ruby/webhelp/refactoring-source-code.html#common</ref> [[File:RubyMine_refactoring_menu.png]]

===RFactor ===
*[http://fabiokung.com/2009/02/04/rfactor-ruby-refactoring-for-your-loved-editor/ RFactor] is a Ruby gem, which aims to provide common and simple refactorings for Ruby code for text editors like TextMate
*The first release has only Extract method implemented while other refactorings are coming soon
*It is available on [http://github.com/fabiokung/rfactor-tmbundle/tree/master GitHub]

=== Other IDEs ===
*Some other IDEs with built-in refactoring include [http://www.aptana.com/products/studio3 Aptana Studio], [http://www.aptana.com/products/radrails Aptana RadRails] and [https://netbeans.org/features/ruby/index.html NetBeans 7] (which requires Ruby and Rails [http://plugins.netbeans.org/plugin/38549 plugin])
*A StackOverflow [http://stackoverflow.com/questions/8705144/ide-with-refactoring-support-for-ruby-on-rails post] compares these tools ranking them as RubyMine being the best, followed by NetBeans, RadRails 2 and Aptana Studio 3

==Further Reading==
*[http://en.wikipedia.org/wiki/Code_smell Ways to identify problems in code]

*[http://blog.codeclimate.com/blog/2012/11/14/why-ruby-class-methods-resist-refactoring/ Resistance With Refactoring Ruby Class Methods]

*[http://www.railsinside.com/uncategorized/460-the-first-step-of-refactoring-a-rails-application.html Refactoring a Rails Application]

*[http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ Refactoring Fat Models]

*[https://speakerdeck.com/brianvh/refactoring-views-in-rails Talk on Refactoring Fat Views]

*[http://www.amazon.com/Rails-AntiPatterns-Refactoring-Addison-Wesley-Professional/dp/0321604814 Rails AntiPatterns: Best Practice Ruby on Rails Refactoring]

==References==
<references/>

CSC/ECE 517 Spring 2014/ch1a 1w1e rm

2014-02-11T01:22:36Z

Rjlloyd: /* Refactoring views */

This page discusses refactoring techniques and metrics. It also includes tips on refactoring in Ruby and list of tools for automated refactoring.

==Background==

The idea behind [http://en.wikipedia.org/wiki/Code_refactoring code refactoring] is to take a code base and improve it's readability, [http://en.wikipedia.org/wiki/Extensibility extensibility], and [http://en.wikipedia.org/wiki/Reusability reusability]. The practice is focused on having a better quality and more standardized code base, and not on fixing bugs or changing functionality.

Refactoring has its difficulties, whether or not it is done using an [http://en.wikipedia.org/wiki/Integrated_development_environment IDE] or whether it is done by hand. There are lots of pitfalls and errors that can be made during refactoring, so it is pertinent to determine how important a refactor is to the code. Code metrics are one method used to determine how badly a file needs refactoring.

==Refactoring Techniques==
Before a coder performs a refactor, they must, either formally or informally, identify their ‘code smells’. A code smell refers to a negative quality of a code base that either implements bad programming practices or slows down code development or runtime. These aren't typically bugs, but can increase the chance of bugs later on if not fixed. Based on the type of code smell, a different refactoring technique is used to fix it.

===Duplicate Code===
Duplicate code can be a tricky concept when refactoring. Large sections of duplicated code can be easy to find and fixed by pulling it out and creating a single centralized method to call, however it is usually not that easy. Sometimes it may only be one or two lines of code that are duplicated which calls for an assessment of whether or not it is in the best interest to create a new method for a couple lines of code. Other times, code is not duplicate, rather it is similar enough that a generic method could be created to serve various purposes.
Some specific techniques to deal with this are:
*Extract Method / Pull-up Method
**If common code is used in multiple places, simply pull it out and make a method that can be called from all of the necessary places. Variables can be passed in if slight variations are needed between calls.
**If the code is used in various subclasses, put the common code in a method in the superclass, so that it can be seen and called by it’s children.
**[http://www.refactoring.com/catalog/extractMethod.html Extract Method Example]

*Form Template Method
**If two methods in subclasses perform similar steps in the same order, but the steps are different, then get the steps into methods with the same signature, so that the original methods become the same. Then pull them up. <ref>http://www.refactoring.com/catalog/formTemplateMethod.html</ref>
**[http://www.integralist.co.uk/posts/refactoring-techniques/#form-template-method Form Template Method Example]

===Large Method/Class===
If a project is not planned out well enough in advance, it is easy for methods and classes to become populated with excess functionality. While functionality of a block of code may be necessary for the project, the code block might not really pertain to the method or class it is included in.
*Extract Method
**This can be used when duplicate code occurs, as discussed above. But it can also be used when a method performs multiple functions that have the ability to be split up into various functions that serve a single purpose.
*Extract Class/Subclass/Superclass
**If there are class variables or methods that don’t directly pertain to a class, then it may be necessary to create a new class for those pieces.[http://www.refactoring.com/catalog/extractClass.html Example]
**If there are pieces of a class that are only for a specific subset of instances, then a subclass can be constructed to contain these.[http://www.refactoring.com/catalog/extractSubclass.html Example]
**If there are pieces that multiple classes use, then a superclass can be constructed to handle these generic functions, leaving the subclasses to deal with the remaining differences [http://www.refactoring.com/catalog/extractSuperclass.html Example]

===Improving Readability and Clarity===
Many times, refactoring can be used to do simple, yet necessary changes like renaming variables, methods, or classes. As features get added to a project, classes tend to get charged with more uses than originally planned, so sometimes, the original naming scheme no longer applies and a new one needs to be instilled.

Moving methods and parameters around to where they have the best accessibility also has its uses. Classes also tend to be promoted or demoted to super and sub classes after their ultimate functional purpose is determined.

===More Techniques===
There is an extensive list of coding smells that can be improved through refactoring.

A description of smells with their techniques exists [http://ghendry.net/refactor.html here].

A list of techniques with examples in Ruby are listed [http://www.refactoring.com/catalog/index.html here].

==Metrics==
It can be hard to decide whether or not to refactor, especially when it’s for something that appears to be working fine with just a surface level smell. Program analysis tools are used to derive various types of code metrics, which allow coders to identify problem areas and future pitfalls of their code base. These tools look at the code in several different ways, including the number of times a source file has been edited to help determine if it is a possible target of [feature envy], duplicate code structure to identify replicated lines, and block depths to suggest possible complexity issues.

===Open Source Ruby Metric Tools===
There are a variety of open source code metric tools that can be employed specifically for Ruby programs. [https://www.ruby-toolbox.com/categories/code_metrics The Ruby Toolbox] contains the most popular of these tools along with ratings.

[http://rubydoc.info/gems/simplecov/frames Simple Cov] is at the top of this list. It was developed specifically to be of use to anyone using any framework. It integrates itself with the project’s own test cases to check the code coverage of them in addition to cucumber features.

===Code Climate===
[https://codeclimate.com Code Climate] is a hosted code metrics tool that analyzes projects in a multitdue of ways. It produces three main metric ratings with grades from A-F that comprise of the methods and classes contained in each file and project.
====Complexity Metric====
This is based off of the Assignment, Branches, and Conditions ([http://c2.com/cgi/wiki?AbcMetric ABC]) metric, where the number of assignments, branches, and conditions are counted and analyzed. However, because Code Climate is constructed for Ruby programs, it also takes into account certain types of Ruby constructs that may increase the metric score, but are actually beneficial to the project.
====Duplication Metric====
This looks at the syntax trees of the code in order to identify identical and similar code structures. Because the syntax trees are being analyzed, code formatting and different method and class names do not affect the score. <ref>https://codeclimate.com/docs#quality-metrics</ref>

====Churn Method====
This integrates with the Git repository to look at the change history of the project’s files. Files with excessively high change histories have a tendency to have a high complexity rating as well, as they can be the result of feature envy, where extra functions are added into a file instead of being added to a new file with it’s own functionality.

==Getting Started with Refactoring in Ruby==

===First step: Writing tests===
The first step in refactoring is writing solid set of tests for the section of code under consideration, in order to avoid introducing bugs. In Ruby, this can be done using [http://www.ruby-doc.org/stdlib-2.1.0/libdoc/test/unit/rdoc/Test/Unit.html Test::Unit] or [http://rspec.info/ Rspec]. Next step is to make small changes, test, make small changes, test again and so on<ref name='Refactoring Ruby Edition'>http://www.amazon.com/Refactoring-Edition-Addison-Wesley-Professional-Series/dp/0321984137</ref>. This ensures that we can revert back to the working version of code if any small refactoring causes the application to stop working.

===When to refactor===
It is always confusing when to start refactoring. If either one of the following conditions is true, it is a good time to start refactoring code<ref name='Refactoring Ruby Edition'/>:
* The Rule of Three - If any code segment gives trouble more than two times, it is time to refactor it
* Adding new function - It might be helpful to refactor when adding new functionality as it would give better understanding of code. Sometimes, revisiting old design might help to accommodate new features better
* Fixing a bug - It is useful to refactor code which had a bug; this might save bug reports from the same piece of code in future
* During code review - Refactoring is useful during code reviews as it can be applied immediately making code reviews more fruitful
* Understanding other's code - If a new member joins the team and is asked to refactor existing code, it helps them to get a better understanding of the code base. It might take extra time to get them started, but trying to refactor will help them contribute to the project better in the long run.

A [http://blog.codeclimate.com/blog/2014/01/09/when-is-it-time-to-refactor/ CodeClimate blog] suggests some other conditions to decide when to refactor code.

===Refactoring fat models===
As more features get added to the application, the models tend to become bulkier. Such fat models cause maintenance issues. Refer to [http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ CodeClimate blog] for 7 patterns to refactor such fat models.

===Refactoring views===
In this [https://speakerdeck.com/brianvh/refactoring-views-in-rails talk], Brian Hughes explains use of patterns to refactor views with bad code smells like using conditionals or formatting data.

==Automated Code Refactoring==
=== RubyMine ===
*[http://www.jetbrains.com/ruby/webhelp/refactoring.html RubyMine] has a built in refactoring menu.
*To perform refactoring, select a code fragment to refactor. Refactorings available for your selection appear under the Refactor Menu in RubyMine. <ref>http://www.jetbrains.com/ruby/webhelp/refactoring-source-code.html#common</ref> [[File:RubyMine_refactoring_menu.png]]

===RFactor ===
*[http://fabiokung.com/2009/02/04/rfactor-ruby-refactoring-for-your-loved-editor/ RFactor] is a Ruby gem, which aims to provide common and simple refactorings for Ruby code for text editors like TextMate
*The first release has only Extract method implemented while other refactorings are coming soon
*It is available on [http://github.com/fabiokung/rfactor-tmbundle/tree/master GitHub]

=== Other IDEs ===
*Some other IDEs with built-in refactoring include [http://www.aptana.com/products/studio3 Aptana Studio], [http://www.aptana.com/products/radrails Aptana RadRails] and [https://netbeans.org/features/ruby/index.html NetBeans 7] (which requires Ruby and Rails [http://plugins.netbeans.org/plugin/38549 plugin])
*A StackOverflow [http://stackoverflow.com/questions/8705144/ide-with-refactoring-support-for-ruby-on-rails post] compares these tools ranking them as RubyMine being the best, followed by NetBeans, RadRails 2 and Aptana Studio 3

==Further Reading==
*[http://en.wikipedia.org/wiki/Code_smell Ways to identify problems in code]

*[http://blog.codeclimate.com/blog/2012/11/14/why-ruby-class-methods-resist-refactoring/ Resistance With Refactoring Ruby Class Methods]

*[http://www.railsinside.com/uncategorized/460-the-first-step-of-refactoring-a-rails-application.html Refactoring a Rails Application]

*[http://www.amazon.com/Rails-AntiPatterns-Refactoring-Addison-Wesley-Professional/dp/0321604814 Rails AntiPatterns: Best Practice Ruby on Rails Refactoring]

==References==
<references/>

CSC/ECE 517 Spring 2014/ch1a 1w1e rm

2014-02-11T01:22:01Z

Rjlloyd: /* Refactoring fat models */

This page discusses refactoring techniques and metrics. It also includes tips on refactoring in Ruby and list of tools for automated refactoring.

==Background==

The idea behind [http://en.wikipedia.org/wiki/Code_refactoring code refactoring] is to take a code base and improve it's readability, [http://en.wikipedia.org/wiki/Extensibility extensibility], and [http://en.wikipedia.org/wiki/Reusability reusability]. The practice is focused on having a better quality and more standardized code base, and not on fixing bugs or changing functionality.

Refactoring has its difficulties, whether or not it is done using an [http://en.wikipedia.org/wiki/Integrated_development_environment IDE] or whether it is done by hand. There are lots of pitfalls and errors that can be made during refactoring, so it is pertinent to determine how important a refactor is to the code. Code metrics are one method used to determine how badly a file needs refactoring.

==Refactoring Techniques==
Before a coder performs a refactor, they must, either formally or informally, identify their ‘code smells’. A code smell refers to a negative quality of a code base that either implements bad programming practices or slows down code development or runtime. These aren't typically bugs, but can increase the chance of bugs later on if not fixed. Based on the type of code smell, a different refactoring technique is used to fix it.

===Duplicate Code===
Duplicate code can be a tricky concept when refactoring. Large sections of duplicated code can be easy to find and fixed by pulling it out and creating a single centralized method to call, however it is usually not that easy. Sometimes it may only be one or two lines of code that are duplicated which calls for an assessment of whether or not it is in the best interest to create a new method for a couple lines of code. Other times, code is not duplicate, rather it is similar enough that a generic method could be created to serve various purposes.
Some specific techniques to deal with this are:
*Extract Method / Pull-up Method
**If common code is used in multiple places, simply pull it out and make a method that can be called from all of the necessary places. Variables can be passed in if slight variations are needed between calls.
**If the code is used in various subclasses, put the common code in a method in the superclass, so that it can be seen and called by it’s children.
**[http://www.refactoring.com/catalog/extractMethod.html Extract Method Example]

*Form Template Method
**If two methods in subclasses perform similar steps in the same order, but the steps are different, then get the steps into methods with the same signature, so that the original methods become the same. Then pull them up. <ref>http://www.refactoring.com/catalog/formTemplateMethod.html</ref>
**[http://www.integralist.co.uk/posts/refactoring-techniques/#form-template-method Form Template Method Example]

===Large Method/Class===
If a project is not planned out well enough in advance, it is easy for methods and classes to become populated with excess functionality. While functionality of a block of code may be necessary for the project, the code block might not really pertain to the method or class it is included in.
*Extract Method
**This can be used when duplicate code occurs, as discussed above. But it can also be used when a method performs multiple functions that have the ability to be split up into various functions that serve a single purpose.
*Extract Class/Subclass/Superclass
**If there are class variables or methods that don’t directly pertain to a class, then it may be necessary to create a new class for those pieces.[http://www.refactoring.com/catalog/extractClass.html Example]
**If there are pieces of a class that are only for a specific subset of instances, then a subclass can be constructed to contain these.[http://www.refactoring.com/catalog/extractSubclass.html Example]
**If there are pieces that multiple classes use, then a superclass can be constructed to handle these generic functions, leaving the subclasses to deal with the remaining differences [http://www.refactoring.com/catalog/extractSuperclass.html Example]

===Improving Readability and Clarity===
Many times, refactoring can be used to do simple, yet necessary changes like renaming variables, methods, or classes. As features get added to a project, classes tend to get charged with more uses than originally planned, so sometimes, the original naming scheme no longer applies and a new one needs to be instilled.

Moving methods and parameters around to where they have the best accessibility also has its uses. Classes also tend to be promoted or demoted to super and sub classes after their ultimate functional purpose is determined.

===More Techniques===
There is an extensive list of coding smells that can be improved through refactoring.

A description of smells with their techniques exists [http://ghendry.net/refactor.html here].

A list of techniques with examples in Ruby are listed [http://www.refactoring.com/catalog/index.html here].

==Metrics==
It can be hard to decide whether or not to refactor, especially when it’s for something that appears to be working fine with just a surface level smell. Program analysis tools are used to derive various types of code metrics, which allow coders to identify problem areas and future pitfalls of their code base. These tools look at the code in several different ways, including the number of times a source file has been edited to help determine if it is a possible target of [feature envy], duplicate code structure to identify replicated lines, and block depths to suggest possible complexity issues.

===Open Source Ruby Metric Tools===
There are a variety of open source code metric tools that can be employed specifically for Ruby programs. [https://www.ruby-toolbox.com/categories/code_metrics The Ruby Toolbox] contains the most popular of these tools along with ratings.

[http://rubydoc.info/gems/simplecov/frames Simple Cov] is at the top of this list. It was developed specifically to be of use to anyone using any framework. It integrates itself with the project’s own test cases to check the code coverage of them in addition to cucumber features.

===Code Climate===
[https://codeclimate.com Code Climate] is a hosted code metrics tool that analyzes projects in a multitdue of ways. It produces three main metric ratings with grades from A-F that comprise of the methods and classes contained in each file and project.
====Complexity Metric====
This is based off of the Assignment, Branches, and Conditions ([http://c2.com/cgi/wiki?AbcMetric ABC]) metric, where the number of assignments, branches, and conditions are counted and analyzed. However, because Code Climate is constructed for Ruby programs, it also takes into account certain types of Ruby constructs that may increase the metric score, but are actually beneficial to the project.
====Duplication Metric====
This looks at the syntax trees of the code in order to identify identical and similar code structures. Because the syntax trees are being analyzed, code formatting and different method and class names do not affect the score. <ref>https://codeclimate.com/docs#quality-metrics</ref>

====Churn Method====
This integrates with the Git repository to look at the change history of the project’s files. Files with excessively high change histories have a tendency to have a high complexity rating as well, as they can be the result of feature envy, where extra functions are added into a file instead of being added to a new file with it’s own functionality.

==Getting Started with Refactoring in Ruby==

===First step: Writing tests===
The first step in refactoring is writing solid set of tests for the section of code under consideration, in order to avoid introducing bugs. In Ruby, this can be done using [http://www.ruby-doc.org/stdlib-2.1.0/libdoc/test/unit/rdoc/Test/Unit.html Test::Unit] or [http://rspec.info/ Rspec]. Next step is to make small changes, test, make small changes, test again and so on<ref name='Refactoring Ruby Edition'>http://www.amazon.com/Refactoring-Edition-Addison-Wesley-Professional-Series/dp/0321984137</ref>. This ensures that we can revert back to the working version of code if any small refactoring causes the application to stop working.

===When to refactor===
It is always confusing when to start refactoring. If either one of the following conditions is true, it is a good time to start refactoring code<ref name='Refactoring Ruby Edition'/>:
* The Rule of Three - If any code segment gives trouble more than two times, it is time to refactor it
* Adding new function - It might be helpful to refactor when adding new functionality as it would give better understanding of code. Sometimes, revisiting old design might help to accommodate new features better
* Fixing a bug - It is useful to refactor code which had a bug; this might save bug reports from the same piece of code in future
* During code review - Refactoring is useful during code reviews as it can be applied immediately making code reviews more fruitful
* Understanding other's code - If a new member joins the team and is asked to refactor existing code, it helps them to get a better understanding of the code base. It might take extra time to get them started, but trying to refactor will help them contribute to the project better in the long run.

A [http://blog.codeclimate.com/blog/2014/01/09/when-is-it-time-to-refactor/ CodeClimate blog] suggests some other conditions to decide when to refactor code.

===Refactoring fat models===
As more features get added to the application, the models tend to become bulkier. Such fat models cause maintenance issues. Refer to [http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ CodeClimate blog] for 7 patterns to refactor such fat models.

===Refactoring views===
In this [https://speakerdeck.com/brianvh/refactoring-views-in-rails talk], Brian Hughes explains use of patterns to refactor views with bad code smells like use of conditionals or formatting data.

==Automated Code Refactoring==
=== RubyMine ===
*[http://www.jetbrains.com/ruby/webhelp/refactoring.html RubyMine] has a built in refactoring menu.
*To perform refactoring, select a code fragment to refactor. Refactorings available for your selection appear under the Refactor Menu in RubyMine. <ref>http://www.jetbrains.com/ruby/webhelp/refactoring-source-code.html#common</ref> [[File:RubyMine_refactoring_menu.png]]

===RFactor ===
*[http://fabiokung.com/2009/02/04/rfactor-ruby-refactoring-for-your-loved-editor/ RFactor] is a Ruby gem, which aims to provide common and simple refactorings for Ruby code for text editors like TextMate
*The first release has only Extract method implemented while other refactorings are coming soon
*It is available on [http://github.com/fabiokung/rfactor-tmbundle/tree/master GitHub]

=== Other IDEs ===
*Some other IDEs with built-in refactoring include [http://www.aptana.com/products/studio3 Aptana Studio], [http://www.aptana.com/products/radrails Aptana RadRails] and [https://netbeans.org/features/ruby/index.html NetBeans 7] (which requires Ruby and Rails [http://plugins.netbeans.org/plugin/38549 plugin])
*A StackOverflow [http://stackoverflow.com/questions/8705144/ide-with-refactoring-support-for-ruby-on-rails post] compares these tools ranking them as RubyMine being the best, followed by NetBeans, RadRails 2 and Aptana Studio 3

==Further Reading==
*[http://en.wikipedia.org/wiki/Code_smell Ways to identify problems in code]

*[http://blog.codeclimate.com/blog/2012/11/14/why-ruby-class-methods-resist-refactoring/ Resistance With Refactoring Ruby Class Methods]

*[http://www.railsinside.com/uncategorized/460-the-first-step-of-refactoring-a-rails-application.html Refactoring a Rails Application]

*[http://www.amazon.com/Rails-AntiPatterns-Refactoring-Addison-Wesley-Professional/dp/0321604814 Rails AntiPatterns: Best Practice Ruby on Rails Refactoring]

==References==
<references/>

CSC/ECE 517 Spring 2014/ch1a 1w1e rm

2014-02-11T01:18:47Z

Rjlloyd: /* First step: Writing tests */

This page discusses refactoring techniques and metrics. It also includes tips on refactoring in Ruby and list of tools for automated refactoring.

==Background==

The idea behind [http://en.wikipedia.org/wiki/Code_refactoring code refactoring] is to take a code base and improve it's readability, [http://en.wikipedia.org/wiki/Extensibility extensibility], and [http://en.wikipedia.org/wiki/Reusability reusability]. The practice is focused on having a better quality and more standardized code base, and not on fixing bugs or changing functionality.

Refactoring has its difficulties, whether or not it is done using an [http://en.wikipedia.org/wiki/Integrated_development_environment IDE] or whether it is done by hand. There are lots of pitfalls and errors that can be made during refactoring, so it is pertinent to determine how important a refactor is to the code. Code metrics are one method used to determine how badly a file needs refactoring.

==Refactoring Techniques==
Before a coder performs a refactor, they must, either formally or informally, identify their ‘code smells’. A code smell refers to a negative quality of a code base that either implements bad programming practices or slows down code development or runtime. These aren't typically bugs, but can increase the chance of bugs later on if not fixed. Based on the type of code smell, a different refactoring technique is used to fix it.

===Duplicate Code===
Duplicate code can be a tricky concept when refactoring. Large sections of duplicated code can be easy to find and fixed by pulling it out and creating a single centralized method to call, however it is usually not that easy. Sometimes it may only be one or two lines of code that are duplicated which calls for an assessment of whether or not it is in the best interest to create a new method for a couple lines of code. Other times, code is not duplicate, rather it is similar enough that a generic method could be created to serve various purposes.
Some specific techniques to deal with this are:
*Extract Method / Pull-up Method
**If common code is used in multiple places, simply pull it out and make a method that can be called from all of the necessary places. Variables can be passed in if slight variations are needed between calls.
**If the code is used in various subclasses, put the common code in a method in the superclass, so that it can be seen and called by it’s children.
**[http://www.refactoring.com/catalog/extractMethod.html Extract Method Example]

*Form Template Method
**If two methods in subclasses perform similar steps in the same order, but the steps are different, then get the steps into methods with the same signature, so that the original methods become the same. Then pull them up. <ref>http://www.refactoring.com/catalog/formTemplateMethod.html</ref>
**[http://www.integralist.co.uk/posts/refactoring-techniques/#form-template-method Form Template Method Example]

===Large Method/Class===
If a project is not planned out well enough in advance, it is easy for methods and classes to become populated with excess functionality. While functionality of a block of code may be necessary for the project, the code block might not really pertain to the method or class it is included in.
*Extract Method
**This can be used when duplicate code occurs, as discussed above. But it can also be used when a method performs multiple functions that have the ability to be split up into various functions that serve a single purpose.
*Extract Class/Subclass/Superclass
**If there are class variables or methods that don’t directly pertain to a class, then it may be necessary to create a new class for those pieces.[http://www.refactoring.com/catalog/extractClass.html Example]
**If there are pieces of a class that are only for a specific subset of instances, then a subclass can be constructed to contain these.[http://www.refactoring.com/catalog/extractSubclass.html Example]
**If there are pieces that multiple classes use, then a superclass can be constructed to handle these generic functions, leaving the subclasses to deal with the remaining differences [http://www.refactoring.com/catalog/extractSuperclass.html Example]

===Improving Readability and Clarity===
Many times, refactoring can be used to do simple, yet necessary changes like renaming variables, methods, or classes. As features get added to a project, classes tend to get charged with more uses than originally planned, so sometimes, the original naming scheme no longer applies and a new one needs to be instilled.

Moving methods and parameters around to where they have the best accessibility also has its uses. Classes also tend to be promoted or demoted to super and sub classes after their ultimate functional purpose is determined.

===More Techniques===
There is an extensive list of coding smells that can be improved through refactoring.

A description of smells with their techniques exists [http://ghendry.net/refactor.html here].

A list of techniques with examples in Ruby are listed [http://www.refactoring.com/catalog/index.html here].

==Metrics==
It can be hard to decide whether or not to refactor, especially when it’s for something that appears to be working fine with just a surface level smell. Program analysis tools are used to derive various types of code metrics, which allow coders to identify problem areas and future pitfalls of their code base. These tools look at the code in several different ways, including the number of times a source file has been edited to help determine if it is a possible target of [feature envy], duplicate code structure to identify replicated lines, and block depths to suggest possible complexity issues.

===Open Source Ruby Metric Tools===
There are a variety of open source code metric tools that can be employed specifically for Ruby programs. [https://www.ruby-toolbox.com/categories/code_metrics The Ruby Toolbox] contains the most popular of these tools along with ratings.

[http://rubydoc.info/gems/simplecov/frames Simple Cov] is at the top of this list. It was developed specifically to be of use to anyone using any framework. It integrates itself with the project’s own test cases to check the code coverage of them in addition to cucumber features.

===Code Climate===
[https://codeclimate.com Code Climate] is a hosted code metrics tool that analyzes projects in a multitdue of ways. It produces three main metric ratings with grades from A-F that comprise of the methods and classes contained in each file and project.
====Complexity Metric====
This is based off of the Assignment, Branches, and Conditions ([http://c2.com/cgi/wiki?AbcMetric ABC]) metric, where the number of assignments, branches, and conditions are counted and analyzed. However, because Code Climate is constructed for Ruby programs, it also takes into account certain types of Ruby constructs that may increase the metric score, but are actually beneficial to the project.
====Duplication Metric====
This looks at the syntax trees of the code in order to identify identical and similar code structures. Because the syntax trees are being analyzed, code formatting and different method and class names do not affect the score. <ref>https://codeclimate.com/docs#quality-metrics</ref>

====Churn Method====
This integrates with the Git repository to look at the change history of the project’s files. Files with excessively high change histories have a tendency to have a high complexity rating as well, as they can be the result of feature envy, where extra functions are added into a file instead of being added to a new file with it’s own functionality.

==Getting Started with Refactoring in Ruby==

===First step: Writing tests===
The first step in refactoring is writing solid set of tests for the section of code under consideration, in order to avoid introducing bugs. In Ruby, this can be done using [http://www.ruby-doc.org/stdlib-2.1.0/libdoc/test/unit/rdoc/Test/Unit.html Test::Unit] or [http://rspec.info/ Rspec]. Next step is to make small changes, test, make small changes, test again and so on<ref name='Refactoring Ruby Edition'>http://www.amazon.com/Refactoring-Edition-Addison-Wesley-Professional-Series/dp/0321984137</ref>. This ensures that we can revert back to the working version of code if any small refactoring causes the application to stop working.

===When to refactor===
It is always confusing when to start refactoring. If either one of the following conditions is true, it is a good time to start refactoring code<ref name='Refactoring Ruby Edition'/>:
* The Rule of Three - If any code segment gives trouble more than two times, it is time to refactor it
* Adding new function - It might be helpful to refactor when adding new functionality as it would give better understanding of code. Sometimes, revisiting old design might help to accommodate new features better
* Fixing a bug - It is useful to refactor code which had a bug; this might save bug reports from the same piece of code in future
* During code review - Refactoring is useful during code reviews as it can be applied immediately making code reviews more fruitful
* Understanding other's code - If a new member joins the team and is asked to refactor existing code, it helps them to get a better understanding of the code base. It might take extra time to get them started, but trying to refactor will help them contribute to the project better in the long run.

A [http://blog.codeclimate.com/blog/2014/01/09/when-is-it-time-to-refactor/ CodeClimate blog] suggests some other conditions to decide when to refactor code.

===Refactoring fat models===
As more features get added to the application, the models tend to become bulkier. Such fat models cause maintenance issues. Refer [http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ CodeClimate blog] for 7 patterns to refactor such fat models.

===Refactoring views===
In this [https://speakerdeck.com/brianvh/refactoring-views-in-rails talk], Brian Hughes explains use of patterns to refactor views with bad code smells like use of conditionals or formatting data.

==Automated Code Refactoring==
=== RubyMine ===
*[http://www.jetbrains.com/ruby/webhelp/refactoring.html RubyMine] has a built in refactoring menu.
*To perform refactoring, select a code fragment to refactor. Refactorings available for your selection appear under the Refactor Menu in RubyMine. <ref>http://www.jetbrains.com/ruby/webhelp/refactoring-source-code.html#common</ref> [[File:RubyMine_refactoring_menu.png]]

===RFactor ===
*[http://fabiokung.com/2009/02/04/rfactor-ruby-refactoring-for-your-loved-editor/ RFactor] is a Ruby gem, which aims to provide common and simple refactorings for Ruby code for text editors like TextMate
*The first release has only Extract method implemented while other refactorings are coming soon
*It is available on [http://github.com/fabiokung/rfactor-tmbundle/tree/master GitHub]

=== Other IDEs ===
*Some other IDEs with built-in refactoring include [http://www.aptana.com/products/studio3 Aptana Studio], [http://www.aptana.com/products/radrails Aptana RadRails] and [https://netbeans.org/features/ruby/index.html NetBeans 7] (which requires Ruby and Rails [http://plugins.netbeans.org/plugin/38549 plugin])
*A StackOverflow [http://stackoverflow.com/questions/8705144/ide-with-refactoring-support-for-ruby-on-rails post] compares these tools ranking them as RubyMine being the best, followed by NetBeans, RadRails 2 and Aptana Studio 3

==Further Reading==
*[http://en.wikipedia.org/wiki/Code_smell Ways to identify problems in code]

*[http://blog.codeclimate.com/blog/2012/11/14/why-ruby-class-methods-resist-refactoring/ Resistance With Refactoring Ruby Class Methods]

*[http://www.railsinside.com/uncategorized/460-the-first-step-of-refactoring-a-rails-application.html Refactoring a Rails Application]

*[http://www.amazon.com/Rails-AntiPatterns-Refactoring-Addison-Wesley-Professional/dp/0321604814 Rails AntiPatterns: Best Practice Ruby on Rails Refactoring]

==References==
<references/>

CSC/ECE 517 Spring 2014/ch1a 1w1e rm

2014-02-11T01:18:00Z

Rjlloyd: /* Background */

This page discusses refactoring techniques and metrics. It also includes tips on refactoring in Ruby and list of tools for automated refactoring.

==Background==

The idea behind [http://en.wikipedia.org/wiki/Code_refactoring code refactoring] is to take a code base and improve it's readability, [http://en.wikipedia.org/wiki/Extensibility extensibility], and [http://en.wikipedia.org/wiki/Reusability reusability]. The practice is focused on having a better quality and more standardized code base, and not on fixing bugs or changing functionality.

Refactoring has its difficulties, whether or not it is done using an [http://en.wikipedia.org/wiki/Integrated_development_environment IDE] or whether it is done by hand. There are lots of pitfalls and errors that can be made during refactoring, so it is pertinent to determine how important a refactor is to the code. Code metrics are one method used to determine how badly a file needs refactoring.

==Refactoring Techniques==
Before a coder performs a refactor, they must, either formally or informally, identify their ‘code smells’. A code smell refers to a negative quality of a code base that either implements bad programming practices or slows down code development or runtime. These aren't typically bugs, but can increase the chance of bugs later on if not fixed. Based on the type of code smell, a different refactoring technique is used to fix it.

===Duplicate Code===
Duplicate code can be a tricky concept when refactoring. Large sections of duplicated code can be easy to find and fixed by pulling it out and creating a single centralized method to call, however it is usually not that easy. Sometimes it may only be one or two lines of code that are duplicated which calls for an assessment of whether or not it is in the best interest to create a new method for a couple lines of code. Other times, code is not duplicate, rather it is similar enough that a generic method could be created to serve various purposes.
Some specific techniques to deal with this are:
*Extract Method / Pull-up Method
**If common code is used in multiple places, simply pull it out and make a method that can be called from all of the necessary places. Variables can be passed in if slight variations are needed between calls.
**If the code is used in various subclasses, put the common code in a method in the superclass, so that it can be seen and called by it’s children.
**[http://www.refactoring.com/catalog/extractMethod.html Extract Method Example]

*Form Template Method
**If two methods in subclasses perform similar steps in the same order, but the steps are different, then get the steps into methods with the same signature, so that the original methods become the same. Then pull them up. <ref>http://www.refactoring.com/catalog/formTemplateMethod.html</ref>
**[http://www.integralist.co.uk/posts/refactoring-techniques/#form-template-method Form Template Method Example]

===Large Method/Class===
If a project is not planned out well enough in advance, it is easy for methods and classes to become populated with excess functionality. While functionality of a block of code may be necessary for the project, the code block might not really pertain to the method or class it is included in.
*Extract Method
**This can be used when duplicate code occurs, as discussed above. But it can also be used when a method performs multiple functions that have the ability to be split up into various functions that serve a single purpose.
*Extract Class/Subclass/Superclass
**If there are class variables or methods that don’t directly pertain to a class, then it may be necessary to create a new class for those pieces.[http://www.refactoring.com/catalog/extractClass.html Example]
**If there are pieces of a class that are only for a specific subset of instances, then a subclass can be constructed to contain these.[http://www.refactoring.com/catalog/extractSubclass.html Example]
**If there are pieces that multiple classes use, then a superclass can be constructed to handle these generic functions, leaving the subclasses to deal with the remaining differences [http://www.refactoring.com/catalog/extractSuperclass.html Example]

===Improving Readability and Clarity===
Many times, refactoring can be used to do simple, yet necessary changes like renaming variables, methods, or classes. As features get added to a project, classes tend to get charged with more uses than originally planned, so sometimes, the original naming scheme no longer applies and a new one needs to be instilled.

Moving methods and parameters around to where they have the best accessibility also has its uses. Classes also tend to be promoted or demoted to super and sub classes after their ultimate functional purpose is determined.

===More Techniques===
There is an extensive list of coding smells that can be improved through refactoring.

A description of smells with their techniques exists [http://ghendry.net/refactor.html here].

A list of techniques with examples in Ruby are listed [http://www.refactoring.com/catalog/index.html here].

==Metrics==
It can be hard to decide whether or not to refactor, especially when it’s for something that appears to be working fine with just a surface level smell. Program analysis tools are used to derive various types of code metrics, which allow coders to identify problem areas and future pitfalls of their code base. These tools look at the code in several different ways, including the number of times a source file has been edited to help determine if it is a possible target of [feature envy], duplicate code structure to identify replicated lines, and block depths to suggest possible complexity issues.

===Open Source Ruby Metric Tools===
There are a variety of open source code metric tools that can be employed specifically for Ruby programs. [https://www.ruby-toolbox.com/categories/code_metrics The Ruby Toolbox] contains the most popular of these tools along with ratings.

[http://rubydoc.info/gems/simplecov/frames Simple Cov] is at the top of this list. It was developed specifically to be of use to anyone using any framework. It integrates itself with the project’s own test cases to check the code coverage of them in addition to cucumber features.

===Code Climate===
[https://codeclimate.com Code Climate] is a hosted code metrics tool that analyzes projects in a multitdue of ways. It produces three main metric ratings with grades from A-F that comprise of the methods and classes contained in each file and project.
====Complexity Metric====
This is based off of the Assignment, Branches, and Conditions ([http://c2.com/cgi/wiki?AbcMetric ABC]) metric, where the number of assignments, branches, and conditions are counted and analyzed. However, because Code Climate is constructed for Ruby programs, it also takes into account certain types of Ruby constructs that may increase the metric score, but are actually beneficial to the project.
====Duplication Metric====
This looks at the syntax trees of the code in order to identify identical and similar code structures. Because the syntax trees are being analyzed, code formatting and different method and class names do not affect the score. <ref>https://codeclimate.com/docs#quality-metrics</ref>

====Churn Method====
This integrates with the Git repository to look at the change history of the project’s files. Files with excessively high change histories have a tendency to have a high complexity rating as well, as they can be the result of feature envy, where extra functions are added into a file instead of being added to a new file with it’s own functionality.

==Getting Started with Refactoring in Ruby==

===First step: Writing tests===
The first step in refactoring is writing solid set of tests for the section of code under consideration, to avoid introducing bugs. In Ruby, this can be done using [http://www.ruby-doc.org/stdlib-2.1.0/libdoc/test/unit/rdoc/Test/Unit.html Test::Unit] or [http://rspec.info/ Rspec]. Next step is to make small changes, test, make small changes, test again and so on<ref name='Refactoring Ruby Edition'>http://www.amazon.com/Refactoring-Edition-Addison-Wesley-Professional-Series/dp/0321984137</ref>. This ensures that we can revert back to the working version of code if any small refactoring causes the application to stop working.

===When to refactor===
It is always confusing when to start refactoring. If either one of the following conditions is true, it is a good time to start refactoring code<ref name='Refactoring Ruby Edition'/>:
* The Rule of Three - If any code segment gives trouble more than two times, it is time to refactor it
* Adding new function - It might be helpful to refactor when adding new functionality as it would give better understanding of code. Sometimes, revisiting old design might help to accommodate new features better
* Fixing a bug - It is useful to refactor code which had a bug; this might save bug reports from the same piece of code in future
* During code review - Refactoring is useful during code reviews as it can be applied immediately making code reviews more fruitful
* Understanding other's code - If a new member joins the team and is asked to refactor existing code, it helps them to get a better understanding of the code base. It might take extra time to get them started, but trying to refactor will help them contribute to the project better in the long run.

A [http://blog.codeclimate.com/blog/2014/01/09/when-is-it-time-to-refactor/ CodeClimate blog] suggests some other conditions to decide when to refactor code.

===Refactoring fat models===
As more features get added to the application, the models tend to become bulkier. Such fat models cause maintenance issues. Refer [http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ CodeClimate blog] for 7 patterns to refactor such fat models.

===Refactoring views===
In this [https://speakerdeck.com/brianvh/refactoring-views-in-rails talk], Brian Hughes explains use of patterns to refactor views with bad code smells like use of conditionals or formatting data.

==Automated Code Refactoring==
=== RubyMine ===
*[http://www.jetbrains.com/ruby/webhelp/refactoring.html RubyMine] has a built in refactoring menu.
*To perform refactoring, select a code fragment to refactor. Refactorings available for your selection appear under the Refactor Menu in RubyMine. <ref>http://www.jetbrains.com/ruby/webhelp/refactoring-source-code.html#common</ref> [[File:RubyMine_refactoring_menu.png]]

===RFactor ===
*[http://fabiokung.com/2009/02/04/rfactor-ruby-refactoring-for-your-loved-editor/ RFactor] is a Ruby gem, which aims to provide common and simple refactorings for Ruby code for text editors like TextMate
*The first release has only Extract method implemented while other refactorings are coming soon
*It is available on [http://github.com/fabiokung/rfactor-tmbundle/tree/master GitHub]

=== Other IDEs ===
*Some other IDEs with built-in refactoring include [http://www.aptana.com/products/studio3 Aptana Studio], [http://www.aptana.com/products/radrails Aptana RadRails] and [https://netbeans.org/features/ruby/index.html NetBeans 7] (which requires Ruby and Rails [http://plugins.netbeans.org/plugin/38549 plugin])
*A StackOverflow [http://stackoverflow.com/questions/8705144/ide-with-refactoring-support-for-ruby-on-rails post] compares these tools ranking them as RubyMine being the best, followed by NetBeans, RadRails 2 and Aptana Studio 3

==Further Reading==
*[http://en.wikipedia.org/wiki/Code_smell Ways to identify problems in code]

*[http://blog.codeclimate.com/blog/2012/11/14/why-ruby-class-methods-resist-refactoring/ Resistance With Refactoring Ruby Class Methods]

*[http://www.railsinside.com/uncategorized/460-the-first-step-of-refactoring-a-rails-application.html Refactoring a Rails Application]

*[http://www.amazon.com/Rails-AntiPatterns-Refactoring-Addison-Wesley-Professional/dp/0321604814 Rails AntiPatterns: Best Practice Ruby on Rails Refactoring]

==References==
<references/>

CSC/ECE 517 Spring 2014/ch1a 1w1e rm

2014-02-11T01:00:42Z

Rjlloyd: /* Large Method/Class */

This page discusses refactoring techniques and metrics. It also includes tips on refactoring in Ruby and list of tools for automated refactoring.

==Background==
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, [http://en.wikipedia.org/wiki/Extensibility extensibility], and [http://en.wikipedia.org/wiki/Reusability reusability] of code.

Whether done through an [http://en.wikipedia.org/wiki/Integrated_development_environment 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.

==Refactoring Techniques==
Before a coder performs a refactor, they must, either formally or informally, identify their ‘code smells’. A code smell refers to a negative quality of a code base that either implements bad programming practices or slows down code development or runtime. These aren't typically bugs, but can increase the chance of bugs later on if not fixed. Based on the type of code smell, a different refactoring technique is used to fix it.

===Duplicate Code===
Duplicate code can be a tricky concept when refactoring. Large sections of duplicated code can be easy to find and fixed by pulling it out and creating a single centralized method to call, however it is usually not that easy. Sometimes it may only be one or two lines of code that are duplicated which calls for an assessment of whether or not it is in the best interest to create a new method for a couple lines of code. Other times, code is not duplicate, rather it is similar enough that a generic method could be created to serve various purposes.
Some specific techniques to deal with this are:
*Extract Method / Pull-up Method
**If common code is used in multiple places, simply pull it out and make a method that can be called from all of the necessary places. Variables can be passed in if slight variations are needed between calls.
**If the code is used in various subclasses, put the common code in a method in the superclass, so that it can be seen and called by it’s children.
**[http://www.refactoring.com/catalog/extractMethod.html Extract Method Example]

*Form Template Method
**If two methods in subclasses perform similar steps in the same order, but the steps are different, then get the steps into methods with the same signature, so that the original methods become the same. Then pull them up. <ref>http://www.refactoring.com/catalog/formTemplateMethod.html</ref>
**[http://www.integralist.co.uk/posts/refactoring-techniques/#form-template-method Form Template Method Example]

===Large Method/Class===
If a project is not planned out well enough in advance, it is easy for methods and classes to become populated with excess functionality. While functionality of a block of code may be necessary for the project, the code block might not really pertain to the method or class it is included in.
*Extract Method
**This can be used when duplicate code occurs, as discussed above. But it can also be used when a method performs multiple functions that have the ability to be split up into various functions that serve a single purpose.
*Extract Class/Subclass/Superclass
**If there are class variables or methods that don’t directly pertain to a class, then it may be necessary to create a new class for those pieces.[http://www.refactoring.com/catalog/extractClass.html Example]
**If there are pieces of a class that are only for a specific subset of instances, then a subclass can be constructed to contain these.[http://www.refactoring.com/catalog/extractSubclass.html Example]
**If there are pieces that multiple classes use, then a superclass can be constructed to handle these generic functions, leaving the subclasses to deal with the remaining differences [http://www.refactoring.com/catalog/extractSuperclass.html Example]

===Improving Readability and Clarity===
Many times, refactoring can be used to do simple, yet necessary changes like renaming variables, methods, or classes. As features get added to a project, classes tend to get charged with more uses than originally planned, so sometimes, the original naming scheme no longer applies and a new one needs to be instilled.

Moving methods and parameters around to where they have the best accessibility also has its uses. Classes also tend to be promoted or demoted to super and sub classes after their ultimate functional purpose is determined.

===More Techniques===
There is an extensive list of coding smells that can be improved through refactoring.

A description of smells with their techniques exists [http://ghendry.net/refactor.html here].

A list of techniques with examples in Ruby are listed [http://www.refactoring.com/catalog/index.html here].

==Metrics==
It can be hard to decide whether or not to refactor, especially when it’s for something that appears to be working fine with just a surface level smell. Program analysis tools are used to derive various types of code metrics, which allow coders to identify problem areas and future pitfalls of their code base. These tools look at the code in several different ways, including the number of times a source file has been edited to help determine if it is a possible target of [feature envy], duplicate code structure to identify replicated lines, and block depths to suggest possible complexity issues.

===Open Source Ruby Metric Tools===
There are a variety of open source code metric tools that can be employed specifically for Ruby programs. [https://www.ruby-toolbox.com/categories/code_metrics The Ruby Toolbox] contains the most popular of these tools along with ratings.

[http://rubydoc.info/gems/simplecov/frames Simple Cov] is at the top of this list. It was developed specifically to be of use to anyone using any framework. It integrates itself with the project’s own test cases to check the code coverage of them in addition to cucumber features.

===Code Climate===
[https://codeclimate.com Code Climate] is a hosted code metrics tool that analyzes projects in a multitdue of ways. It produces three main metric ratings with grades from A-F that comprise of the methods and classes contained in each file and project.
====Complexity Metric====
This is based off of the Assignment, Branches, and Conditions ([http://c2.com/cgi/wiki?AbcMetric ABC]) metric, where the number of assignments, branches, and conditions are counted and analyzed. However, because Code Climate is constructed for Ruby programs, it also takes into account certain types of Ruby constructs that may increase the metric score, but are actually beneficial to the project.
====Duplication Metric====
This looks at the syntax trees of the code in order to identify identical and similar code structures. Because the syntax trees are being analyzed, code formatting and different method and class names do not affect the score. <ref>https://codeclimate.com/docs#quality-metrics</ref>

====Churn Method====
This integrates with the Git repository to look at the change history of the project’s files. Files with excessively high change histories have a tendency to have a high complexity rating as well, as they can be the result of feature envy, where extra functions are added into a file instead of being added to a new file with it’s own functionality.

==Getting Started with Refactoring in Ruby==

===First step: Writing tests===
The first step in refactoring is writing solid set of tests for the section of code under consideration, to avoid introducing bugs. In Ruby, this can be done using [http://www.ruby-doc.org/stdlib-2.1.0/libdoc/test/unit/rdoc/Test/Unit.html Test::Unit] or [http://rspec.info/ Rspec]. Next step is to make small changes, test, make small changes, test again and so on<ref name='Refactoring Ruby Edition'>http://www.amazon.com/Refactoring-Edition-Addison-Wesley-Professional-Series/dp/0321984137</ref>. This ensures that we can revert back to the working version of code if any small refactoring causes the application to stop working.

===When to refactor===
It is always confusing when to start refactoring. If either one of the following conditions is true, it is a good time to start refactoring code<ref name='Refactoring Ruby Edition'/>:
* The Rule of Three - If any code segment gives trouble more than two times, it is time to refactor it
* Adding new function - It might be helpful to refactor when adding new functionality as it would give better understanding of code. Sometimes, revisiting old design might help to accommodate new features better
* Fixing a bug - It is useful to refactor code which had a bug; this might save bug reports from the same piece of code in future
* During code review - Refactoring is useful during code reviews as it can be applied immediately making code reviews more fruitful
* Understanding other's code - If a new member joins the team and is asked to refactor existing code, it helps them to get a better understanding of the code base. It might take extra time to get them started, but trying to refactor will help them contribute to the project better in the long run.

A [http://blog.codeclimate.com/blog/2014/01/09/when-is-it-time-to-refactor/ CodeClimate blog] suggests some other conditions to decide when to refactor code.

===Refactoring fat models===
As more features get added to the application, the models tend to become bulkier. Such fat models cause maintenance issues. Refer [http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ CodeClimate blog] for 7 patterns to refactor such fat models.

===Refactoring views===
In this [https://speakerdeck.com/brianvh/refactoring-views-in-rails talk], Brian Hughes explains use of patterns to refactor views with bad code smells like use of conditionals or formatting data.

==Automated Code Refactoring==
=== RubyMine ===
*[http://www.jetbrains.com/ruby/webhelp/refactoring.html RubyMine] has a built in refactoring menu.
*To perform refactoring, select a code fragment to refactor. Refactorings available for your selection appear under the Refactor Menu in RubyMine. <ref>http://www.jetbrains.com/ruby/webhelp/refactoring-source-code.html#common</ref> [[File:RubyMine_refactoring_menu.png]]

===RFactor ===
*[http://fabiokung.com/2009/02/04/rfactor-ruby-refactoring-for-your-loved-editor/ RFactor] is a Ruby gem, which aims to provide common and simple refactorings for Ruby code for text editors like TextMate
*The first release has only Extract method implemented while other refactorings are coming soon
*It is available on [http://github.com/fabiokung/rfactor-tmbundle/tree/master GitHub]

=== Other IDEs ===
*Some other IDEs with built-in refactoring include [http://www.aptana.com/products/studio3 Aptana Studio], [http://www.aptana.com/products/radrails Aptana RadRails] and [https://netbeans.org/features/ruby/index.html NetBeans 7] (which requires Ruby and Rails [http://plugins.netbeans.org/plugin/38549 plugin])
*A StackOverflow [http://stackoverflow.com/questions/8705144/ide-with-refactoring-support-for-ruby-on-rails post] compares these tools ranking them as RubyMine being the best, followed by NetBeans, RadRails 2 and Aptana Studio 3

==Further Reading==
*[http://en.wikipedia.org/wiki/Code_smell Ways to identify problems in code]

*[http://blog.codeclimate.com/blog/2012/11/14/why-ruby-class-methods-resist-refactoring/ Resistance With Refactoring Ruby Class Methods]

*[http://www.railsinside.com/uncategorized/460-the-first-step-of-refactoring-a-rails-application.html Refactoring a Rails Application]

*[http://www.amazon.com/Rails-AntiPatterns-Refactoring-Addison-Wesley-Professional/dp/0321604814 Rails AntiPatterns: Best Practice Ruby on Rails Refactoring]

==References==
<references/>

CSC/ECE 517 Spring 2014/ch1a 1w1e rm

2014-02-11T00:58:51Z

Rjlloyd: /* Open Source Ruby Tools */

This page discusses refactoring techniques and metrics. It also includes tips on refactoring in Ruby and list of tools for automated refactoring.

==Background==
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, [http://en.wikipedia.org/wiki/Extensibility extensibility], and [http://en.wikipedia.org/wiki/Reusability reusability] of code.

Whether done through an [http://en.wikipedia.org/wiki/Integrated_development_environment 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.

==Refactoring Techniques==
Before a coder performs a refactor, they must, either formally or informally, identify their ‘code smells’. A code smell refers to a negative quality of a code base that either implements bad programming practices or slows down code development or runtime. These aren't typically bugs, but can increase the chance of bugs later on if not fixed. Based on the type of code smell, a different refactoring technique is used to fix it.

===Duplicate Code===
Duplicate code can be a tricky concept when refactoring. Large sections of duplicated code can be easy to find and fixed by pulling it out and creating a single centralized method to call, however it is usually not that easy. Sometimes it may only be one or two lines of code that are duplicated which calls for an assessment of whether or not it is in the best interest to create a new method for a couple lines of code. Other times, code is not duplicate, rather it is similar enough that a generic method could be created to serve various purposes.
Some specific techniques to deal with this are:
*Extract Method / Pull-up Method
**If common code is used in multiple places, simply pull it out and make a method that can be called from all of the necessary places. Variables can be passed in if slight variations are needed between calls.
**If the code is used in various subclasses, put the common code in a method in the superclass, so that it can be seen and called by it’s children.
**[http://www.refactoring.com/catalog/extractMethod.html Extract Method Example]

*Form Template Method
**If two methods in subclasses perform similar steps in the same order, but the steps are different, then get the steps into methods with the same signature, so that the original methods become the same. Then pull them up. <ref>http://www.refactoring.com/catalog/formTemplateMethod.html</ref>
**[http://www.integralist.co.uk/posts/refactoring-techniques/#form-template-method Form Template Method Example]

===Large Method/Class===
If a project is not planned out well enough in advance, it is easy for methods and classes to become populated with excess functionality. While the functionality may be necessary for the project, it might not be in the method or class.
*Extract Method
**This can be used when duplicate code occurs, as discussed above. But it can also be used when a method performs multiple functions that have the ability to be split up into various functions that serve a single purpose.
*Extract Class/Subclass/Superclass
**If there are class variables or methods that don’t directly pertain to a class, then it may be necessary to create a new class for those pieces.[http://www.refactoring.com/catalog/extractClass.html Example]
**If there are pieces of a class that are only for a specific subset of instances, then a subclass can be constructed to contain these.[http://www.refactoring.com/catalog/extractSubclass.html Example]
**If there are pieces that multiple classes use, then a superclass can be constructed to handle these generic functions, leaving the subclasses to deal with the remaining differences [http://www.refactoring.com/catalog/extractSuperclass.html Example]

===Improving Readability and Clarity===
Many times, refactoring can be used to do simple, yet necessary changes like renaming variables, methods, or classes. As features get added to a project, classes tend to get charged with more uses than originally planned, so sometimes, the original naming scheme no longer applies and a new one needs to be instilled.

Moving methods and parameters around to where they have the best accessibility also has its uses. Classes also tend to be promoted or demoted to super and sub classes after their ultimate functional purpose is determined.

===More Techniques===
There is an extensive list of coding smells that can be improved through refactoring.

A description of smells with their techniques exists [http://ghendry.net/refactor.html here].

A list of techniques with examples in Ruby are listed [http://www.refactoring.com/catalog/index.html here].

==Metrics==
It can be hard to decide whether or not to refactor, especially when it’s for something that appears to be working fine with just a surface level smell. Program analysis tools are used to derive various types of code metrics, which allow coders to identify problem areas and future pitfalls of their code base. These tools look at the code in several different ways, including the number of times a source file has been edited to help determine if it is a possible target of [feature envy], duplicate code structure to identify replicated lines, and block depths to suggest possible complexity issues.

===Open Source Ruby Metric Tools===
There are a variety of open source code metric tools that can be employed specifically for Ruby programs. [https://www.ruby-toolbox.com/categories/code_metrics The Ruby Toolbox] contains the most popular of these tools along with ratings.

[http://rubydoc.info/gems/simplecov/frames Simple Cov] is at the top of this list. It was developed specifically to be of use to anyone using any framework. It integrates itself with the project’s own test cases to check the code coverage of them in addition to cucumber features.

===Code Climate===
[https://codeclimate.com Code Climate] is a hosted code metrics tool that analyzes projects in a multitdue of ways. It produces three main metric ratings with grades from A-F that comprise of the methods and classes contained in each file and project.
====Complexity Metric====
This is based off of the Assignment, Branches, and Conditions ([http://c2.com/cgi/wiki?AbcMetric ABC]) metric, where the number of assignments, branches, and conditions are counted and analyzed. However, because Code Climate is constructed for Ruby programs, it also takes into account certain types of Ruby constructs that may increase the metric score, but are actually beneficial to the project.
====Duplication Metric====
This looks at the syntax trees of the code in order to identify identical and similar code structures. Because the syntax trees are being analyzed, code formatting and different method and class names do not affect the score. <ref>https://codeclimate.com/docs#quality-metrics</ref>

====Churn Method====
This integrates with the Git repository to look at the change history of the project’s files. Files with excessively high change histories have a tendency to have a high complexity rating as well, as they can be the result of feature envy, where extra functions are added into a file instead of being added to a new file with it’s own functionality.

==Getting Started with Refactoring in Ruby==

===First step: Writing tests===
The first step in refactoring is writing solid set of tests for the section of code under consideration, to avoid introducing bugs. In Ruby, this can be done using [http://www.ruby-doc.org/stdlib-2.1.0/libdoc/test/unit/rdoc/Test/Unit.html Test::Unit] or [http://rspec.info/ Rspec]. Next step is to make small changes, test, make small changes, test again and so on<ref name='Refactoring Ruby Edition'>http://www.amazon.com/Refactoring-Edition-Addison-Wesley-Professional-Series/dp/0321984137</ref>. This ensures that we can revert back to the working version of code if any small refactoring causes the application to stop working.

===When to refactor===
It is always confusing when to start refactoring. If either one of the following conditions is true, it is a good time to start refactoring code<ref name='Refactoring Ruby Edition'/>:
* The Rule of Three - If any code segment gives trouble more than two times, it is time to refactor it
* Adding new function - It might be helpful to refactor when adding new functionality as it would give better understanding of code. Sometimes, revisiting old design might help to accommodate new features better
* Fixing a bug - It is useful to refactor code which had a bug; this might save bug reports from the same piece of code in future
* During code review - Refactoring is useful during code reviews as it can be applied immediately making code reviews more fruitful
* Understanding other's code - If a new member joins the team and is asked to refactor existing code, it helps them to get a better understanding of the code base. It might take extra time to get them started, but trying to refactor will help them contribute to the project better in the long run.

A [http://blog.codeclimate.com/blog/2014/01/09/when-is-it-time-to-refactor/ CodeClimate blog] suggests some other conditions to decide when to refactor code.

===Refactoring fat models===
As more features get added to the application, the models tend to become bulkier. Such fat models cause maintenance issues. Refer [http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ CodeClimate blog] for 7 patterns to refactor such fat models.

===Refactoring views===
In this [https://speakerdeck.com/brianvh/refactoring-views-in-rails talk], Brian Hughes explains use of patterns to refactor views with bad code smells like use of conditionals or formatting data.

==Automated Code Refactoring==
=== RubyMine ===
*[http://www.jetbrains.com/ruby/webhelp/refactoring.html RubyMine] has a built in refactoring menu.
*To perform refactoring, select a code fragment to refactor. Refactorings available for your selection appear under the Refactor Menu in RubyMine. <ref>http://www.jetbrains.com/ruby/webhelp/refactoring-source-code.html#common</ref> [[File:RubyMine_refactoring_menu.png]]

===RFactor ===
*[http://fabiokung.com/2009/02/04/rfactor-ruby-refactoring-for-your-loved-editor/ RFactor] is a Ruby gem, which aims to provide common and simple refactorings for Ruby code for text editors like TextMate
*The first release has only Extract method implemented while other refactorings are coming soon
*It is available on [http://github.com/fabiokung/rfactor-tmbundle/tree/master GitHub]

=== Other IDEs ===
*Some other IDEs with built-in refactoring include [http://www.aptana.com/products/studio3 Aptana Studio], [http://www.aptana.com/products/radrails Aptana RadRails] and [https://netbeans.org/features/ruby/index.html NetBeans 7] (which requires Ruby and Rails [http://plugins.netbeans.org/plugin/38549 plugin])
*A StackOverflow [http://stackoverflow.com/questions/8705144/ide-with-refactoring-support-for-ruby-on-rails post] compares these tools ranking them as RubyMine being the best, followed by NetBeans, RadRails 2 and Aptana Studio 3

==Further Reading==
*[http://en.wikipedia.org/wiki/Code_smell Ways to identify problems in code]

*[http://blog.codeclimate.com/blog/2012/11/14/why-ruby-class-methods-resist-refactoring/ Resistance With Refactoring Ruby Class Methods]

*[http://www.railsinside.com/uncategorized/460-the-first-step-of-refactoring-a-rails-application.html Refactoring a Rails Application]

*[http://www.amazon.com/Rails-AntiPatterns-Refactoring-Addison-Wesley-Professional/dp/0321604814 Rails AntiPatterns: Best Practice Ruby on Rails Refactoring]

==References==
<references/>

CSC/ECE 517 Spring 2014/ch1a 1w1e rm

2014-02-10T08:03:32Z

Rjlloyd: /* Duplication Metric */

This page discusses how to elegantly refactor code, including several common metrics used in determining the potential quality of refactoring code, as well as which refactoring techniques to use in coordination with such metrics.

==Background==
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, [http://en.wikipedia.org/wiki/Extensibility extensibility], and [http://en.wikipedia.org/wiki/Reusability reusability] of code.

Whether done through an [http://en.wikipedia.org/wiki/Integrated_development_environment 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.

==Refactoring Techniques==
Before a coder performs a refactor, they must, either formally or informally, identify their ‘code smells’. A code smell refers to a negative quality of a code base that either implements bad programming practices or slows down code development or runtime. These aren’t typically bugs, but can increase the chance of bugs later on if not fixed. Based off of the type of code smell, a different refactoring technique is used to fix it.

===Duplicate Code===
Duplicate code can be a tricky concept when refactoring. Large sections of duplicated code can be easy to find and fixed by pulling it out and creating a single centralized method to call, however it is usually not that easy. Sometimes it may only be one or two lines of code that are duplicated which calls for an assessment of whether or not it is in the best interest to create a new method for a couple lines of code. Other times, code is not duplicate, rather it is similar enough that a generic method could be created to serve various purposes.
Some specific techniques to deal with this are:
*Extract Method / Pull-up Method
**If common code is used in multiple places, simply pull it out and make a method that can be called from all of the necessary places. Variables can be passed in if slight variations are needed between calls.
**If the code is used in various subclasses, put the common code in a method in the superclass, so that it can be seen and called by it’s children.
**[http://www.refactoring.com/catalog/extractMethod.html Extract Method Example]

*Form Template Method
**If two methods in subclasses perform similar steps in the same order, but the steps are different, then get the steps into methods with the same signature, so that the original methods become the same. Then pull them up. <ref>http://www.refactoring.com/catalog/formTemplateMethod.html</ref>
**[http://www.integralist.co.uk/posts/refactoring-techniques/#form-template-method Form Template Method Example]

===Large Method/Class===
If a project is not planned out well enough in advance, it is easy for methods and classes to become populated with excess functionality. While the functionality may be necessary for the project, it might not be in the method or class.
*Extract Method
**This can be used when duplicate code occurs, as discussed above. But it can also be used when a method performs multiple functions that have the ability to be split up into various functions that serve a single purpose.
*Extract Class/Subclass/Superclass
**If there are class variables or methods that don’t directly pertain to a class, then it may be necessary to create a new class for those pieces.[http://www.refactoring.com/catalog/extractClass.html Example]
**If there are pieces of a class that are only for a specific subset of instances, then a subclass can be constructed to contain these.[http://www.refactoring.com/catalog/extractSubclass.html Example]
**If there are pieces that multiple classes use, then a superclass can be constructed to handle these generic functions, leaving the subclasses to deal with the remaining differences [http://www.refactoring.com/catalog/extractSuperclass.html Example]

===Improving Readability and Clarity===
A lot of times, refactoring can be used to do simple, yet necessary changes like renaming variables, methods, or classes. As features get added to a project, classes tend to get charged with more uses than originally planned, so sometimes, the original naming scheme no longer applies and a new one needs to be instilled.

Moving methods and parameters around to where they have the best accessibility also has its uses. Classes also tend to be promoted or demoted to super and sub classes after their ultimate functional purpose is determined.

===More Techniques===
There is an extensive list of coding smells that can are able to be improved through refactoring.

A description of smells with their techniques exists [http://ghendry.net/refactor.html here].

A list of techniques with examples in Ruby are listed [http://www.refactoring.com/catalog/index.html here].

==Getting Started with Refactoring in Ruby==
The first step in refactoring is writing solid set of tests for that section of code to avoid introducing bugs. In Ruby, this can be done using [http://www.ruby-doc.org/stdlib-2.1.0/libdoc/test/unit/rdoc/Test/Unit.html Test::Unit] or [http://rspec.info/ Rspec]. Next step is to make small changes, test again, make small changes and so on. <ref>http://www.amazon.com/Refactoring-Edition-Addison-Wesley-Professional-Series/dp/0321984137</ref>

To start refactoring in Ruby, a [http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ CodeClimate blog] suggests 7 patterns to refactor fat models in Ruby:
# Extract Value Objects
# Extract Service Objects
# Extract Form Objects
# Extract Query Objects
# Introduce View Objects
# Extract Policy Objects
# Extract Decorators

It is always confusing when to start refactoring. If either one of the following conditions is true, it is a good time to start refactoring code:
* The Rule of Three
* When you add function
* When you need to fix a bug
* During code review,
* For greater understanding

A [http://blog.codeclimate.com/blog/2014/01/09/when-is-it-time-to-refactor/ CodeClimate blog] also suggests some other conditions to identify the need to refactor code.

=Metrics=
It can be hard to decide whether or not to refactor, especially when it’s for something that appears to be working fine with just a surface level smell. Program analysis tools are used to derive various types of code metrics, which allow coders to identify problem areas and future pitfalls of their code base. These tools look at the code in several different ways, including the number of times a source file has been edited to help determine if it is a possible target of [feature envy], duplicate code structure to identify replicated lines, and block depths to suggest possible complexity issues.

==Open Source Ruby Tools==
There are a variety of open source tools that can be employed specifically for Ruby programs. [https://www.ruby-toolbox.com/categories/code_metrics The Ruby Toolbox] contains the most popular of these tools along with ratings.

[http://rubydoc.info/gems/simplecov/frames Simple Cov] is at the top of this list. It was developed specifically to be of use to anyone using any framework. It integrates itself with the project’s own test cases to check the coverage of them in addition to cucumber features.

==Code Climate==
[https://codeclimate.com Code Climate] is a hosted code metrics tool that analyzes projects in a multitdue of ways. It produces three main metric ratings with grades from A-F that comprise of the methods and classes contained in each file and project.
===Complexity Metric===
This is based off of the Assignment, Branches, and Conditions ([http://c2.com/cgi/wiki?AbcMetric ABC]) metric, where the number of assignments, branches, and conditions are counted and analyzed. However, because Code Climate is constructed for Ruby programs, it also takes into account certain types of Ruby constructs that may increase the metric score, but are actually beneficial to the project.
===Duplication Metric===
This looks at the syntax trees of the code in order to identify identical and similar code structures. Because the syntax trees are being analyzed, code formatting and different method and class names do not affect the score. <ref>https://codeclimate.com/docs#quality-metrics</ref>

===Churn Method===
This integrates with the Git repository to look at the change history of the project’s files. Files with excessively high change histories have a tendency to have a high complexity rating as well, as they can be the result of feature envy, where extra functions are added into a file instead of being added to a new file with it’s own functionality.

=Automated Code Refactoring=
* [http://www.jetbrains.com/ruby/webhelp/refactoring.html RubyMine]
** RubyMine has a built in refactoring menu.
** Select a symbol or code fragment to refactor. Refactorings available for your selection appears. <ref>http://www.jetbrains.com/ruby/webhelp/refactoring-source-code.html#common</ref> [[File:RubyMine_refactoring_menu.png]]

* [http://fabiokung.com/2009/02/04/rfactor-ruby-refactoring-for-your-loved-editor/ RFactor]
** RFactor is a Ruby gem, which aims to provide common and simple refactorings for Ruby code for text editors like TextMate
** The first release has only Extract method implemented while other refactorings are coming soon
** It is available on [http://github.com/fabiokung/rfactor-tmbundle/tree/master GitHub]

* Some other IDEs with built-in refactoring include [http://www.aptana.com/products/studio3 Aptana Studio], [http://www.aptana.com/products/radrails Aptana RadRails] and [https://netbeans.org/features/ruby/index.html NetBeans 7] (which requires Ruby and Rails [http://plugins.netbeans.org/plugin/38549 plugin]).
** A StackOverflow [http://stackoverflow.com/questions/8705144/ide-with-refactoring-support-for-ruby-on-rails post] compares these tools ranking them as RubyMine being the best followed by NetBeans, RadRails 2 and Aptana Studio 3

=Further Reading=
*[http://en.wikipedia.org/wiki/Code_smell Ways to identify problems in code.]

*[http://blog.codeclimate.com/blog/2012/11/14/why-ruby-class-methods-resist-refactoring/ Resistance With Refactoring Ruby Class Methods]

*[http://www.railsinside.com/uncategorized/460-the-first-step-of-refactoring-a-rails-application.html Refactoring a Rails Application]

=References=
<references/>

CSC/ECE 517 Spring 2014/ch1a 1w1e rm

2014-02-10T08:02:58Z

Rjlloyd: /* Duplicate Code */

This page discusses how to elegantly refactor code, including several common metrics used in determining the potential quality of refactoring code, as well as which refactoring techniques to use in coordination with such metrics.

==Background==
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, [http://en.wikipedia.org/wiki/Extensibility extensibility], and [http://en.wikipedia.org/wiki/Reusability reusability] of code.

Whether done through an [http://en.wikipedia.org/wiki/Integrated_development_environment 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.

==Refactoring Techniques==
Before a coder performs a refactor, they must, either formally or informally, identify their ‘code smells’. A code smell refers to a negative quality of a code base that either implements bad programming practices or slows down code development or runtime. These aren’t typically bugs, but can increase the chance of bugs later on if not fixed. Based off of the type of code smell, a different refactoring technique is used to fix it.

===Duplicate Code===
Duplicate code can be a tricky concept when refactoring. Large sections of duplicated code can be easy to find and fixed by pulling it out and creating a single centralized method to call, however it is usually not that easy. Sometimes it may only be one or two lines of code that are duplicated which calls for an assessment of whether or not it is in the best interest to create a new method for a couple lines of code. Other times, code is not duplicate, rather it is similar enough that a generic method could be created to serve various purposes.
Some specific techniques to deal with this are:
*Extract Method / Pull-up Method
**If common code is used in multiple places, simply pull it out and make a method that can be called from all of the necessary places. Variables can be passed in if slight variations are needed between calls.
**If the code is used in various subclasses, put the common code in a method in the superclass, so that it can be seen and called by it’s children.
**[http://www.refactoring.com/catalog/extractMethod.html Extract Method Example]

*Form Template Method
**If two methods in subclasses perform similar steps in the same order, but the steps are different, then get the steps into methods with the same signature, so that the original methods become the same. Then pull them up. <ref>http://www.refactoring.com/catalog/formTemplateMethod.html</ref>
**[http://www.integralist.co.uk/posts/refactoring-techniques/#form-template-method Form Template Method Example]

===Large Method/Class===
If a project is not planned out well enough in advance, it is easy for methods and classes to become populated with excess functionality. While the functionality may be necessary for the project, it might not be in the method or class.
*Extract Method
**This can be used when duplicate code occurs, as discussed above. But it can also be used when a method performs multiple functions that have the ability to be split up into various functions that serve a single purpose.
*Extract Class/Subclass/Superclass
**If there are class variables or methods that don’t directly pertain to a class, then it may be necessary to create a new class for those pieces.[http://www.refactoring.com/catalog/extractClass.html Example]
**If there are pieces of a class that are only for a specific subset of instances, then a subclass can be constructed to contain these.[http://www.refactoring.com/catalog/extractSubclass.html Example]
**If there are pieces that multiple classes use, then a superclass can be constructed to handle these generic functions, leaving the subclasses to deal with the remaining differences [http://www.refactoring.com/catalog/extractSuperclass.html Example]

===Improving Readability and Clarity===
A lot of times, refactoring can be used to do simple, yet necessary changes like renaming variables, methods, or classes. As features get added to a project, classes tend to get charged with more uses than originally planned, so sometimes, the original naming scheme no longer applies and a new one needs to be instilled.

Moving methods and parameters around to where they have the best accessibility also has its uses. Classes also tend to be promoted or demoted to super and sub classes after their ultimate functional purpose is determined.

===More Techniques===
There is an extensive list of coding smells that can are able to be improved through refactoring.

A description of smells with their techniques exists [http://ghendry.net/refactor.html here].

A list of techniques with examples in Ruby are listed [http://www.refactoring.com/catalog/index.html here].

==Getting Started with Refactoring in Ruby==
The first step in refactoring is writing solid set of tests for that section of code to avoid introducing bugs. In Ruby, this can be done using [http://www.ruby-doc.org/stdlib-2.1.0/libdoc/test/unit/rdoc/Test/Unit.html Test::Unit] or [http://rspec.info/ Rspec]. Next step is to make small changes, test again, make small changes and so on. <ref>http://www.amazon.com/Refactoring-Edition-Addison-Wesley-Professional-Series/dp/0321984137</ref>

To start refactoring in Ruby, a [http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ CodeClimate blog] suggests 7 patterns to refactor fat models in Ruby:
# Extract Value Objects
# Extract Service Objects
# Extract Form Objects
# Extract Query Objects
# Introduce View Objects
# Extract Policy Objects
# Extract Decorators

It is always confusing when to start refactoring. If either one of the following conditions is true, it is a good time to start refactoring code:
* The Rule of Three
* When you add function
* When you need to fix a bug
* During code review,
* For greater understanding

A [http://blog.codeclimate.com/blog/2014/01/09/when-is-it-time-to-refactor/ CodeClimate blog] also suggests some other conditions to identify the need to refactor code.

=Metrics=
It can be hard to decide whether or not to refactor, especially when it’s for something that appears to be working fine with just a surface level smell. Program analysis tools are used to derive various types of code metrics, which allow coders to identify problem areas and future pitfalls of their code base. These tools look at the code in several different ways, including the number of times a source file has been edited to help determine if it is a possible target of [feature envy], duplicate code structure to identify replicated lines, and block depths to suggest possible complexity issues.

==Open Source Ruby Tools==
There are a variety of open source tools that can be employed specifically for Ruby programs. [https://www.ruby-toolbox.com/categories/code_metrics The Ruby Toolbox] contains the most popular of these tools along with ratings.

[http://rubydoc.info/gems/simplecov/frames Simple Cov] is at the top of this list. It was developed specifically to be of use to anyone using any framework. It integrates itself with the project’s own test cases to check the coverage of them in addition to cucumber features.

==Code Climate==
[https://codeclimate.com Code Climate] is a hosted code metrics tool that analyzes projects in a multitdue of ways. It produces three main metric ratings with grades from A-F that comprise of the methods and classes contained in each file and project.
===Complexity Metric===
This is based off of the Assignment, Branches, and Conditions ([http://c2.com/cgi/wiki?AbcMetric ABC]) metric, where the number of assignments, branches, and conditions are counted and analyzed. However, because Code Climate is constructed for Ruby programs, it also takes into account certain types of Ruby constructs that may increase the metric score, but are actually beneficial to the project.
===Duplication Metric===
This looks at the syntax trees of the code in order to identify identical and similar code structures. Because the syntax trees are being analyzed, code formatting and different method and class names do not affect the score. [https://codeclimate.com/docs#quality-metrics]
===Churn Method===
This integrates with the Git repository to look at the change history of the project’s files. Files with excessively high change histories have a tendency to have a high complexity rating as well, as they can be the result of feature envy, where extra functions are added into a file instead of being added to a new file with it’s own functionality.

=Automated Code Refactoring=
* [http://www.jetbrains.com/ruby/webhelp/refactoring.html RubyMine]
** RubyMine has a built in refactoring menu.
** Select a symbol or code fragment to refactor. Refactorings available for your selection appears. <ref>http://www.jetbrains.com/ruby/webhelp/refactoring-source-code.html#common</ref> [[File:RubyMine_refactoring_menu.png]]

* [http://fabiokung.com/2009/02/04/rfactor-ruby-refactoring-for-your-loved-editor/ RFactor]
** RFactor is a Ruby gem, which aims to provide common and simple refactorings for Ruby code for text editors like TextMate
** The first release has only Extract method implemented while other refactorings are coming soon
** It is available on [http://github.com/fabiokung/rfactor-tmbundle/tree/master GitHub]

* Some other IDEs with built-in refactoring include [http://www.aptana.com/products/studio3 Aptana Studio], [http://www.aptana.com/products/radrails Aptana RadRails] and [https://netbeans.org/features/ruby/index.html NetBeans 7] (which requires Ruby and Rails [http://plugins.netbeans.org/plugin/38549 plugin]).
** A StackOverflow [http://stackoverflow.com/questions/8705144/ide-with-refactoring-support-for-ruby-on-rails post] compares these tools ranking them as RubyMine being the best followed by NetBeans, RadRails 2 and Aptana Studio 3

=Further Reading=
*[http://en.wikipedia.org/wiki/Code_smell Ways to identify problems in code.]

*[http://blog.codeclimate.com/blog/2012/11/14/why-ruby-class-methods-resist-refactoring/ Resistance With Refactoring Ruby Class Methods]

*[http://www.railsinside.com/uncategorized/460-the-first-step-of-refactoring-a-rails-application.html Refactoring a Rails Application]

=References=
<references/>

CSC/ECE 517 Spring 2014/ch1a 1w1e rm

2014-02-10T08:02:17Z

Rjlloyd: /* References */

This page discusses how to elegantly refactor code, including several common metrics used in determining the potential quality of refactoring code, as well as which refactoring techniques to use in coordination with such metrics.

==Background==
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, [http://en.wikipedia.org/wiki/Extensibility extensibility], and [http://en.wikipedia.org/wiki/Reusability reusability] of code.

Whether done through an [http://en.wikipedia.org/wiki/Integrated_development_environment 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.

==Refactoring Techniques==
Before a coder performs a refactor, they must, either formally or informally, identify their ‘code smells’. A code smell refers to a negative quality of a code base that either implements bad programming practices or slows down code development or runtime. These aren’t typically bugs, but can increase the chance of bugs later on if not fixed. Based off of the type of code smell, a different refactoring technique is used to fix it.

===Duplicate Code===
Duplicate code can be a tricky concept when refactoring. Large sections of duplicated code can be easy to find and fixed by pulling it out and creating a single centralized method to call, however it is usually not that easy. Sometimes it may only be one or two lines of code that are duplicated which calls for an assessment of whether or not it is in the best interest to create a new method for a couple lines of code. Other times, code is not duplicate, rather it is similar enough that a generic method could be created to serve various purposes.
Some specific techniques to deal with this are:
*Extract Method / Pull-up Method
**If common code is used in multiple places, simply pull it out and make a method that can be called from all of the necessary places. Variables can be passed in if slight variations are needed between calls.
**If the code is used in various subclasses, put the common code in a method in the superclass, so that it can be seen and called by it’s children.
**[http://www.refactoring.com/catalog/extractMethod.html Extract Method Example]

*Form Template Method
**If two methods in subclasses perform similar steps in the same order, but the steps are different, then get the steps into methods with the same signature, so that the original methods become the same. Then pull them up. [http://www.refactoring.com/catalog/formTemplateMethod.html]
**[http://www.integralist.co.uk/posts/refactoring-techniques/#form-template-method Form Template Method Example]

===Large Method/Class===
If a project is not planned out well enough in advance, it is easy for methods and classes to become populated with excess functionality. While the functionality may be necessary for the project, it might not be in the method or class.
*Extract Method
**This can be used when duplicate code occurs, as discussed above. But it can also be used when a method performs multiple functions that have the ability to be split up into various functions that serve a single purpose.
*Extract Class/Subclass/Superclass
**If there are class variables or methods that don’t directly pertain to a class, then it may be necessary to create a new class for those pieces.[http://www.refactoring.com/catalog/extractClass.html Example]
**If there are pieces of a class that are only for a specific subset of instances, then a subclass can be constructed to contain these.[http://www.refactoring.com/catalog/extractSubclass.html Example]
**If there are pieces that multiple classes use, then a superclass can be constructed to handle these generic functions, leaving the subclasses to deal with the remaining differences [http://www.refactoring.com/catalog/extractSuperclass.html Example]

===Improving Readability and Clarity===
A lot of times, refactoring can be used to do simple, yet necessary changes like renaming variables, methods, or classes. As features get added to a project, classes tend to get charged with more uses than originally planned, so sometimes, the original naming scheme no longer applies and a new one needs to be instilled.

Moving methods and parameters around to where they have the best accessibility also has its uses. Classes also tend to be promoted or demoted to super and sub classes after their ultimate functional purpose is determined.

===More Techniques===
There is an extensive list of coding smells that can are able to be improved through refactoring.

A description of smells with their techniques exists [http://ghendry.net/refactor.html here].

A list of techniques with examples in Ruby are listed [http://www.refactoring.com/catalog/index.html here].

==Getting Started with Refactoring in Ruby==
The first step in refactoring is writing solid set of tests for that section of code to avoid introducing bugs. In Ruby, this can be done using [http://www.ruby-doc.org/stdlib-2.1.0/libdoc/test/unit/rdoc/Test/Unit.html Test::Unit] or [http://rspec.info/ Rspec]. Next step is to make small changes, test again, make small changes and so on. <ref>http://www.amazon.com/Refactoring-Edition-Addison-Wesley-Professional-Series/dp/0321984137</ref>

To start refactoring in Ruby, a [http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ CodeClimate blog] suggests 7 patterns to refactor fat models in Ruby:
# Extract Value Objects
# Extract Service Objects
# Extract Form Objects
# Extract Query Objects
# Introduce View Objects
# Extract Policy Objects
# Extract Decorators

It is always confusing when to start refactoring. If either one of the following conditions is true, it is a good time to start refactoring code:
* The Rule of Three
* When you add function
* When you need to fix a bug
* During code review,
* For greater understanding

A [http://blog.codeclimate.com/blog/2014/01/09/when-is-it-time-to-refactor/ CodeClimate blog] also suggests some other conditions to identify the need to refactor code.

=Metrics=
It can be hard to decide whether or not to refactor, especially when it’s for something that appears to be working fine with just a surface level smell. Program analysis tools are used to derive various types of code metrics, which allow coders to identify problem areas and future pitfalls of their code base. These tools look at the code in several different ways, including the number of times a source file has been edited to help determine if it is a possible target of [feature envy], duplicate code structure to identify replicated lines, and block depths to suggest possible complexity issues.

==Open Source Ruby Tools==
There are a variety of open source tools that can be employed specifically for Ruby programs. [https://www.ruby-toolbox.com/categories/code_metrics The Ruby Toolbox] contains the most popular of these tools along with ratings.

[http://rubydoc.info/gems/simplecov/frames Simple Cov] is at the top of this list. It was developed specifically to be of use to anyone using any framework. It integrates itself with the project’s own test cases to check the coverage of them in addition to cucumber features.

==Code Climate==
[https://codeclimate.com Code Climate] is a hosted code metrics tool that analyzes projects in a multitdue of ways. It produces three main metric ratings with grades from A-F that comprise of the methods and classes contained in each file and project.
===Complexity Metric===
This is based off of the Assignment, Branches, and Conditions ([http://c2.com/cgi/wiki?AbcMetric ABC]) metric, where the number of assignments, branches, and conditions are counted and analyzed. However, because Code Climate is constructed for Ruby programs, it also takes into account certain types of Ruby constructs that may increase the metric score, but are actually beneficial to the project.
===Duplication Metric===
This looks at the syntax trees of the code in order to identify identical and similar code structures. Because the syntax trees are being analyzed, code formatting and different method and class names do not affect the score. [https://codeclimate.com/docs#quality-metrics]
===Churn Method===
This integrates with the Git repository to look at the change history of the project’s files. Files with excessively high change histories have a tendency to have a high complexity rating as well, as they can be the result of feature envy, where extra functions are added into a file instead of being added to a new file with it’s own functionality.

=Automated Code Refactoring=
* [http://www.jetbrains.com/ruby/webhelp/refactoring.html RubyMine]
** RubyMine has a built in refactoring menu.
** Select a symbol or code fragment to refactor. Refactorings available for your selection appears. <ref>http://www.jetbrains.com/ruby/webhelp/refactoring-source-code.html#common</ref> [[File:RubyMine_refactoring_menu.png]]

* [http://fabiokung.com/2009/02/04/rfactor-ruby-refactoring-for-your-loved-editor/ RFactor]
** RFactor is a Ruby gem, which aims to provide common and simple refactorings for Ruby code for text editors like TextMate
** The first release has only Extract method implemented while other refactorings are coming soon
** It is available on [http://github.com/fabiokung/rfactor-tmbundle/tree/master GitHub]

* Some other IDEs with built-in refactoring include [http://www.aptana.com/products/studio3 Aptana Studio], [http://www.aptana.com/products/radrails Aptana RadRails] and [https://netbeans.org/features/ruby/index.html NetBeans 7] (which requires Ruby and Rails [http://plugins.netbeans.org/plugin/38549 plugin]).
** A StackOverflow [http://stackoverflow.com/questions/8705144/ide-with-refactoring-support-for-ruby-on-rails post] compares these tools ranking them as RubyMine being the best followed by NetBeans, RadRails 2 and Aptana Studio 3

=Further Reading=
*[http://en.wikipedia.org/wiki/Code_smell Ways to identify problems in code.]

*[http://blog.codeclimate.com/blog/2012/11/14/why-ruby-class-methods-resist-refactoring/ Resistance With Refactoring Ruby Class Methods]

*[http://www.railsinside.com/uncategorized/460-the-first-step-of-refactoring-a-rails-application.html Refactoring a Rails Application]

=References=
<references/>

CSC/ECE 517 Spring 2014/ch1a 1w1e rm

2014-02-10T08:02:08Z

Rjlloyd: /* Further Reading */

This page discusses how to elegantly refactor code, including several common metrics used in determining the potential quality of refactoring code, as well as which refactoring techniques to use in coordination with such metrics.

==Background==
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, [http://en.wikipedia.org/wiki/Extensibility extensibility], and [http://en.wikipedia.org/wiki/Reusability reusability] of code.

Whether done through an [http://en.wikipedia.org/wiki/Integrated_development_environment 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.

==Refactoring Techniques==
Before a coder performs a refactor, they must, either formally or informally, identify their ‘code smells’. A code smell refers to a negative quality of a code base that either implements bad programming practices or slows down code development or runtime. These aren’t typically bugs, but can increase the chance of bugs later on if not fixed. Based off of the type of code smell, a different refactoring technique is used to fix it.

===Duplicate Code===
Duplicate code can be a tricky concept when refactoring. Large sections of duplicated code can be easy to find and fixed by pulling it out and creating a single centralized method to call, however it is usually not that easy. Sometimes it may only be one or two lines of code that are duplicated which calls for an assessment of whether or not it is in the best interest to create a new method for a couple lines of code. Other times, code is not duplicate, rather it is similar enough that a generic method could be created to serve various purposes.
Some specific techniques to deal with this are:
*Extract Method / Pull-up Method
**If common code is used in multiple places, simply pull it out and make a method that can be called from all of the necessary places. Variables can be passed in if slight variations are needed between calls.
**If the code is used in various subclasses, put the common code in a method in the superclass, so that it can be seen and called by it’s children.
**[http://www.refactoring.com/catalog/extractMethod.html Extract Method Example]

*Form Template Method
**If two methods in subclasses perform similar steps in the same order, but the steps are different, then get the steps into methods with the same signature, so that the original methods become the same. Then pull them up. [http://www.refactoring.com/catalog/formTemplateMethod.html]
**[http://www.integralist.co.uk/posts/refactoring-techniques/#form-template-method Form Template Method Example]

===Large Method/Class===
If a project is not planned out well enough in advance, it is easy for methods and classes to become populated with excess functionality. While the functionality may be necessary for the project, it might not be in the method or class.
*Extract Method
**This can be used when duplicate code occurs, as discussed above. But it can also be used when a method performs multiple functions that have the ability to be split up into various functions that serve a single purpose.
*Extract Class/Subclass/Superclass
**If there are class variables or methods that don’t directly pertain to a class, then it may be necessary to create a new class for those pieces.[http://www.refactoring.com/catalog/extractClass.html Example]
**If there are pieces of a class that are only for a specific subset of instances, then a subclass can be constructed to contain these.[http://www.refactoring.com/catalog/extractSubclass.html Example]
**If there are pieces that multiple classes use, then a superclass can be constructed to handle these generic functions, leaving the subclasses to deal with the remaining differences [http://www.refactoring.com/catalog/extractSuperclass.html Example]

===Improving Readability and Clarity===
A lot of times, refactoring can be used to do simple, yet necessary changes like renaming variables, methods, or classes. As features get added to a project, classes tend to get charged with more uses than originally planned, so sometimes, the original naming scheme no longer applies and a new one needs to be instilled.

Moving methods and parameters around to where they have the best accessibility also has its uses. Classes also tend to be promoted or demoted to super and sub classes after their ultimate functional purpose is determined.

===More Techniques===
There is an extensive list of coding smells that can are able to be improved through refactoring.

A description of smells with their techniques exists [http://ghendry.net/refactor.html here].

A list of techniques with examples in Ruby are listed [http://www.refactoring.com/catalog/index.html here].

==Getting Started with Refactoring in Ruby==
The first step in refactoring is writing solid set of tests for that section of code to avoid introducing bugs. In Ruby, this can be done using [http://www.ruby-doc.org/stdlib-2.1.0/libdoc/test/unit/rdoc/Test/Unit.html Test::Unit] or [http://rspec.info/ Rspec]. Next step is to make small changes, test again, make small changes and so on. <ref>http://www.amazon.com/Refactoring-Edition-Addison-Wesley-Professional-Series/dp/0321984137</ref>

To start refactoring in Ruby, a [http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ CodeClimate blog] suggests 7 patterns to refactor fat models in Ruby:
# Extract Value Objects
# Extract Service Objects
# Extract Form Objects
# Extract Query Objects
# Introduce View Objects
# Extract Policy Objects
# Extract Decorators

It is always confusing when to start refactoring. If either one of the following conditions is true, it is a good time to start refactoring code:
* The Rule of Three
* When you add function
* When you need to fix a bug
* During code review,
* For greater understanding

A [http://blog.codeclimate.com/blog/2014/01/09/when-is-it-time-to-refactor/ CodeClimate blog] also suggests some other conditions to identify the need to refactor code.

=Metrics=
It can be hard to decide whether or not to refactor, especially when it’s for something that appears to be working fine with just a surface level smell. Program analysis tools are used to derive various types of code metrics, which allow coders to identify problem areas and future pitfalls of their code base. These tools look at the code in several different ways, including the number of times a source file has been edited to help determine if it is a possible target of [feature envy], duplicate code structure to identify replicated lines, and block depths to suggest possible complexity issues.

==Open Source Ruby Tools==
There are a variety of open source tools that can be employed specifically for Ruby programs. [https://www.ruby-toolbox.com/categories/code_metrics The Ruby Toolbox] contains the most popular of these tools along with ratings.

[http://rubydoc.info/gems/simplecov/frames Simple Cov] is at the top of this list. It was developed specifically to be of use to anyone using any framework. It integrates itself with the project’s own test cases to check the coverage of them in addition to cucumber features.

==Code Climate==
[https://codeclimate.com Code Climate] is a hosted code metrics tool that analyzes projects in a multitdue of ways. It produces three main metric ratings with grades from A-F that comprise of the methods and classes contained in each file and project.
===Complexity Metric===
This is based off of the Assignment, Branches, and Conditions ([http://c2.com/cgi/wiki?AbcMetric ABC]) metric, where the number of assignments, branches, and conditions are counted and analyzed. However, because Code Climate is constructed for Ruby programs, it also takes into account certain types of Ruby constructs that may increase the metric score, but are actually beneficial to the project.
===Duplication Metric===
This looks at the syntax trees of the code in order to identify identical and similar code structures. Because the syntax trees are being analyzed, code formatting and different method and class names do not affect the score. [https://codeclimate.com/docs#quality-metrics]
===Churn Method===
This integrates with the Git repository to look at the change history of the project’s files. Files with excessively high change histories have a tendency to have a high complexity rating as well, as they can be the result of feature envy, where extra functions are added into a file instead of being added to a new file with it’s own functionality.

=Automated Code Refactoring=
* [http://www.jetbrains.com/ruby/webhelp/refactoring.html RubyMine]
** RubyMine has a built in refactoring menu.
** Select a symbol or code fragment to refactor. Refactorings available for your selection appears. <ref>http://www.jetbrains.com/ruby/webhelp/refactoring-source-code.html#common</ref> [[File:RubyMine_refactoring_menu.png]]

* [http://fabiokung.com/2009/02/04/rfactor-ruby-refactoring-for-your-loved-editor/ RFactor]
** RFactor is a Ruby gem, which aims to provide common and simple refactorings for Ruby code for text editors like TextMate
** The first release has only Extract method implemented while other refactorings are coming soon
** It is available on [http://github.com/fabiokung/rfactor-tmbundle/tree/master GitHub]

* Some other IDEs with built-in refactoring include [http://www.aptana.com/products/studio3 Aptana Studio], [http://www.aptana.com/products/radrails Aptana RadRails] and [https://netbeans.org/features/ruby/index.html NetBeans 7] (which requires Ruby and Rails [http://plugins.netbeans.org/plugin/38549 plugin]).
** A StackOverflow [http://stackoverflow.com/questions/8705144/ide-with-refactoring-support-for-ruby-on-rails post] compares these tools ranking them as RubyMine being the best followed by NetBeans, RadRails 2 and Aptana Studio 3

=Further Reading=
*[http://en.wikipedia.org/wiki/Code_smell Ways to identify problems in code.]

*[http://blog.codeclimate.com/blog/2012/11/14/why-ruby-class-methods-resist-refactoring/ Resistance With Refactoring Ruby Class Methods]

*[http://www.railsinside.com/uncategorized/460-the-first-step-of-refactoring-a-rails-application.html Refactoring a Rails Application]

==References==
<references/>

CSC/ECE 517 Spring 2014/ch1a 1w1e rm

2014-02-10T08:00:24Z

Rjlloyd: /* Further Reading */

This page discusses how to elegantly refactor code, including several common metrics used in determining the potential quality of refactoring code, as well as which refactoring techniques to use in coordination with such metrics.

==Background==
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, [http://en.wikipedia.org/wiki/Extensibility extensibility], and [http://en.wikipedia.org/wiki/Reusability reusability] of code.

Whether done through an [http://en.wikipedia.org/wiki/Integrated_development_environment 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.

==Refactoring Techniques==
Before a coder performs a refactor, they must, either formally or informally, identify their ‘code smells’. A code smell refers to a negative quality of a code base that either implements bad programming practices or slows down code development or runtime. These aren’t typically bugs, but can increase the chance of bugs later on if not fixed. Based off of the type of code smell, a different refactoring technique is used to fix it.

===Duplicate Code===
Duplicate code can be a tricky concept when refactoring. Large sections of duplicated code can be easy to find and fixed by pulling it out and creating a single centralized method to call, however it is usually not that easy. Sometimes it may only be one or two lines of code that are duplicated which calls for an assessment of whether or not it is in the best interest to create a new method for a couple lines of code. Other times, code is not duplicate, rather it is similar enough that a generic method could be created to serve various purposes.
Some specific techniques to deal with this are:
*Extract Method / Pull-up Method
**If common code is used in multiple places, simply pull it out and make a method that can be called from all of the necessary places. Variables can be passed in if slight variations are needed between calls.
**If the code is used in various subclasses, put the common code in a method in the superclass, so that it can be seen and called by it’s children.
**[http://www.refactoring.com/catalog/extractMethod.html Extract Method Example]

*Form Template Method
**If two methods in subclasses perform similar steps in the same order, but the steps are different, then get the steps into methods with the same signature, so that the original methods become the same. Then pull them up. [http://www.refactoring.com/catalog/formTemplateMethod.html]
**[http://www.integralist.co.uk/posts/refactoring-techniques/#form-template-method Form Template Method Example]

===Large Method/Class===
If a project is not planned out well enough in advance, it is easy for methods and classes to become populated with excess functionality. While the functionality may be necessary for the project, it might not be in the method or class.
*Extract Method
**This can be used when duplicate code occurs, as discussed above. But it can also be used when a method performs multiple functions that have the ability to be split up into various functions that serve a single purpose.
*Extract Class/Subclass/Superclass
**If there are class variables or methods that don’t directly pertain to a class, then it may be necessary to create a new class for those pieces.[http://www.refactoring.com/catalog/extractClass.html Example]
**If there are pieces of a class that are only for a specific subset of instances, then a subclass can be constructed to contain these.[http://www.refactoring.com/catalog/extractSubclass.html Example]
**If there are pieces that multiple classes use, then a superclass can be constructed to handle these generic functions, leaving the subclasses to deal with the remaining differences [http://www.refactoring.com/catalog/extractSuperclass.html Example]

===Improving Readability and Clarity===
A lot of times, refactoring can be used to do simple, yet necessary changes like renaming variables, methods, or classes. As features get added to a project, classes tend to get charged with more uses than originally planned, so sometimes, the original naming scheme no longer applies and a new one needs to be instilled.

Moving methods and parameters around to where they have the best accessibility also has its uses. Classes also tend to be promoted or demoted to super and sub classes after their ultimate functional purpose is determined.

===More Techniques===
There is an extensive list of coding smells that can are able to be improved through refactoring.

A description of smells with their techniques exists [http://ghendry.net/refactor.html here].

A list of techniques with examples in Ruby are listed [http://www.refactoring.com/catalog/index.html here].

==Getting Started with Refactoring in Ruby==
The first step in refactoring is writing solid set of tests for that section of code to avoid introducing bugs. In Ruby, this can be done using [http://www.ruby-doc.org/stdlib-2.1.0/libdoc/test/unit/rdoc/Test/Unit.html Test::Unit] or [http://rspec.info/ Rspec]. Next step is to make small changes, test again, make small changes and so on. <ref>http://www.amazon.com/Refactoring-Edition-Addison-Wesley-Professional-Series/dp/0321984137</ref>

To start refactoring in Ruby, a [http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ CodeClimate blog] suggests 7 patterns to refactor fat models in Ruby:
# Extract Value Objects
# Extract Service Objects
# Extract Form Objects
# Extract Query Objects
# Introduce View Objects
# Extract Policy Objects
# Extract Decorators

It is always confusing when to start refactoring. If either one of the following conditions is true, it is a good time to start refactoring code:
* The Rule of Three
* When you add function
* When you need to fix a bug
* During code review,
* For greater understanding

A [http://blog.codeclimate.com/blog/2014/01/09/when-is-it-time-to-refactor/ CodeClimate blog] also suggests some other conditions to identify the need to refactor code.

=Metrics=
It can be hard to decide whether or not to refactor, especially when it’s for something that appears to be working fine with just a surface level smell. Program analysis tools are used to derive various types of code metrics, which allow coders to identify problem areas and future pitfalls of their code base. These tools look at the code in several different ways, including the number of times a source file has been edited to help determine if it is a possible target of [feature envy], duplicate code structure to identify replicated lines, and block depths to suggest possible complexity issues.

==Open Source Ruby Tools==
There are a variety of open source tools that can be employed specifically for Ruby programs. [https://www.ruby-toolbox.com/categories/code_metrics The Ruby Toolbox] contains the most popular of these tools along with ratings.

[http://rubydoc.info/gems/simplecov/frames Simple Cov] is at the top of this list. It was developed specifically to be of use to anyone using any framework. It integrates itself with the project’s own test cases to check the coverage of them in addition to cucumber features.

==Code Climate==
[https://codeclimate.com Code Climate] is a hosted code metrics tool that analyzes projects in a multitdue of ways. It produces three main metric ratings with grades from A-F that comprise of the methods and classes contained in each file and project.
===Complexity Metric===
This is based off of the Assignment, Branches, and Conditions ([http://c2.com/cgi/wiki?AbcMetric ABC]) metric, where the number of assignments, branches, and conditions are counted and analyzed. However, because Code Climate is constructed for Ruby programs, it also takes into account certain types of Ruby constructs that may increase the metric score, but are actually beneficial to the project.
===Duplication Metric===
This looks at the syntax trees of the code in order to identify identical and similar code structures. Because the syntax trees are being analyzed, code formatting and different method and class names do not affect the score. [https://codeclimate.com/docs#quality-metrics]
===Churn Method===
This integrates with the Git repository to look at the change history of the project’s files. Files with excessively high change histories have a tendency to have a high complexity rating as well, as they can be the result of feature envy, where extra functions are added into a file instead of being added to a new file with it’s own functionality.

=Automated Code Refactoring=
* [http://www.jetbrains.com/ruby/webhelp/refactoring.html RubyMine]
** RubyMine has a built in refactoring menu.
** Select a symbol or code fragment to refactor. Refactorings available for your selection appears. <ref>http://www.jetbrains.com/ruby/webhelp/refactoring-source-code.html#common</ref> [[File:RubyMine_refactoring_menu.png]]

* [http://fabiokung.com/2009/02/04/rfactor-ruby-refactoring-for-your-loved-editor/ RFactor]
** RFactor is a Ruby gem, which aims to provide common and simple refactorings for Ruby code for text editors like TextMate
** The first release has only Extract method implemented while other refactorings are coming soon
** It is available on [http://github.com/fabiokung/rfactor-tmbundle/tree/master GitHub]

* Some other IDEs with built-in refactoring include [http://www.aptana.com/products/studio3 Aptana Studio], [http://www.aptana.com/products/radrails Aptana RadRails] and [https://netbeans.org/features/ruby/index.html NetBeans 7] (which requires Ruby and Rails [http://plugins.netbeans.org/plugin/38549 plugin]).
** A StackOverflow [http://stackoverflow.com/questions/8705144/ide-with-refactoring-support-for-ruby-on-rails post] compares these tools ranking them as RubyMine being the best followed by NetBeans, RadRails 2 and Aptana Studio 3

==Further Reading==
*[http://en.wikipedia.org/wiki/Code_smell Ways to identify problems in code.]

*[http://blog.codeclimate.com/blog/2012/11/14/why-ruby-class-methods-resist-refactoring/ Resistance With Refactoring Ruby Class Methods]

*[http://www.railsinside.com/uncategorized/460-the-first-step-of-refactoring-a-rails-application.html Refactoring a Rails Application]

==References==
<references/>