scruffles.net subscribe
Monday, June 14, 2010

My current employer runs Sonar's static code analysis on the continuous integration servers. I recently turned on an IDE plugin which integrates Sonar's results into my editor and noticed a warning that made me scratch my head. Sonar doesn't like that I sometimes reuse my parameter variables. Here's an example of what I mean:

public void doSomething(int input) {
input = Math.min(20, input);
input = Math.max(0, input);

for (int i = 0; i < input; i++) {
doSomethingElse(input);
}
}

I went online to look for an explanation. I expected to find an academic paper explaining some details that I'm overlooking. Instead I found that everyone willing to speak seemed to be in agreement that this is a bad practice. Strangely, I could find little reasoning as to why. The best explanation I could find was Martin Fowler's Refactoring. In it he provides two reasons you shouldn't make assignments to parameters:
1) Java uses pass by value exclusively. "With pass by value, any change to the parameter is not reflected in the calling routine. Those who have used pass by reference will probably find this confusing"
2) Consistency - "It is much clearer if you use only the parameter to represent what has been passed in, because that is a consistent usage."

To the first point, I would say any Java developer (even a junior developer) who thinks reassigning a parameter will effect the reference passed into the method should be fired immediately. We shouldn't cater to that developer. They will eventually do severe damage to your program.

To the second point, I think creating a second variable for the same purpose of the first is the very definition of inconsistent. A parameter is nothing more than a method scoped variable that happened to have been assigned from outside the method. If James Gosling had intended them to be final, he would have made them that way.*

I believe I like re-assignment for the very reason Fowler's dislikes them: maintainability and readability. The result of refactoring the above code to Fowler's recommendation would result in this code:

public void doSomething(int input) {
int boundedInput = Math.min(20, input);
boundedInput = Math.max(0, boundedInput);

for (int i = 0; i < boundedInput; i++) {
doSomethingElse(boundedInput);
}
}

I think this is less readable. We now have two variables of the same scope that have nearly the same meaning. The first (the parameter) should not be used anywhere in the method except to initialize the second variable. This seems error prone. Somone could easily use input in the method body where they meant to operate against boundedInput. Even if they don't, it's still there taking up space (and brain cells) without providing anything to the story of this method.

Maybe I'm alone in thinking reusing parameters can make for more readable code. What better way to find out than for me to post my thoughts for the world to read (and criticize)? Feel free to comment.

* I guess an argument could be made that it was a mistake not to make parameters final by default, but now is a little late to make that argument. I believe we should write in the language that we have.

Monday, March 29, 2010

It's been on my todo list for well over a year now, but I've finally taken the time to redesign my blog. Since I switched to blogger I've been using an altered blogger theme that never really sat right with me (front image below). When I was using moveable type, I had created my design from scratch including a photo I had taken of a circut board (middle image). Considering myself a creative person, using someone else's website template really bothered me. It felt good to get this done.



Other than the actual photo of the cork (which I lifted from deviant art), everything here is original. I created all the artifacts from scratch in Photoshop and even took a picture of myself for the top corner. I'm using CSS and Javascript (JQuery) to make the flickr badge at the left look like images taped to the cork. There are a few rough edges I'd like to clean up, but overall I feel much better to have something original up again.

Saturday, March 20, 2010

Having used Macs for a number of years, I've become accustomed to being able to drag windows around by the window's outer most frame (the toolbar, statusbar or the outer border of the window). When I run a program that doesn't have this behavior (even one of my own), it almost feels broken.

I put together a piece of code which adds a MouseListener to any Swing component so dragging it will drag the entire Frame (or Dialog). Here's the behavior I'm trying to reproduce:



It isn't too difficult to implement. You can try out the results here:



The source is available on github.

Bryan