Which is the better method to use "if else" statements
in [Embedded]
|
From: Vladimir Vassilevsky on 7 Jun 2010 16:54 D Yuniskis wrote: > Hi Vladimir, > > Vladimir Vassilevsky wrote: > >> kishor wrote: >> >>> I have some doubt in using "if" "else" statements. >>> Which is the better method (for efficiency, readability or any other >>> reason)????. >> >> >> A piece of code shall have only one entry point and only one exit point. > > > As with most "coding rules", I *really* disagree with that! :> > (I've made a goal of routinely loosening all of the "rules" > that I've previously thought to have been "written in stone") > Write the code so it is easy to understand. Then you have to define in stone a rule which explains what is "easy to understand", as 99.9% of people have no taste neither common sense. Don't > force extra *syntax* on the code just to make it fit > some (well intended, though arbitrary) rule. > > E.g., how do you handle: > > void > task(void) { > while (FOREVER) { > lamp(ON); > sleep(ON_TIME); > lamp(OFF); > sleep(OFF_TIME); > } > } > > and still satisfy the "shall" in your rule? lamp.toggle(ON_TIME, OFF_TIME, FOREVER); //-------------- Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
From: D Yuniskis on 7 Jun 2010 17:23 Hi Vladimir, Vladimir Vassilevsky wrote: > D Yuniskis wrote: > >> Hi Vladimir, >> >> Vladimir Vassilevsky wrote: >> >>> kishor wrote: >>> >>>> I have some doubt in using "if" "else" statements. >>>> Which is the better method (for efficiency, readability or any other >>>> reason)????. >>> >>> >>> A piece of code shall have only one entry point and only one exit point. >> >> >> As with most "coding rules", I *really* disagree with that! :> >> (I've made a goal of routinely loosening all of the "rules" >> that I've previously thought to have been "written in stone") >> Write the code so it is easy to understand. > > Then you have to define in stone a rule which explains what is "easy to > understand", as 99.9% of people have no taste neither common sense. But that's my whole point: there are damn few things that I think should be "cast in stone". Too often, following rules leads to crappy and/or clumsy code as people strive for (or are *forced* into) "compliance at all costs". My coding standards are titled "Coding GUIDELINES". They're goal is to force as little as possible on the code. Instead, they try to point out the hazzards associated with various coding practices that might not be obvious to the casual coder. They try to shed light on many of the "implementation defined" behaviors of compilers (which many coders seem to be ignorant of). They try to show how certain ways of expressing algorithms can lead to unexpected consequences in different environments/tool chains/etc. As to "understandability", you can't (realistically) quantify that. But, you know it when you see it. :> OTOH, you also know when something is unclear and/or prone to misunderstanding (e.g., if you're counting parenthesis, you've probably got an expression that could benefit from reduction). > Don't >> force extra *syntax* on the code just to make it fit >> some (well intended, though arbitrary) rule. >> >> E.g., how do you handle: >> >> void >> task(void) { >> while (FOREVER) { >> lamp(ON); >> sleep(ON_TIME); >> lamp(OFF); >> sleep(OFF_TIME); >> } >> } >> >> and still satisfy the "shall" in your rule? > > lamp.toggle(ON_TIME, OFF_TIME, FOREVER); In case you failed to see my point: void user_interface(void) { while (FOREVER) { event_t event = get_event(source); (void) process_event(event); } }
From: Chris Burrows on 7 Jun 2010 19:59 "rickman" <gnuarm(a)gmail.com> wrote in message news:5aeb2f93-56f8-4638-91fb-7cffa7da75da(a)y12g2000vbg.googlegroups.com... On Jun 7, 8:48 am, Vladimir Vassilevsky <nos...(a)nowhere.com> wrote: >> >> A piece of code shall have only one entry point and only one exit point. >> > The reason for this rule is to > facilitate debugging and allow breakpoints to be set at the single > exit of a routine. There are other reasons why 'one exit point' is a good rule (...of thumb). One is that multiple exit points lead to maintenance problems. They are often hard to spot when reading real world code. If new code that always has to be executed, is added later, it is easy to overlook that a premature exit might prevent it from happening. The sensibility of the 'one entry point' rule should need no explanation. -- Chris Burrows CFB Software Astrobe: ARM Oberon-07 Development System http://www.astrobe.com
From: David Brown on 8 Jun 2010 03:15 On 08/06/2010 01:59, Chris Burrows wrote: > "rickman"<gnuarm(a)gmail.com> wrote in message > news:5aeb2f93-56f8-4638-91fb-7cffa7da75da(a)y12g2000vbg.googlegroups.com... > On Jun 7, 8:48 am, Vladimir Vassilevsky<nos...(a)nowhere.com> wrote: >>> >>> A piece of code shall have only one entry point and only one exit point. >>> > >> The reason for this rule is to >> facilitate debugging and allow breakpoints to be set at the single >> exit of a routine. > > There are other reasons why 'one exit point' is a good rule (...of thumb). > One is that multiple exit points lead to maintenance problems. They are > often hard to spot when reading real world code. If new code that always has > to be executed, is added later, it is easy to overlook that a premature exit > might prevent it from happening. > > The sensibility of the 'one entry point' rule should need no explanation. > The implication of what you write here is that it's okay to modify functions that you have barely skimmed, because you know they will always run to the end. You must read and understand functions and their flow of control before you modify them. A coding style that makes it easier to read and understand the functions therefore makes maintenance easier. So if multiple returns makes the code clearer, it's a good thing. As an example, consider the very common template: void foo(int *p) { if (!p) return; ... do something with *p } That is clearer than: void foo(int *p) { if (p) { ... do something with *p } } The first version removes an extra layer of block indents, making the function slightly flatter and slightly clearer.
From: Boudewijn Dijkstra on 8 Jun 2010 03:47
Op Mon, 07 Jun 2010 23:23:20 +0200 schreef D Yuniskis <not.going.to.be(a)seen.com>: > Vladimir Vassilevsky wrote: >> D Yuniskis wrote: >>> Vladimir Vassilevsky wrote: >>>> kishor wrote: >>>> >>>>> I have some doubt in using "if" "else" statements. >>>>> Which is the better method (for efficiency, readability or any other >>>>> reason)????. >>>> >>>> >>>> A piece of code shall have only one entry point and only one exit >>>> point. >>> >>> >>> As with most "coding rules", I *really* disagree with that! :> > My coding standards are titled "Coding GUIDELINES". > > As to "understandability", you can't (realistically) > quantify that. But, you know it when you see it. :> > >> Don't >>> force extra *syntax* on the code just to make it fit >>> some (well intended, though arbitrary) rule. >>> >>> E.g., how do you handle: >>> > void > user_interface(void) { > while (FOREVER) { > event_t event = get_event(source); if (!event) { break; } > (void) process_event(event); > } > } -- Gemaakt met Opera's revolutionaire e-mailprogramma: http://www.opera.com/mail/ (remove the obvious prefix to reply by mail) |