Comments on: Beware the mechanical coder, my son…

By: Robert Watkins

Robert Watkins — Mon, 21 Feb 2005 14:21:49 +0000

Ah, but the first one indicates a greater degree of cluelessness, and that’s what I’m finding offensive.

The second one, of course, is the greater problem.

By: Michael

Michael — Mon, 21 Feb 2005 13:45:19 +0000

But it is the second one with serious real world implications.

But fixing the second one will require a lot more testing then the first.

By: Robert Watkins

Robert Watkins — Mon, 21 Feb 2005 11:59:46 +0000

Probably the first one. That’s a basic Java issue, whereas the “fetch IDs and delete one-by-one” is one step further up.

To answer Charles: the string appends isn’t a problem. As can be clearly seen, all the strings are constant; the compiler will simply run them together at compile time (a standard optimisation technique).

By: Michael

Michael — Sat, 19 Feb 2005 21:14:36 +0000

But which one offends you more? The mindless use of StringBuffer (probably cause someone told them that if you are building up strings, ALWAYS use a string buffer. If I had a doller for everytime…)

The n+1?

By: Charles

Charles — Sat, 19 Feb 2005 05:10:53 +0000

The problem with the first one is clearly that he uses the stringbuffer, ostensibly for performance reasons but then uses string concatenation anyways instead of calling .append()

By: Robert Watkins

Robert Watkins — Fri, 18 Feb 2005 18:44:47 +0000

Yes, as you say, it uses a StringBuffer when not needed; the template, BTW, comes from a dynamically constructed query elsewhere in the class.

The problem with the latter is that it does a query to get back the IDs, then iterates through the list and brings them back one at a time. Thus, you get N+1 database calls, instead of just 1.

The problem with all of it is that the person who wrote it just mechanically copied something else rather than understand it.

By: Niels

Niels — Fri, 18 Feb 2005 18:36:30 +0000

The only problem I see in the first fragment is that it uses a StringBuffer instead of a plain String. The concatenation will be handled at compiletime anyway.

Not beign hibernate-savvy, I won’t comment on the second fragment.