Minor fixes

README.md

@@ -71,6 +71,7 @@ guide for the benefit of the entire Ruby community.
 ## Syntax
 
 * Use **def** with parentheses when there are arguments. Omit the parentheses when the method doesn't accept any arguments.
+
         def some_method
           # body omitted
         end
@@ -80,6 +81,7 @@ guide for the benefit of the entire Ruby community.
         end
 
 * Never use **for**, unless you exactly know why. Most of the time iterators should be used instead.
+
         arr = [1, 2, 3]
 
         # bad
@@ -107,6 +109,7 @@ guide for the benefit of the entire Ruby community.
   wrong operators.)
 * Avoid multiline ?: (the ternary operator), use **if/unless** instead.
 * Favor modifier **if/unless** usage when you have a single-line body.
+
         # bad
         if some_condition
           do_something
@@ -119,6 +122,7 @@ guide for the benefit of the entire Ruby community.
         some_condition && do_something
 
 * Favor **unless** over **if** for negative conditions:
+
         # bad
         do_something if !some_condition
 
@@ -127,9 +131,11 @@ guide for the benefit of the entire Ruby community.
 
         # another good option
         some_condition || do_something
+
 * Suppress superfluous parentheses when calling methods, but keep them
   when calling "functions", i.e. when you use the return value in the
   same line.
+
         x = Math.sin(y)
         array.delete e
 
@@ -197,9 +203,11 @@ guide for the benefit of the entire Ruby community.
 
 * When using **inject** with short blocks, name the arguments **|a, e|** (mnemonic: accumulator, element)
 * When defining binary operators, name the argument "other".
+
         def +(other)
           # body omitted
         end
+
 * Prefer **map** over *collect*, **find** over *detect*, **find_all** over *select*, **size** over *length*. This is not a hard requirement, though - if
 the use of the alias enhances readability - it's ok to use it.
 
@@ -249,7 +257,7 @@ the use of the alias enhances readability - it's ok to use it.
 * Keep the code simple (subjective, but still...). Each method should have a single well-defined responsibility.
 * Avoid more than 3 Level of  block nesting.
 * Don't overdesign. Overly complex solutions tend to be brittle and hard to maintain.
-* Don't underdesign. A solution to a problem should be as simple as possible... but it should be simpler than that. Poor initial design 
+* Don't underdesign. A solution to a problem should be as simple as possible... but it should not be simpler than that. Poor initial design 
 can lead to a lot of problems in the future.
 * Be consistent. In an ideal world - be consistent with the points listed here in this guidelines.
 * Use common sense.