diff --git a/Coding-Standards.md b/Coding-Standards.md
index ef667b6..6b86ace 100644
--- a/Coding-Standards.md
+++ b/Coding-Standards.md
@@ -3,20 +3,16 @@
 
 All user-facing strings/text must be wrapped in the `__("")` function in javascript and `_("")` function in Python, so that it is shown as translated to the user.
 
-### Avoid using Deprecated API
-
-The API used in the pull request must be the latest recommended methods and usage of globals like `cur_frm` must be avoided.
-
-Examples:
-- `$c_obj()`
-- `cur_frm`
-- `get_query`
-- `add_fetch`
-
 ### Break functions/methods more than 10 lines of code
 
 Long functions are hard to read and debug, and 10 lines is usually a good point to break the function into smaller parts. Smaller functions are easy to read and review. You might even want to convert a series of functions into a class so you don't need to pass parameters through all of them.
 
+As Steve Mcconnell and Bob Martin say (two pretty good references on coding best practices), a method should do one thing and only one thing. However many lines of code it takes to do that one thing is how many lines it should have. If that "one thing" can be broken into smaller things, each of those should have a method. Good clues your method is doing more than one thing:
+- More than one level of indention in a method (indicates too many logic branches to only be doing one thing)
+- "Paragraph Breaks" - whitespace between logical groups of code indicate the method is doing more than one thing
+
+[Reference](https://stackoverflow.com/questions/611304/how-many-lines-of-code-should-a-function-procedure-method-have)
+
 ### Use simple indenting
 
 The ERPNext and Frappe Project uses tabs (I know and we are sorry, but its too much effort to change it now and we don't want to lose the history). The indentation must be consistent whether you are writing Javascript or Python. Multi-line strings or expressions must also be consistently indented, not hanging like a bee hive at the end of the line. We just think the code looks a lot more stable that way.
@@ -77,9 +73,15 @@ While we believe that code should be written in a self-explanatory way, comments
 
 We don't expect heavily commented code, but some explanation of what a method does is required. [Read this post](http://antirez.com/news/124) on why code commenting is important.
 
-### Don't Delete Test Data
+### Avoid using Deprecated API
 
-Don't delete test data, specially fixtures while writing tests. If you want, create new fixtures and delete them.
+The API used in the pull request must be the latest recommended methods and usage of globals like `cur_frm` must be avoided.
+
+Examples:
+- `$c_obj()`
+- `cur_frm`
+- `get_query`
+- `add_fetch`
 
 ### Tabs, not spaces