changeset 123:400c46fe348c

Don't indent code due to error checking!
author Oleksandr Gavenko <gavenkoa@gmail.com>
date Mon, 27 Mar 2017 20:42:50 +0300
parents 2fea753a51ff
children 368af08056e7
files 631f6b21-01b6-4d50-8e0f-13f59bd66fc2/index.rst fe640f31-c6b5-435d-b7b7-28ff9d1fd598/index.rst
diffstat 2 files changed, 117 insertions(+), 22 deletions(-) [+]
line wrap: on
line diff
--- a/631f6b21-01b6-4d50-8e0f-13f59bd66fc2/index.rst	Mon Mar 27 20:42:26 2017 +0300
+++ b/631f6b21-01b6-4d50-8e0f-13f59bd66fc2/index.rst	Mon Mar 27 20:42:50 2017 +0300
@@ -6,28 +6,6 @@
 :updated: 2017-03-26
 :tags: java, lang
 
-Many programmers put main execution flow inside several levels of "if" statements that guard against
-violation of processing pre-conditions.
-
-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
-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.
-
-I think that code should detect problems and interrupt execution (or move to processing next portion
-of information).
-
-Using interruptions you guaranty that next code will operate with proper incoming state. And you
-don't need to guard checks, eliminating checks nesting and allowing sequencing checks without
-code indenting. All code will lay on the same level!
-
 Maintaining code with checks first and keeping all on single level can be tricky because language
 designers don't worried about such use case.
 
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/fe640f31-c6b5-435d-b7b7-28ff9d1fd598/index.rst	Mon Mar 27 20:42:50 2017 +0300
@@ -0,0 +1,117 @@
+
+==========================================
+ Don't indent code due to error checking!
+==========================================
+:created: 2017-03-27 21:00
+:updated: 2017-03-27
+
+Developer tend to indent code just because of ``x != null`` check.
+
+Lets look to ``jQuery`` library::
+
+    makeArray: function( arr, results ) {
+        var ret = results || [];
+
+        if ( arr != null ) {
+            if ( isArraylike( Object(arr) ) ) {
+                jQuery.merge( ret,
+                    typeof arr === "string" ?
+                    [ arr ] : arr
+                );
+            } else {
+                core_push.call( ret, arr );
+            }
+        }
+
+        return ret;
+    }
+
+That's a shame!
+
+Code should look like::
+
+    makeArray: function( arr, results ) {
+        var ret = results || [];
+
+        if ( arr == null )
+            return ret;
+
+        if ( isArraylike( Object(arr) ) ) {
+            jQuery.merge( ret,
+                typeof arr === "string" ? [ arr ] : arr
+            );
+        } else {
+            core_push.call( ret, arr );
+        }
+
+        return ret;
+    }
+
+The case ``arr == null`` is not important!
+
+Consider following code::
+
+    public static boolean findCause(Throwable t, Class <? extends Exception> cl) {
+        if (cl.isInstance(t))
+            return true;
+        if (t.getCause() != null)
+            return findCause(t.getCause(), cl);
+        return false;
+    }
+
+Again above code mix recursion with final leaves. Instead final leaves should be at the beginning
+and recursion should be clearly visible::
+
+    public static boolean findCause(Throwable t, Class <? extends Exception> cl) {
+        if (cl.isInstance(t))
+            return true;
+        if (t.getCause() == null)
+           return false;
+
+        return findCause(t.getCause(), cl);
+    }
+
+or better without recursion::
+
+    public static boolean findCause(Throwable t, Class <? extends Exception> cl) {
+        do {
+            if (cl.isInstance(t))
+                return true;
+            t = t.getCause();
+        } while (t != null)
+
+        return false;
+    }
+
+or::
+
+    public static boolean findCause(Throwable t, Class <? extends Exception> cl) {
+        for (; t != null; t = t.getCause()) {
+            if (cl.isInstance(t))
+                return true;
+        }
+        return false;
+    }
+
+Many programmers put main execution flow inside several levels of "if" statements that guard against
+violation of processing pre-conditions.
+
+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
+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.
+
+I think that code should detect problems and interrupt execution (or move to processing next portion
+of information).
+
+Using interruptions you guaranty that next code will operate with proper incoming state. And you
+don't need to guard checks, eliminating checks nesting and allowing sequencing checks without
+code indenting. All code will lay on the same level!
+