Which is the better method to use "if else" statements
in [Embedded]
|
From: Chris Burrows on 8 Jun 2010 08:43 "David Brown" <david(a)westcontrol.removethisbit.com> wrote in message news:4c0dee1d$0$4111$8404b019(a)news.wineasy.se... >> >> 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 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. > Not at all. It is an observation that humans are fallible and it is easy to overlook a single word (return) buried in many lines of code. At least in my language of choice (Oberon) RETURN is always capitalised so it stands out from the crowd. The above sentence speaks for itself.
From: Chris Burrows on 8 Jun 2010 08:57 "David Brown" <david(a)westcontrol.removethisbit.com> wrote in message news:4c0dee1d$0$4111$8404b019(a)news.wineasy.se... > > 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. > I disagree. The fact that the second version is not flatter is a clear indication that the body is conditionally executed. If that were not true you could just make it flatter by removing all indentation!
From: rickman on 8 Jun 2010 12:03 On Jun 7, 7:59 pm, "Chris Burrows" <cfbsoftw...(a)hotmail.com> wrote: > "rickman" <gnu...(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 ability to spot an exit point is a different issue than having one vs. multiple exit points. Yes, I will agree that having multiple exits can make the code harder to read, but the key word here is "can". In the "real world", coding is done by humans and humans can determine when to follow guidelines and when to break them. The code being discussed is a perfect example of when multiple returns can be perfectly clear. BTW, the only rule I use is one that says the word "shall" shall not be used in coding guidelines. Rick
From: rickman on 8 Jun 2010 12:08 On Jun 7, 10:26 am, Spehro Pefhany <speffS...(a)interlogDOTyou.knowwhat> wrote: > On Mon, 7 Jun 2010 06:27:37 -0700 (PDT), rickman <gnu...(a)gmail.com> > wrote: > > > > >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 > > Why waste all those linefeeds when you can simply write > > uint16_t func(uint16_t i1, uint16_t i2, uint16_t i3) > {return i1 != 32 ? 3: i2 != 16 ? 2: i3 !=8 ? 1 : 0;} > > ? ;-) I assume the winky means no response is needed? BTW, I don't live the the ever storage conscious Unix/Linux world. Real men use CR/LF pairs. Rick
From: Rob Gaddi on 8 Jun 2010 12:21
On 6/8/2010 9:08 AM, rickman wrote: > On Jun 7, 10:26 am, Spehro Pefhany<speffS...(a)interlogDOTyou.knowwhat> > wrote: >> On Mon, 7 Jun 2010 06:27:37 -0700 (PDT), rickman<gnu...(a)gmail.com> >> wrote: >> >> >> >>> 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 >> >> Why waste all those linefeeds when you can simply write >> >> uint16_t func(uint16_t i1, uint16_t i2, uint16_t i3) >> {return i1 != 32 ? 3: i2 != 16 ? 2: i3 !=8 ? 1 : 0;} >> >> ? ;-) > > I assume the winky means no response is needed? > > BTW, I don't live the the ever storage conscious Unix/Linux world. > Real men use CR/LF pairs. > > Rick Humbug. As a devout Linux user I scoff at your carriage returns. If I want a carriage return, I'll smack the right side of the monitor. -- Rob Gaddi, Highland Technology Email address is currently out of order |