From Journeyman to Master

This was on digg today: Top Ten of Programming Advice NOT to follow. I’d like to share my take on them one by one.

10) “Use error codes instead of exceptions”

Agree. I don’t know why you want to use error codes unless you are dealing with legacy system.

9) “Use unsigned integers for values that can only be positive”

Well, I don’t really care.

8 ) “Design classes parallel to their physical counterparts”

Agree. It would be nice if you can do it. But you don’t have to. Especially if it’s gonna take a lot of effort.

7) “Make sure your team shares a common coding standard”

Disagree. I don’t care what coding style each team member uses. But with all the concurrent development, version control and merging going on, can we at lease use the same code format please?

6) “Write lots of comments”

Agree. Good programmers don’t need and don’t write comments.

5) “Use accessors or properties rather than public fields”

Disagree. I don’t see what’s the big deal with using accessors.

4) “Use the singleton pattern for variables that you KNOW you should have only one instance of”

Kind of agree. But I think singleton is appropriate for looking up stuff like factories or strategies.

3) “Be tolerant with input and strict with output”

Agree. Actually I don’t recall hearing this advice from anybody.

2) “Code all the corner cases immediately, cause otherwise you’ll never go back and fix things”

Agree. If you follow this advice, it means you are not doing Test Driven Development.

1) “Design first, then code”

Agree. That’s sooooo waterfall.

When I first heard of WATIR, it was an eye opener for me. It kicked HttpUnit/JWebUnit’s ass. Why use something that pretends to be a browser while you can simply interact with a real browser, right? After I introduced Ted to Paul Rogers, we started using WATIR extensively in our project. We created hundreds or maybe even thousands of WATIR tests in just a few months. Everything seems to be going well.

But when we object-oriented developers meet a good OO language, we tend to create a thing called object hierarchy. The more object-oriented we are, the deeper the hierarchy we create. This is not a good thing when you are working with a language with close to zero IDE support. Ruby is one of those languages. It’s a nightmare to figure out whether a constant or method has been defined and where it is if it has. There is also a lot of duplications and therefore chances for error because we cannot reuse the Java code in Ruby. Not too many developers are willing to write and maintain them except those who have to.

Here is where Ruby’s impact on Java comes into play. We’ve already seen it in stuff like GWT, Groovy and Grails. Now there is Watij. My coworker Chris found out about it when he’s working on a side project. It’s pretty much a WATIR clone in Java. But it’s easier to use than WATIR because you can reference your Java code, write your tests as JUnit tests and run them in your favourite IDE. It’s also very easy to set up. I can’t post any screen shots here because Watij currently only support IE and I’m a Mac guy. So you have to give it a try yourself. I’m sure you won’t be disappointed.

Have you ever used TreeSet in Java? Let’s say we have a class called AClass. It only inherits from Object and doesn’t implement any interface. Now I want to use the following code snippet to add a collection of AClass to a TreeSet:

TreeSet treeSet = new TreeSet();
treeSet.addAll(listOfAClass)

What happens when you run this piece of code? You get a ClassCastException! Why? Because if you don’t supply a Comparator to the TreeSet, it by default thinks that the element you are adding implements Comparable. It just blindly tries to cast whatever you put in it to Comparable. This is not very nice, is it? Shouldn’t it prevent me from adding element that’s not Comparable in the first place? Exception should be part of the interface. Yes, there is the API and source code I can look at. But in the world of code completion, people rarely do that. An appropriate exception would have been a lot better.