From: D Yuniskis on 7 Jun 2010 08:59 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. 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?
From: rickman on 7 Jun 2010 09:27 There is one other way to write this that I tend to use when coding. One of the "guides" to coding I read many years ago, perhaps in college said the smaller of the two choices in an if then else should be first. This makes it easier for the eye to scan the code and glean structure from the shape... a bit like the way I learned to read... look for the outline of the words rather than parsing every letter. Also,, it is not uncommon for the else and the if to be put on the same line to show that the "if" is the only statement within the else. The result is very clean, simple and uses much less space streamlining the code to the point that the structure is very clear to the eye. Oh, and you don't need all those parens for single statements. uint16_t Func1(uint16_t int1, uint16_t int2, uint16_t int3) { if (int1 != 32) return 3; else if (int2 != 16) return 2; else if (int3 != 8) return 1; else return 0; } Rick On Jun 7, 4:49 am, kishor <kiis...(a)gmail.com> wrote: > Hi friends, > > I have some doubt in using "if" "else" statements. > > uint16_t Func1(uint16_t int1, uint16_t int2, uint16_t int3) > { > > if(int1 == 32) > { > if(int2 == 16) > { > if(int3 == 8) > { > return 0; > } > else > { > return 1; > } > } > else > { > return 2; > } > } > else > { > return 3; > } > > } > > ======================= OR ============================== > > uint16_t Func1(uint16_t int1, uint16_t int2, uint16_t int3) > { > if(int1 != 32) > { > return 3; > } > > if(int2 != 16) > { > return 2; > } > > if(int3 != 8) > { > return 1; > } > > return 0; > > } > > Which is the better method (for efficiency, readability or any other > reason)????. > > Thanks & Regards, > Kishore.
From: rickman on 7 Jun 2010 09:36 On Jun 7, 8:48 am, Vladimir Vassilevsky <nos...(a)nowhere.com> wrote: > kishor wrote: > > Hi friends, > > > 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. > > Vladimir Vassilevsky > DSP and Mixed Signal Design Consultanthttp://www.abvolt.com Only small minds follow rules blindly. The reason for this rule is to facilitate debugging and allow breakpoints to be set at the single exit of a routine. All of the tools I have used all me to set a breakpoint at the final semicolon which is where the actual exit from the routine is found. Rick
From: David Brown on 7 Jun 2010 09:38 On 07/06/2010 14:48, Vladimir Vassilevsky wrote: > > > kishor wrote: >> Hi friends, >> >> 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. > A piece of code shall have only one entry point unless it is a coroutine, which is fairly specialised programming because C doesn't support coroutines well. A piece of code shall have only one exit point unless it is clearer and neater to have more than one exit. In my mind, the neatest way to write this code is: uint16_t Func1(uint16_t int1, uint16_t int2, uint16_t int3) { if (int1 != 32) return 3; if (int2 != 16) return 2; if (int3 != 8) return 1; return 0; } Of course, parameter names and the various numbers should be replaced by sensible names and symbolic constants, and you may need comments (if the names are not clear enough). That breaks another rule of good C programming - /always/ use brackets with "if" statements. But by being neat and compact, it is easy to see what is going on - and that trumps most other rules.
From: Boudewijn Dijkstra on 7 Jun 2010 09:38
Op Mon, 07 Jun 2010 14:59:57 +0200 schreef D Yuniskis <not.going.to.be(a)seen.com>: > 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. 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? static void callback_on(void) { lamp(ON); timer(callback_off, ON_TIME); } static void callback_off(void) { lamp(OFF); timer(callback_on, OFF_TIME); } void main(void) { callback_on(); } -- Gemaakt met Opera's revolutionaire e-mailprogramma: http://www.opera.com/mail/ (remove the obvious prefix to reply by mail) |