stuttering : Java Glossary

Boolean Redundancy

• Newbies love to balloon out their code with redundancy. Newbies will write:

  if ( i < 7 )
     {
     return true;
     }
  else
     {
     return false;
     }

  That can be more tersely written as:

  return i < 7;

• Here is another common stuttering:

  return b ? true : false;

  It can be more tersely written:

  return b;

• Similarly a newbie will write:

  return b ? false : true;

  When he could have written more tersely:

  return !b;

• Avoid computing a Boolean this way:

  boolean b;
  if ( i < 7 )
     {
     b = true;
     }
  else
     {
     b = false;
     }

  Just say:

  boolean b = i < 7;

• Even intermediate programmers often stutter this way:

  if ( b == true ) j++;

  You already have the Boolean:

  if ( b ) j++;

• A newbie might code:

  if ( a.startsWith ( "c$$" ) )
     {
     System.out.println( "true" );
     }
  else
     {
     System.out.println( "false" );
     }

  When all they needed was:

  System.out.println( a.startsWith( "c$$" ) );

String Redundancy

• Newbies will often code:

  String s = new String( "abc" );

  to avoid littering the constant pool with redundant Strings, this should be written:

  String s = "abc";

• Newbies will often code:

  String s = new String();

  To avoid littering the constant pool with redundant copies of "", this should be written:

  String s = "";

  new String( String) rarely has legitimate use. One use is freeing up RAM (Random Access Memory) of a large base String when you no longer need the base String, but only want the substring kept around. If you use it otherwise you create needless duplicate Strings in your literal pool. For details on when new String( String) is valid, see intern.

If Redundancy

• if ( i <= 10 )
     {
     /*... */
     }
  else if ( 11 <= i && i <= 15 )
     {
     /*... */
     }

  Can be more tersely coded:

  if ( i <= 10 )
     {
     /*... */
     }
  else if ( i <= 15 )
     {
     /*... */
     }

• Newbies don’t understand that null does not have or need a type.

  public String getNull()
     {
     return(String)null;
     }

  There is no need to cast null, so this method is not needed at all. Plain null will do.

Conversions

Instead of consulting conversion in the Java glossary to find the optimal code, newbies, concoct preposterously complicated chains of conversions to convert a double to a String for example, leaving behind a trail of discarded intermediate objects:

String s = "1";
int i= new Integer(s).intValue(); /* newbie */
int i = Integer.parseInt( s ); /* correct */
//...
int i = 1;
String s = new Integer( i ).toString(); /* newbie */
String s = i + ""; /* lazy */
String s = Integer.toString( i ); /* correct */

Too Big And Flexible a Hammer

Newbies discover exceptions and use them where simpler and more efficient constructs would work better. For example they might use them in place of a loop ending condition or even a Boolean return flag.

Reflection dazzles, and newbies will use it where simple interfaces and delegate objects would suffice.

Sometimes an old-fashioned if or switch statement is easier to understand and maintain than a complicated nest of inherited classes. A newbie is intoxicated with the power of OO (Object Oriented) programming and wants to use it everywhere.

The more advanced newbie might discover the facade design pattern, and go overboard thinking that every class should implement every method with a wrapper.

If you enjoyed this essay you might like this one on how to write unmaintainable code.