06.13.05
Joel Speaks…
A while back Joel, over at Joel on Software posted a new article on coding conventions Making Wrong Code Look Wrong.
I think his point was legitimate, but maybe clouded by the fervor with which people hate Hungarian notation. The central point that coding conventions should be used to make wrong code look wrong. It may be that Hungarian is a reasonable solution for a procedural environment.
The best Java analogue I can think of is RequestDispatcher.forward(). You *have* to return after that call, or you’ve just created a bug. It may not crop up, but if you don’t return and then some other piece of code tried to modify the response *boom* it blows up.
So how do you make this look wrong:
RequestDispatcher dispatcher = ServletContext.getRequestDispatcher("path");
dispatcher.forward(request, response);
and make this look right:
RequestDispatcher dispatcher = ServletContext.getRequestDispatcher("path");
dispatcher.forward(request, response);
return;
That’s the kind of thing I started thinking about when I read that article.
You can’t extract a method, because you’ll just create another method that requires a return after it. So I think the answer is to make a dictate against such methods. Since we can’t change the J2EE spec, we should leave RequestDispatcher.forward() calls bare. At least, then you can recognize one of the few methods that are missing the required return.
The bit I haven’t figured out, yet is what would the J2EE spec look like if we could change it. That’s a topic for another time.