FullStackNoob · February 21, 2017 20:21 · Nov 24, 2014 · Nov 24, 2014 · Nov 24, 2014 · Nov 24, 2014
diff --git a/CodeSmells.md b/CodeSmells.md
@@ -71,4 +71,5 @@ Some Examples and Tools that can help
 - http://robots.thoughtbot.com/tell-dont-ask
 - http://thoughtbot.com/ruby-science-sample.pdf
 - http://blog.codinghorror.com/code-smells/
-- http://sourcemaking.com/refactoring/extract-class
+- http://sourcemaking.com/refactoring/extract-class
+- https://github.com/troessner/reek/wiki/Code-Smells
diff --git a/CodeSmells.md b/CodeSmells.md
@@ -70,4 +70,5 @@ Some Examples and Tools that can help
 - http://opensoul.org/2012/05/23/why-our-code-smells/
 - http://robots.thoughtbot.com/tell-dont-ask
 - http://thoughtbot.com/ruby-science-sample.pdf
-- http://blog.codinghorror.com/code-smells/
+- http://blog.codinghorror.com/code-smells/
+- http://sourcemaking.com/refactoring/extract-class
diff --git a/CodeSmells.md b/CodeSmells.md
@@ -62,6 +62,7 @@ Common code smells
 
 Some Examples and Tools that can help
 ----------------------
+- https://github.com/ga-wdi-boston/wdi_10_design_patterns_refactoring
 - https://www.infinum.co/the-capsized-eight/articles/top-8-tools-for-ruby-on-rails-code-optimization-and-cleanup
 - http://rails-bestpractices.com/
 - http://c2.com/cgi/wiki?CodeSmell

diff --git a/CodeSmells.md b/CodeSmells.md
@@ -60,12 +60,13 @@ Common code smells
 - `the_method(a,b,c,d,e,f,g,h)` is probably doing more than it needs to.
 - Check to make sure that you're actually using 
 
-Some Tools
+Some Examples and Tools that can help
 ----------------------
 - https://www.infinum.co/the-capsized-eight/articles/top-8-tools-for-ruby-on-rails-code-optimization-and-cleanup
 - http://rails-bestpractices.com/
 - http://c2.com/cgi/wiki?CodeSmell
 - http://ghendry.net/refactor.html
 - http://opensoul.org/2012/05/23/why-our-code-smells/
 - http://robots.thoughtbot.com/tell-dont-ask
-- http://thoughtbot.com/ruby-science-sample.pdf
+- http://thoughtbot.com/ruby-science-sample.pdf
+- http://blog.codinghorror.com/code-smells/
diff --git a/CodeSmells.md b/CodeSmells.md
@@ -9,54 +9,54 @@ The cost of maintaining code as it increases in complexity and features becomes
 
 Common code smells 
 ---------------------
-Long Methods
+### Long Methods
 - Chances are if your method is too long it's doing too much or is too complex. 
 - If your method is doing more than exactly one thing, it's doing too much. Break it down into seperate methods or out to it's own class.
 
 
-Duplicate code 
+### Duplicate code 
 - Lets say there's a regex method for breaking down and checking a string... in half of a class's methods. Pull it out! 
 - Make it it's own method and call when neccesary. 
 - When you write something more than once chances are you need to extract it.
 
-Fat Controllers
+### Fat Controllers
 - This is a very easy one to solve. If your controllers do anything other than settign instance varibles or rendering something it's probably doing too much and the rest of the methods should be extracted to a model or helper class. 
 
-Poorly Named
+### Poorly Named
 - If your methods can't be clearly named, it suggests that what the method is doing is too complex for a single method. Or that you suck at naming. Either way it's something to check for. 
 
-Large Classes
+### Large Classes
 - or God classes typically are the fatest models in your app and are usually something that has access to most of the app (*cough* User Class *cough*) 
 - This class has a terrible habit of collecting all the methods that really belong in a helper module or static class. 
 - Ideally every class should try to solve one type of problem.  
 
-Feature Envy
+### Feature Envy
 - When a single class excessively calls other classes methods, your code is probably very brittle. It has become reliant on other classes and is difficult to understand or change without breaking anything.
 - This class is too closely coupled with other classes and it should be more isolate for the benefit of the code base. 
 
-Attribute Abuse
+### Attribute Abuse
 - When you rely too heavily on attribute getters and setters for logic you run the risk of breaking something should those variables ever need to change
 - If you find that you're using the getters to ever check the state of an object ( maybe you're checking whether or not something is public or a certain length every so often) then you should write a method for that object called public? or long_enough? that return true or false.
 
-Primitive obsession
+### Primitive obsession
 - This is most common when you use things like strings or floats to represent time or currency. 
 - These should really be thier own objects like Date, Address, or Currency. This way we don't have to perform some string manipulation or 
 
-Nested Iterators
+### Nested Iterators
 - Blocks on Blocks on Blocks. Pretty clearly too complex. At this point you should be asking yourself why you need to parse through a data set and if they should be so made more distinct or seperated entirely. 
 
-Unused Code
+### Unused Code
 - Code that is rarely or never used is taking too much space
 - Sometimes this mean that these methods could belong to somewhere else and solve problems before even getting to where the unused code is.
 - Don't worry too much about deleting methods. If we ever find we need them again we can just check git. 
 
-Highly coupled class
+### Highly coupled class
 - This class has too many methods that rely on each other. Methods have too much dependency on other methods behaviors.
 
