--- a/fe640f31-c6b5-435d-b7b7-28ff9d1fd598/index.rst	Tue Oct 16 04:11:33 2018 +0300
+++ b/fe640f31-c6b5-435d-b7b7-28ff9d1fd598/index.rst	Mon Oct 22 23:46:48 2018 +0300
@@ -8,7 +8,7 @@
 
 Developers tend to indent code just because of null check.
 
-Lets look to ``jQuery`` library code::
+Let's look to ``jQuery`` library code::
 
     makeArray: function( arr, results ) {
         var ret = results || [];
@@ -46,7 +46,8 @@
         return ret;
     }
 
-The case ``arr == null`` is not important! Resulted code have guarding part and main execution part.
+The case ``arr == null`` is not so important to distract our attention with 4 spaces indent!
+Resulted code has guarding part and main execution part.
 
 Consider following code::
 
@@ -58,8 +59,8 @@
         return false;
     }
 
-Again above code mix recursion with final leaves. Instead final leaves should be at the beginning
-and recursion should be clearly visible::
+Above code mixes recursion call with terminal values. Let's place recursion as final part of
+function (making it suitable for tail resursion optimization)::
 
     public static boolean findCause(Throwable t, Class <? extends Exception> cl) {
         if (cl.isInstance(t))
@@ -70,7 +71,7 @@
         return findCause(t.getCause(), cl);
     }
 
-or better without recursion::
+Or better eliminate recursion::
 
     public static boolean findCause(Throwable t, Class <? extends Exception> cl) {
         do {
@@ -97,34 +98,31 @@
 
 I think that this is a faulty practice.
 
-At first sight it looks like explicit checks for proper state are more meaningful then checks for
+On first sight it looks like explicit checks for proper state are more meaningful then checks for
 malformed or undesired state.
 
 Putting main execution flow inside several ``if`` means that your main code will have several levels
 of indenting. Indenting is an indicator of more specialized, detailed code that at brief look should
 be ignored.
 
-But more important, the way of thinking during code review and troubleshooting lays in getting rid
-of undesired states that may lead to operation on unintended state.
+And more important, during code review and debugging you quickly movee your attention from
+pre-conditions to main execution flow.
 
 I think that code should detect problems and interrupt execution (or move to processing next portion
 of information).
 
-By using early checks with interruption of exection you guaranty that next code will operate with
-proper incoming state.
+By using early checks with interruption of exection you guaranty that following code will operate
+with proper incoming state.
 
-And you don't need to guard checks itself. Instead of::
+You even don't need to guard checks itself. Instead of::
 
   if (obj != null && obj.getInternal != null) { ... }
 
 use::
 
-  if (obj == null)
-      return;
-  if (obj.getInternal == null)
-      return;
+  if (obj == null)             return;
+  if (obj.getInternal == null) return;
   ...
 
-You are eliminating checks nesting and allowing sequencing of checks without code indenting. All
-code will lay on the same level!
+All the code lays on the same level!