4 ms·

Get to No as fast as possible

31 points by tswicegood 16y ago

oakenshield 16y ago
I remember back in a Paradigms of Programming class in uni, our professor who lived by Dijkstra's "Gotos considered harmful" mantra tried to get us all to write programs with a single exit point from each function. I argued that short-circuiting errors before going to the logic made sense both nesting-wise and maintainability-wise, but was ridiculed. I wish I'd known about coding styles in the Linux/BSD kernels back then so I could throw it back at him.
- scott_s 16y ago
  But the coding styles in the Linux kernel usually maintain a single exit point from the function. The format they generally have is: syscall(params) { if (easy check on params fails) goto done; allocate data for work if (further check on params and data fails) goto cleanup; perform real work cleanup: deallocate data done: set return value } There's often still a single exit, but it does use gotos to implement simple exceptions. The only times when there are multiple exits is before any data has been allocated and there's no cleanup to be done.
- walkon 16y ago
  I agree with your preference, but just curious - is a return considered a goto? I've not thought so, but I could be wrong.
iamwil 16y ago
I much prefer this style too. Every time you have to go into a nest, you have to maintain state in your head of what the condition is. So by the time you're nested 9 or 10 levels deep (I've seen this before), I can't remember what all the conditions are that got me there. I remember reading the single-exit mantra was the result of hardware and speed optimization, rather than readability and maintainability optimization, but I could be remembering wrong.
GFischer 16y ago
Whenever I see code that asks for conditions that might vary according to the business rules, I ask myself if there's a better way. Has anyone had any success with business rule engines? What's your approach to these kind of constraints? I'm faced with code like this at work all the time (I mostly maintain corporate apps, and get requirements like "law XYZ asks for a minimum of 150.000 oddunits for ABC, we need to change all our apps to support that") Edit: or the far simpler, "we can't sell ABC to people under 21" or "people from Iran"
- dkimball 16y ago
  Alex Papadimoulis of the Daily WTF has an article on this -- it's his opinion that the simple, "bone-headed" approach is the best one for constraints like this, and homegrown business rule engines are dangerous: http://thedailywtf.com/Articles/Programming-Sucks!-Or-At-Least,-It-Ought-To-.aspx http://thedailywtf.com/Articles/Programming-Sucks!-Or-At-Lea... However, commercial business rule engines might work out better, provided they stick to XML or known formats of I/O in general.
  - GFischer 16y ago
    Thanks for the link. IMO Alex doesn't give the best advice sometimes (not to wonder, he sees so much boneheadedness!!!), but he's quite right there... but I don't see the advice -against- business rule engines there. I totally agree with your own advice about sticking to commercial business rule engines. In fact, I'll give Drools.net a try (any other suggestions?). If any company -needs- a rules engine, it's the one I work for (there's a "developer" whose main reason for having work is that the business rules change a lot every freaking month) PD: I like his linking to Yourdon's book :) - and I have a degree in "Information Systems" myself
    - dkimball 16y ago
      You know, on considering, I think you're right -- he doesn't advise against rules engines, just the Greenspun's Rule version. (Greenspun's Rule is that "any sufficiently long-running project includes a slow, buggy, and ad-hoc implementation of half of Common Lisp.") I don't have much experience with rules engines, and I don't know what your budget is like; so I can't really make recommendations. That doesn't stop me from trying, though... You might be interested in Intersystems' Ensemble. If you're anything like Alex, you'll run screaming for the hills at this point, since it's built on MUMPS (it's an extension of Caché, "postmodern MUMPS," which comes with everything from a web server to a blindingly fast SQL frontend). If you're not -- if you realize that it all compiles down to object code anyways, and what's important is programmer skill and code maintainability, not the presence of curly braces and variable declarations -- you'll keep reading. (Actually, Caché's version of MUMPS has both curly braces and variable declarations, although both are optional.) Ensemble was designed to translate messages between incompatible healthcare databases, applying business rules in the process. It can be used for more than that; part of the training I had in the product (see below for my full disclosure) was using it to implement a simple loan acceptance protocol. I think that its "flowchart mode" of execution might be very well suited to frequently-changing business rules. There's a video at http://www.maddash.net/videos/intersystems/ensemble/vehr/ http://www.maddash.net/videos/intersystems/ensemble/vehr/ which demonstrates this -- look at 7:15 for the flowchart (each element in it is programmable as necessary), and at 2:15 for the related flow through processing modules when something comes in. You may be able to get a proof-of-concept demonstration -- see http://www.intersystems.com/ensemble/pilot/index.html http://www.intersystems.com/ensemble/pilot/index.html for details. Even if not, if this looks interesting, it wouldn't hurt to get in touch with Intersystems Sales. Full disclosure: I work at Intersystems, but I'm not associated with Sales, and I really should be getting back to work. :)
wfjackson3 16y ago
This methodology is commonly taught for designing discrete logic in electronics. Make a Karnaugh map to show your true and false states, and pick to implement the minimized logic for true or false cases only.
emehrkay 16y ago
I much prefer one return per mehtod/func. Of course there are cases where that isn't possible, but I feel that if it were structured the right way, the code would be easier to read. func(){ val = true resp = 'whatever' if(condition){ resp = 'new' } return resp }
- nihilocrat 16y ago
  What do you do if in between if(condition) and return, there are a bunch of actions that modify state outside the function that, if condition is true, you'd never ever want to do?
  - emehrkay 16y ago
    else ?
- fleitz 16y ago
  It's generally pretty easy to do if you write your code in a functional/tail recursive style. Instead of modifying your variables and returning, create new variables and pass them back into your function, in that way whatever you create will have to go back through all the sanity checks. Yes you can get infinite loops this way, but it alerts you to having coded your function incorrectly instead of returning the wrong data. func(condition,resp){ val = true if(!condition){ return func(!condition,'new'); }) return resp } func(false,'whatever');
albertzeyer 16y ago
I'm always using this style because of much better readability. If I need some shared cleanup code when the function returns, I'm using some of the C++ scope-exit trick. Or in most cases, some of the predefined scope-exit handlers do just what I want. Like: std::auto_ptr or boost::scoped_ptr boost::shared_ptr boost::interprocess::scoped_lock (or I have my own mutex scopedlock class)
pragmatic 16y ago
Coding Horror discusses this: http://www.codinghorror.com/blog/2006/01/flattening-arrow-code.html http://www.codinghorror.com/blog/2006/01/flattening-arrow-co... Worth another look. I've found this style much more readalbe and maintainable down the road and it prevents the "arrow code" in the link above.

31 points by tswicegood 16y ago

I remember back in a Paradigms of Programming class in uni, our professor who lived by Dijkstra's "Gotos considered harmful" mantra tried to get us all to write programs with a single exit point from each function. I argued that short-circuiting errors before going to the logic made sense both nesting-wise and maintainability-wise, but was ridiculed. I wish I'd known about coding styles in the Linux/BSD kernels back then so I could throw it back at him.

scott_s 16y ago
But the coding styles in the Linux kernel usually maintain a single exit point from the function. The format they generally have is: syscall(params) { if (easy check on params fails) goto done; allocate data for work if (further check on params and data fails) goto cleanup; perform real work cleanup: deallocate data done: set return value } There's often still a single exit, but it does use gotos to implement simple exceptions. The only times when there are multiple exits is before any data has been allocated and there's no cleanup to be done.
walkon 16y ago
I agree with your preference, but just curious - is a return considered a goto? I've not thought so, but I could be wrong.

iamwil 16y ago

I much prefer this style too. Every time you have to go into a nest, you have to maintain state in your head of what the condition is. So by the time you're nested 9 or 10 levels deep (I've seen this before), I can't remember what all the conditions are that got me there. I remember reading the single-exit mantra was the result of hardware and speed optimization, rather than readability and maintainability optimization, but I could be remembering wrong.

GFischer 16y ago

Whenever I see code that asks for conditions that might vary according to the business rules, I ask myself if there's a better way. Has anyone had any success with business rule engines? What's your approach to these kind of constraints? I'm faced with code like this at work all the time (I mostly maintain corporate apps, and get requirements like "law XYZ asks for a minimum of 150.000 oddunits for ABC, we need to change all our apps to support that") Edit: or the far simpler, "we can't sell ABC to people under 21" or "people from Iran"

dkimball 16y ago
Alex Papadimoulis of the Daily WTF has an article on this -- it's his opinion that the simple, "bone-headed" approach is the best one for constraints like this, and homegrown business rule engines are dangerous: http://thedailywtf.com/Articles/Programming-Sucks!-Or-At-Least,-It-Ought-To-.aspx http://thedailywtf.com/Articles/Programming-Sucks!-Or-At-Lea... However, commercial business rule engines might work out better, provided they stick to XML or known formats of I/O in general.
- GFischer 16y ago
  Thanks for the link. IMO Alex doesn't give the best advice sometimes (not to wonder, he sees so much boneheadedness!!!), but he's quite right there... but I don't see the advice -against- business rule engines there. I totally agree with your own advice about sticking to commercial business rule engines. In fact, I'll give Drools.net a try (any other suggestions?). If any company -needs- a rules engine, it's the one I work for (there's a "developer" whose main reason for having work is that the business rules change a lot every freaking month) PD: I like his linking to Yourdon's book :) - and I have a degree in "Information Systems" myself
  - dkimball 16y ago
    You know, on considering, I think you're right -- he doesn't advise against rules engines, just the Greenspun's Rule version. (Greenspun's Rule is that "any sufficiently long-running project includes a slow, buggy, and ad-hoc implementation of half of Common Lisp.") I don't have much experience with rules engines, and I don't know what your budget is like; so I can't really make recommendations. That doesn't stop me from trying, though... You might be interested in Intersystems' Ensemble. If you're anything like Alex, you'll run screaming for the hills at this point, since it's built on MUMPS (it's an extension of Caché, "postmodern MUMPS," which comes with everything from a web server to a blindingly fast SQL frontend). If you're not -- if you realize that it all compiles down to object code anyways, and what's important is programmer skill and code maintainability, not the presence of curly braces and variable declarations -- you'll keep reading. (Actually, Caché's version of MUMPS has both curly braces and variable declarations, although both are optional.) Ensemble was designed to translate messages between incompatible healthcare databases, applying business rules in the process. It can be used for more than that; part of the training I had in the product (see below for my full disclosure) was using it to implement a simple loan acceptance protocol. I think that its "flowchart mode" of execution might be very well suited to frequently-changing business rules. There's a video at http://www.maddash.net/videos/intersystems/ensemble/vehr/ http://www.maddash.net/videos/intersystems/ensemble/vehr/ which demonstrates this -- look at 7:15 for the flowchart (each element in it is programmable as necessary), and at 2:15 for the related flow through processing modules when something comes in. You may be able to get a proof-of-concept demonstration -- see http://www.intersystems.com/ensemble/pilot/index.html http://www.intersystems.com/ensemble/pilot/index.html for details. Even if not, if this looks interesting, it wouldn't hurt to get in touch with Intersystems Sales. Full disclosure: I work at Intersystems, but I'm not associated with Sales, and I really should be getting back to work. :)

wfjackson3 16y ago

This methodology is commonly taught for designing discrete logic in electronics. Make a Karnaugh map to show your true and false states, and pick to implement the minimized logic for true or false cases only.

emehrkay 16y ago

I much prefer one return per mehtod/func. Of course there are cases where that isn't possible, but I feel that if it were structured the right way, the code would be easier to read. func(){ val = true resp = 'whatever' if(condition){ resp = 'new' } return resp }

nihilocrat 16y ago
What do you do if in between if(condition) and return, there are a bunch of actions that modify state outside the function that, if condition is true, you'd never ever want to do?
- emehrkay 16y ago
  else ?
fleitz 16y ago
It's generally pretty easy to do if you write your code in a functional/tail recursive style. Instead of modifying your variables and returning, create new variables and pass them back into your function, in that way whatever you create will have to go back through all the sanity checks. Yes you can get infinite loops this way, but it alerts you to having coded your function incorrectly instead of returning the wrong data. func(condition,resp){ val = true if(!condition){ return func(!condition,'new'); }) return resp } func(false,'whatever');

albertzeyer 16y ago

I'm always using this style because of much better readability. If I need some shared cleanup code when the function returns, I'm using some of the C++ scope-exit trick. Or in most cases, some of the predefined scope-exit handlers do just what I want. Like: std::auto_ptr or boost::scoped_ptr boost::shared_ptr boost::interprocess::scoped_lock (or I have my own mutex scopedlock class)

pragmatic 16y ago

Coding Horror discusses this: http://www.codinghorror.com/blog/2006/01/flattening-arrow-code.html http://www.codinghorror.com/blog/2006/01/flattening-arrow-co... Worth another look. I've found this style much more readalbe and maintainable down the road and it prevents the "arrow code" in the link above.