You see, I was working on this function that returned a value based on a few incoming parameters, and the lead admitted he was having difficulty reading the code.  It looked something like the following snippet:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

int myFunction( int a, int b, int c )
{
  /* Initialize return value */
  int returnValue = 0;
 
  /* Determine return value */
  if ( a == 0 || b == 0 || c == 0 )
  {
    /* Provided values are invalid, return -1 */
    returnValue = -1;
  }
  else
  {
    if ( a > b )
    {
      returnValue = 1;
    }
    else if ( b > c )
    {
      returnValue = 2;
    }
    else if ( c > a )
    {
      returnValue = 3;
    }
    else
    {
      returnValue = 0;
    }
 
    // Do more stuff here
 
  }
 
  /* Return the value */
  return( returnValue );
}

Lets take a minute to review this function…

• At line 1, we begin our function and accept 3 integers
• At line 4, we create a variable to hold the value our function will return upon completion
• At line 7, we enter an if statement and check to see if any of the provided values are 0
• If any of the values are 0, then we set our return value to -1
• Otherwise, we enter our else block and determine our return value
• At line 31, we have code that does other important stuff
• Finally, at line 36, we return our return value

Note: the “other stuff” code at line 31 was not reproduced as we don’t really care what it does in this example, but we do need to know that it is there.

My Lead’s beef with the function above mostly had to do with lines 7 through 33. Specifically, he deplored the fact that the if statement was the length of the function, and also questioned the reasoning behind letting the function continue its flow if the parameters were determined to be incorrect. (For example, if we add code to line 34, it will be run regardless of the parameters being valid or not.)

He explained that, although nested if statements could be useful from time to time, they should generally be avoided as they make code difficult to maintain.

So I asked him how I could avoid nested if statements, and he proposed that I simply return the -1 value at line 10, instead of assigning it to a variable and returning it later on. This would simplify the function, and would remove the function-long if statement:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

int myFunction( int a, int b, int c )
{
  /* Initialize return value */
  int returnValue = 0;
 
  /* Validate Parameters */
  if ( a == 0 || b == 0 || c == 0 )
  {
    /* Provided values are invalid, return -1 */
    return( -1 );
  }
 
  /* Determine return value */
  if ( a > b )
  {
    returnValue = 1;
  }
  else if ( b > c )
  {
    returnValue = 2;
  }
  else if ( c > a )
  {
    returnValue = 3;
  }
  else
  {
    returnValue = 0;
  }
 
  // Do more stuff here
 
  /* Return the value */
  return( returnValue );
}

And there we go. By immediately returning the value -1, we can remove the else block and avoid putting the whole function in an if statement.

This might not seem like much right now, but one day you might run into a very large function with multiple lines of code and multiple if statements that persist throughout the function. And on that day you’ll hit your forehead with your hand and wonder why the function’s author didn’t read FuglyCode.com

Function Optimization

This function could be even more optimized. Can you figure out how?

Try rewriting this function to make it as optimal as possible and then compare what you wrote with my code (click on the down arrow to expand the code box). Feel free to share your code in the comments if its any different from mine!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

int myFunction( int a, int b, int c )
{
  /* Validate Parameters */
  if ( a == 0 || b == 0 || c == 0 )
  {
    /* Provided values are invalid, return -1 */
    return( -1 );
  }
 
  /* Call new doMoreStuff function */
  doMoreStuff();
 
  /* Return a value */
  if ( a > b )
  {
    return( 1 );
  }
  else if ( b > c )
  {
    return( 2 );
  }
  else if ( c > a )
  {
    return( 3 );
  }
 
  return( 0 );
}
 
void doMoreStuff ()
{
  /* Move the do more stuff into its own function *
   * to increase reusability and readability */
}

Lets take the following snipped of FuglyCode for example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

public boolean Tester( Object myObject ) {
  String myString;
  Integer myInt;
  try
  {
    // Save the string
    myString = ( String ) myObject;
 
    // Do more String stuff...
  }
  catch ( Exception e )
  {
    // The object was not a string
    // Save the integer
    myInt = ( Integer ) myObject;
 
    // Do more Integer stuff...
  }
 
  return( true );
}

Special thanks to jpuly for submitting this code. Submit your fugly code here.

Before we begin analyzing the fuglyness of this code, lets go over it to make sure we all understand what seems to be going on:

• At line 1, we enter our Tester method and receive an object
• At line 7, we attempt to save our object to a String variable
• At line 11, we catch any exception of type Exception (pretty much, we catch any exception)
• At line 15, we assume that the exception was caused by saving the object to a string, so we save our object to an Integer variable

One of the biggest problems with this code is that, although we accept any Exception type, we assume that the only reason our code would throw an exception would be because of the String cast on line 7. What if the myObject parameter is a String, and code does something on line 9 that throws an exception?

Obviously the exception will be caught and the catch block will be run. Because myObject is a string, however, the Integer cast on line 15 will throw an exception, and since we don’t have any code to handle and exception thrown at that line, our program will crash and burn.

So what could you do? Well, you could begin by using a much more specific Exception type. In fact, changing line 11 to “catch ( ClassCastException e )” would ensure that we only enter the catch block if the String cast on line 7 failed, although it wouldn’t protect against other exceptions being thrown, or against myObject being something other than a String or an Integer.

KISS!

In this particular situation, we need to take a step back and look at the method as a whole. What are we trying to accomplish here? Does the code have to be so complicated? (Remember KISS!)

Truth is, our Tester method is using error handling to make a decision (if myObject is a String, do something, otherwise, do something else). Not only is this poor software design, but it fails to capitalize on the programming language’s built in ability to overload methods.

So, lets scrap the error handling altogether, and split this method into two similar methods with differing signatures:

1
2
3
4
5
6
7
8
9
10

public boolean Tester( String myString ) {
    // Do String stuff... (optionally wrap in try/catch block)
 
    return( true );
}
public boolean Tester( Integer myInt ) {
    // Do Integer stuff... (optionally wrap in try/catch block)
 
    return( true );
}

And there we go! Now we have two methods with the same names (meaning our calling code doesn’t have to change). We also specify our parameter types, meaning that the compiler will not allow us to call Tester with anything other than either an Integer or a String. And as a final and optional touch, we can add error handling at lines 2 and 7, in case these lines risk throwing an exception.

If you have any questions, feel free to post them in the comments section below.

If you would like to ask your question privately, you can send it using the Contact Us form.

Do you have any FuglyCode you would like to share? If so, then submit it!