Re: Control Flow Coding Style

As mentioned earlier today by John Carter in the "Alignment Nazi" thread, scientific/numerical code tends to have lots of if's, nested to some depth, to account for all the possible cases an algorithm may encounter.  I haven't spent much time thinking about how one would refactor large routines of this nature into a larger number of smaller pieces.  As much of the existing code is in non-OO languages (Fortran 77 is probably the most prevalent even now), there aren't a lot of tools in the toolbox as far as refactoring goes.  Also, performance is usually a prime consideration, so increasing the number of function calls is not desirable.  Actually I used to refactor toward monolithic "structured programming" style if statements, because what pre-existed was even worse -- true spaghetti code, sometimes still using arithmetic goto's from FORTRAN 66 and earlier dialects.

Al



----- Original Message ----
From: jens bendig <[email protected]>
To: [email protected]
Sent: Monday, April 28, 2008 8:44:57 AM
Subject: Re: [pragprog] Control Flow Coding Style

Hi Avdi,

I completely agree with your short-circuit-clauses.
Also, with the Problematic return inside a deep conditional.
Here, I would add a thing: Mostly, when you have a deep conditional in *any* Method,
you have a Design-Problem that can be solved by some refactoring. The deep conditional
often has to do with doing something at the wrong level of detail. The complicated descision will
vanish or spread, if somewhere else in the code the right thing is done. However, I´d not
just look for the return, but also for complicated conditions at all, you don´t need them.

The third thing, the else-clauses: Right, In about every case you should be aware that you 
have the else-clause coded there. If you don´t write it down, the else-clause is implicitely coded
by the following code. The only case where I don´t code the else is the short circuit-cause.

Yours,

Jens


Am 28.04.2008 um 16:55 schrieb Avdi Grimm:

On Mon, Apr 28, 2008 at 4:55 AM, Michael Hunger <pragmatic@jexp. de> wrote:
> 1) there _must_ be a single point of exit for each method

For me the point of pragmatic compromise falls thus (and I'm assuming
we're only talking about method return, not exceptions): In general,
only one point of return. There are a couple of exceptions, though.

1. Short-circuit clauses at the beginning of methods:

def foo(arg)
return nil if arg.some_special_ case?

# ... the meat of the method ...
end

I like to keep these in a separate clause at the beginning of the
method, though; once the primary logic of the method begins, no more
short-circuit returns allowed.

2. Methods where there is a consistent and obvious pattern of returns:

def bar(arg)
arg = transform1(arg)
return arg if arg.ready?
arg = arg transform2(arg)
return if arg.ready?
arg = transform3(arg)
return arg
end

What I *don't* like to see is a method that has one obvious return at
the end, and then a second special-case return buried a couple layers
deep in conditionals. Those are the methods that lead to
head-scratching debugging sessions because you haven't noticed that
the method is exiting early.

> 2) each if must have an accompanying else branch

The longer I write code, the more I think this is a good idea. I
pretty habitually put in 'else raise "Should never get here"' clauses
in my code. Yeah, it's a little extra clutter; but the time savings
in catching bad assumptions early is worth it IMO.

-- 
Avdi

Home: http://avdi. org
Developer Blog: http://avdi. org/devblog/
Twitter: http://twitter. com/avdi
Journal: http://avdi. livejournal. com


Dipl.-Phys. Jens Bendig
motionDesign im Technologiepark Universität Bremen
http://www.motionDesign.de
[email protected]

Fahrenheitstr. 1
28359 Bremen
Tel. 49 -421 2208 311 nachmittags

 
 


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