Ayende @ Rahien

Refunds available at head office

More code review errors

Take a look at this method:

image

Now, let us make this simple, shall we?

image

Same meaning, and a significant reduction of complexity. Damn, but this is annoying.

Comments

meowth
09/30/2008 07:49 AM by
meowth

Simply detect and explicitly express preconditions instead of trying to keep one return point, yep?

Frank Quednau
09/30/2008 07:51 AM by
Frank Quednau

It's funny you're coming with those, yesterday I talked with 2 colleagues about just that kind of stuff you see. Quite often it is paired with the weird obsession to have only 1 exit point. People are out there who actually TALK like that.

While being at it, any reason for comparing to false and not using '!' as well as any reason why the last if'd one-liner is in braces, while the other 1-liners aren't ?

Cheers...:)

Ayende Rahien
09/30/2008 07:56 AM by
Ayende Rahien

comparing to false is the way I like to do it.

As for the last, it just looks better to me that way

Laurent Kempé
09/30/2008 08:08 AM by
Laurent Kempé

Thanks to Resharper those code review are easiness!

JonR
09/30/2008 08:50 AM by
JonR

i strongly agree with all these points (and the ones in the previous post), but isn't it a little OTT to call them "errors"? i mean, if they really were errors, they wouldn't compile.

Romain Verdier
09/30/2008 09:02 AM by
Romain Verdier

I prefer using "!" and putting one liners in braces every time, but yes, guard clauses make code more easy to read/maintain.

Lars Hundertwasser
09/30/2008 09:17 AM by
Lars Hundertwasser

I agree with Romain, put one liners in braces. At least you have to be consistent, i.e. you have 3 one liners w/o braces and 1 with...

Markus Zywitza
09/30/2008 09:38 AM by
Markus Zywitza

This type of code usually exists because code isn't refactored. I don't know who wrote this code, but this was only red/green, not red/green/refactor.

The human mind thinks like the first code snippet: Do the main options first and wrap them with the required conditionals and handle exceptional conditions after that.

The latter code snippet is not how we think (well, at least not as I do): I don't think up all invariants and restrictions up front, but add them as if clauses as I go by. As a result, I refactor every method directly after I have finished it.

Frans Bouma
09/30/2008 09:40 AM by
Frans Bouma

fieldBridge is casted twice to ITwoWayFieldBridge, one should use 'as' and test for null.

It might be my C background, but I would test for < 0 instead of == -1.

The most weird thing still is that the method header accepts IFieldBridge, but effectively crashes (exception) if the parameter isn't an ITwoWayFieldBridge, i.o.w.: the method should have its fieldBridge parameter be typed as ITwoWayFieldBridge and let the compiler deal with calls to the method.

Also, 1 line if clauses should IMHO also be inside {}.

Ayende Rahien
09/30/2008 09:55 AM by
Ayende Rahien

Frans,

This method is called in one code path where the IFieldBridge impl should also be ITwoWayFieldBridge. If you don't enter this code path, you don't have to be IFieldBridge.

That is why the check is made dynamically.

Paul Hatcher
09/30/2008 10:47 AM by
Paul Hatcher

Oren

The reason I wrote it that way was that it is a direct port of the Java code and I'd prefer to keep the code bases the same until the port it complete.

Once it's all there, then refactoring makes sense, but until it is, trying to figure out if someone's refactored code does the same job as the original Java can be really problematic.

Michael McCurrey
09/30/2008 11:31 AM by
Michael McCurrey

" __i strongly agree with all these points (and the ones in the previous post), but isn't it a little OTT to call them "errors"? i mean, if they really were errors, they wouldn't compile. "

Just because something compiles, doesn't mean it won't error.

Robert Taylor
09/30/2008 12:07 PM by
Robert Taylor

The difference between the 1-line If-statements with vs. without braces is that for the ones without braces no code after those statements could ever possibly be executed. If someone needed to come along and add some additional statements it should be clear that it can't go after the throw statement in the same if-block.

jonnii
09/30/2008 01:50 PM by
jonnii

I tend to put error conditions at the top of my methods, as they're the first thing I write tests for so my code ends up looking like this by default.

I find it far easier to read.

Ayende Rahien
09/30/2008 02:29 PM by
Ayende Rahien

Paul,

I should have been more clear.

I am showing the C# code because it is what most of my readers will understand.

The fault lies in the Java code, I agree. It is bad in either language.

meisinger
09/30/2008 02:45 PM by
meisinger

interesting...

i would have tested "store" and "fieldBridge" first so that i wouldn't waste a call to "GetFieldPosition"

lord only knows what that method is doing

(i guess i have been bitten by too many "bad" calls in the past)

the other thing that interests me is the fact that there is no check to see if "matchingPosition" is within the bounds of the "result" array

lastly... (this is my personal "downfall")

i would use a string.Format for the exception messages

just my 2 cents

Bruno
09/30/2008 03:15 PM by
Bruno

@meisinger

String.Format is too much for simple string concatenations following the pattern 1 literal + 1 variable. It uses StringBuilder. You can check the stack trace causing an error due to bad formating.

JonR
10/01/2008 09:30 AM by
JonR

__Just because something compiles, doesn't mean it won't error.

:rolleyes:

i'll give you that, but i'm sure you see what i'm getting at.

Manav
10/01/2008 04:42 PM by
Manav

Disagree whole-heartedly with multiple return value point. There is another easy way to refactor the code i..e using goto Cleanup. That is the standard way we use in C/C++ but I have not used C# so don't know if goto exists or not.

Mohammad Tayseer
10/02/2008 01:40 AM by
Mohammad Tayseer

@Manav

The error case should be handled first, to free your mind from remembering if the error was handled or not.

In C++, you shouldn't use goto Cleanup. Use destructors & smart pointers instead. You don't want your resource cleanup to be all over the place

Comments have been closed on this topic.