Code n'roll

Updates from October, 2008 Toggle Comment Threads | Keyboard Shortcuts

• 

  Tomás Augusto Müller 7:40 pm on October 26, 2008 Permalink | Reply
  Tags: OO ( 11 ), patterns, programming ( 15 ), rules of thumb ( 2 )   

  Rule 2: Don’t Use the else Keyword 

  As Jeff Bay wrote: “Every programmer understands the if/else construct.” This is the simplest conditional logic, avalilable in nearly every programming language. But it also make possible to turns your code into a nasty nested conditional logic that’s impossible to follow or very dificult to read, understand and mantain. Conditionals are also a frequent source of duplication.

  But don’t worry. It’s not only your fault :-)
  Due to ease of simply add another branch to an conditional logic, rather than factoring to a better solution, it is a very common problem that we can see.

  Tip from the book

  Status flags, for example, frequently lead to this kind of trouble:

  public static void endMe() {
   if (status == DONE) {
       doSomething();
   } else {
       <other code>
   }
  }

  You have several options for rewriting this without the else. Form simple cases, use this:

  public static void endMe() {
   if (status == DONE) {
       doSomething();
       return;
   }
   <other code>
  }

  Another tip is make use of ternary operator:

  public static Node head() {
   if (isAdvancing()) {
      return first;
  }
   else {
      return last;
  }
  }
  
  public static Node head() {
   return isAdvancing() ? first : last;
  }

  Cutting down else keyword

  Look the early return used at first example. Was used to collapse down the lines where else keyword were used. Also take care to not overuse early returns in your code. This can easily reduce clarity and turn the code into a mess again.

  Simple cases can be replaced with guard clauses and early returns. Look at those sites for more information about guard clauses:

  • http://www.refactoring.com/catalog/replaceNestedConditionalWithGuardClauses.html
  • http://sourcemaking.com/refactoring/replace-nested-conditional-with-guard-clauses
  • http://www.codinghorror.com/blog/archives/000486.html

  From Coding Horror I’ve taken this nice picture :-) :

  

  In Object-Oriented languages we have polymorphism. It is a powerful tool for handling complex conditional cases, making the design easier to read and maintain, expressing their intent more clearly. Take a look at the Design Patterns book, and find the Strategy pattern. It can be useful to avoid duplicated branchings, and it is a good example of polymorphism. Also see the Null Object pattern, it may help in some situations.

  And keep in mind that some of others rules, like the first one can help here!

  Good luck in your exercise!

  Share:

  Like this:

  Like

  Be the first to like this post.
   

  Reply Cancel reply

  Required fields are marked *

  Name *

  Email *

  Website

  

  Notify me of follow-up comments via email.

  Notify me of new posts via email.

• 

  Tomás Augusto Müller 3:39 pm on September 20, 2008 Permalink | Reply
  Tags: OO ( 11 ), programming ( 15 ), rules of thumb ( 2 )   

  Rule 1: Use One Level of Indentation per Method 

  In a previous entry, I’ve written about an exercice based on “rules of tumb”, proposed by Jeff Bay. Here is the first rule.

  Have you ever encountered a large amount of lines all together into a single method, and started wondering “oh hell, where I start…” ? Please! Don’t lie for your self conscience!

  So, this rule is a good way to start.

  The Rule

  Try to ensure that each method does exactly one thing. One control structure, or one block of statements per method. Nested control structures in a method are a signal that you’re working at multiple level of abstraction, and that means you’re doing more than one thing.

  Working with methods that does exactly one thing, and classes doing exactly one thing, your code begins to change, becoming more smaller and increasing exponentially the level of reuse. Or you see a easy opportunity to reuse a method with many responsibilities implemented on hundred lines?

  Another effect of this rule is that each individual method has become much more easier to match its implementation to its name, and the ease of bug hunting.

  Tip from the book

  Use the Extract Method feature of your IDE to pull out behaviors until your methods have only one level of indentation. See the example below:

  class Board {
   String board() {
    StringBuffer buf = new StringBuffer();
    for (int i = 0; i < 10; i++) {
     for (int j = 0; j < 10; j++)
      buf.append(data[i][j]);
     buf.append("\n");
    }
    return buf.toString();
   }
  }

  applying the rule, we will see this:

  class Board {
   String board() {
    StringBuffer buf = new StringBuffer();
    collectRows(buf);
    return buf.toString();
   }
  
   void collectRows(StringBuffer buf) {
    for (int i = 0; i < 10; i++)
     collectRow(buf, i);
   }
  
   void collectRow(StringBuffer buf, int row) {
    for (int i = 0; i < 10; i++)
     buf.append(data[row][i]);
    buf.append("\n");
   }
  }

  That’s it! Wait for the next one! Till there have a happy programming!

  Share:

  Like this:

  Like

  Be the first to like this post.