-Lazy/ freeloader classes
+### Lazy/ freeloader classes
 - This class isn't doin enough. It means that too much of the complexity is split into multiple classes.
 
-Too Many Parameters 
+### Too Many Parameters 
 - `the_method(a,b,c,d,e,f,g,h)` is probably doing more than it needs to.
 - Check to make sure that you're actually using 
 

diff --git a/Code Smells → CodeSmells.md b/Code Smells → CodeSmells.md
@@ -67,4 +67,5 @@ Some Tools
 - http://c2.com/cgi/wiki?CodeSmell
 - http://ghendry.net/refactor.html
 - http://opensoul.org/2012/05/23/why-our-code-smells/
-- http://robots.thoughtbot.com/tell-dont-ask
+- http://robots.thoughtbot.com/tell-dont-ask
+- http://thoughtbot.com/ruby-science-sample.pdf
diff --git a/Code Smells b/Code Smells
@@ -12,17 +12,7 @@ Common code smells
 Long Methods
 - Chances are if your method is too long it's doing too much or is too complex. 
 - If your method is doing more than exactly one thing, it's doing too much. Break it down into seperate methods or out to it's own class.
-`
-def long_method
-  if object.isFun?
-    have_fun
-  elsif object.isTall?
-    tall_things
-  elseif object.isMe?
-    who_method
-  end
-end
-`
+
 
 Duplicate code 
 - Lets say there's a regex method for breaking down and checking a string... in half of a class's methods. Pull it out! 

diff --git a/Code Smells b/Code Smells
@@ -0,0 +1,80 @@
+Code Smells 
+===============
+
+Code Smells are paterns that we commonly fall into when building a code base for our project. They're troublesome bits of code and habits that can cause problems as your code base increase in size and complexity. However it's important to know code smells are realy just hints or pointers that something might be wrong.
+
+Why is it important to be aware of code smells?
+----------------------------
+The cost of maintaining code as it increases in complexity and features becomes more difficult and as code grows these smell patterns can take root in your code base and if not monitored they can turn your code into a brittle tangle of difficult to understand methods and classes. Monitoring code smells as part of your work routines refactoring can save you time and money as your code base continues to grow. 
+
+Common code smells 
+---------------------
+Long Methods
+- Chances are if your method is too long it's doing too much or is too complex. 
+- If your method is doing more than exactly one thing, it's doing too much. Break it down into seperate methods or out to it's own class.
+`
+def long_method
+  if object.isFun?
+    have_fun
+  elsif object.isTall?
+    tall_things
+  elseif object.isMe?
+    who_method
+  end
+end
+`
+
+Duplicate code 
+- Lets say there's a regex method for breaking down and checking a string... in half of a class's methods. Pull it out! 
+- Make it it's own method and call when neccesary. 
+- When you write something more than once chances are you need to extract it.
+
+Fat Controllers
+- This is a very easy one to solve. If your controllers do anything other than settign instance varibles or rendering something it's probably doing too much and the rest of the methods should be extracted to a model or helper class. 
+
+Poorly Named
+- If your methods can't be clearly named, it suggests that what the method is doing is too complex for a single method. Or that you suck at naming. Either way it's something to check for. 
+
+Large Classes
+- or God classes typically are the fatest models in your app and are usually something that has access to most of the app (*cough* User Class *cough*) 
+- This class has a terrible habit of collecting all the methods that really belong in a helper module or static class. 
+- Ideally every class should try to solve one type of problem.  
+
+Feature Envy
+- When a single class excessively calls other classes methods, your code is probably very brittle. It has become reliant on other classes and is difficult to understand or change without breaking anything.
+- This class is too closely coupled with other classes and it should be more isolate for the benefit of the code base. 
+
+Attribute Abuse
+- When you rely too heavily on attribute getters and setters for logic you run the risk of breaking something should those variables ever need to change
+- If you find that you're using the getters to ever check the state of an object ( maybe you're checking whether or not something is public or a certain length every so often) then you should write a method for that object called public? or long_enough? that return true or false.
+
+Primitive obsession
+- This is most common when you use things like strings or floats to represent time or currency. 
+- These should really be thier own objects like Date, Address, or Currency. This way we don't have to perform some string manipulation or 
+
+Nested Iterators
+- Blocks on Blocks on Blocks. Pretty clearly too complex. At this point you should be asking yourself why you need to parse through a data set and if they should be so made more distinct or seperated entirely. 
+
+Unused Code
+- Code that is rarely or never used is taking too much space
+- Sometimes this mean that these methods could belong to somewhere else and solve problems before even getting to where the unused code is.
+- Don't worry too much about deleting methods. If we ever find we need them again we can just check git. 
+
+Highly coupled class
+- This class has too many methods that rely on each other. Methods have too much dependency on other methods behaviors.
+
+Lazy/ freeloader classes
+- This class isn't doin enough. It means that too much of the complexity is split into multiple classes.
+
+Too Many Parameters 
+- `the_method(a,b,c,d,e,f,g,h)` is probably doing more than it needs to.
+- Check to make sure that you're actually using 
+
+Some Tools
+----------------------
+- https://www.infinum.co/the-capsized-eight/articles/top-8-tools-for-ruby-on-rails-code-optimization-and-cleanup
+- http://rails-bestpractices.com/
+- http://c2.com/cgi/wiki?CodeSmell
+- http://ghendry.net/refactor.html
+- http://opensoul.org/2012/05/23/why-our-code-smells/
+- http://robots.thoughtbot.com/tell-dont-ask