Settling into Eclipse

As part of my current software engineering course, I've installed the latest version of Eclipse (Indigo). I've used Eclipse before, but not for some time, so I'm going through a period of reacquaintance and reconfiguring.

As a settling-in exercise, I implemented the following FizzBuzz program:

/**

 * The sort of problem given to intro programmers in a job interview:

 * print the numbers 1 to 100, one per line, with "Fizz" replacing those

 * divisible by 3, "Buzz" replacing those divisible by 5, and "FizzBuzz"

 * for those divisible by both 3 and 5.

 * 

 * @author Zach Tomaszewski

 * @version 29 Aug 2011 

 */

public class FizzBuzz {

  

  /**

   * Returns a String version of num or else "Fizz", "Buzz", etc. according

   * to the rules of FizzBuzz.  Applies the rules even if num is <= 0.  

   */

  public static String fizzBuzz(int num) {

    if (num % 3 == 0 && num % 5 == 0) {

      return "FizzBuzz";

    }else if (num % 3 == 0){

      return "Fizz";

    }else if (num % 5 == 0) {

      return "Buzz";

    }else {

      return Integer.toString(num);

    }

  }



  /**

   * Prints results of {@link #fizzBuzz()} for 1 to 100 to the screen.

   */

  public static void main(String[] args) {

    for (int i = 1; i <= 100; i++) {

      System.out.println(fizzBuzz(i));

    }

  }

}

It took me 22 minutes to create a project, write the code, and test it. Since I wrote this program on paper in 3.5 minutes in class the other day, most of this time spent went into playing around with Eclipse.

Part of this time was adjusting to initially-annoying things that Eclipse does. For example, at one point it suddenly highlighted in grey all the return statements in the current method. I wasn't at first able to see why this happened or how to make it go away. I now understand that Eclipse does this highlighting for any variable or return statement you are currently lingering on with the cursor, and it won't change the highlighting until you move your cursor elsewhere.

I also tried to decide how detailed to get for something that is obviously a one-off practice program. For example, should I bother with a package? Should I bother documenting the simple methods using @param and @return tags? Should I prevent fizzBuzz(int) from accepting negative numbers? In the end, I decide no for all these things.

I did move the fizzBuzz logic into its own method, though, in order to make it easier to test. This is something I saw done in class. I wrote a JUnit test too:

import static org.junit.Assert.*;



import org.junit.Test;



public class FizzBuzzTest {



  @Test

  public void test() {

    assertEquals("fizzBuzz(4)", FizzBuzz.fizzBuzz(4), "4");

    assertEquals("fizzBuzz(9)", FizzBuzz.fizzBuzz(9), "Fizz");

    assertEquals("fizzBuzz(20)", FizzBuzz.fizzBuzz(20), "Buzz");

    assertEquals("fizzBuzz(45)", FizzBuzz.fizzBuzz(45), "FizzBuzz");

  }

}

This is the first time I've used JUnit, but, for something this simple, it was pretty self-explanatory (once you know about the assertEquals method). I'm looking forward to learning more about JUnit--particularly best practices. Right now, I find writing the test descriptions to be unnecessary duplication. It's easy for the description of the test to get out of sync with the test itself. I'm guessing that perhaps test descriptions should be stated at a higher level: what the test is testing, rather than the details of how it is testing it (as I did here). For example, perhaps the second test here would be better described as "Divisible by 3".

I also set up SyntaxHighlighter to use on this blog for code samples. Various instructions for Blogger installation are here. I went through the extra work of hosting SyntaxHighligher on my own server and then linking to the necessary scripts from here. This took much longer than the above code.