Prev: Need help on getting the original source code of eZ430 Chronos
Next: email client: POP vs. POP3 differences
From: RockyG on 7 Jun 2010 10:35
>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 !=3D 32)
> return 3;
> else if (int2 !=3D 16)
> return 2;
> else if (int3 !=3D 8)
> return 1;
> else
> return 0;
>}
A nitpick. The else is completely unnecessary. Regarding the braces, I use
them if the true statement is not on the same line as the if, even if it is
only on statement.

---------------------------------------
Posted through http://www.EmbeddedRelated.com
From: David Brown on 7 Jun 2010 13:34
RockyG 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 !=3D 32)
>> return 3;
>> else if (int2 !=3D 16)
>> return 2;
>> else if (int3 !=3D 8)
>> return 1;
>> else
>> return 0;
>> }
> A nitpick. The else is completely unnecessary. Regarding the braces, I use
> them if the true statement is not on the same line as the if, even if it is
> only on statement.
>

I agree on that regarding the braces. I think the style with slightly
indented if "true" statements on their own line is horrible - they are
hard to spot, and very easy to get wrong. And when someone modifies it
to have two statements, it's easy to break. If the "true" statement is
short and clearly a single statement (such as "return 3;") with no
possibility of being a macro, then it can be neater to have it on the
same line. If you need a new line, use braces and indent. And if you
need an "else", then you /always/ want to use braces and indent - code
using multiple if's and else's without braces and indents is right out.

Of course, there are other ways to format you if's. But there is only
one /good/ way :-)
From: rickman on 8 Jun 2010 12:34
On Jun 7, 10:35 am, "RockyG" <RobertGush(a)n_o_s_p_a_m.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;
> >}
>
> A nitpick. The else is completely unnecessary. Regarding the braces, I use
> them if the true statement is not on the same line as the if, even if it is
> only on statement.        

Ok, have it your way, even better!


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;
}

Very short and still perfectly clear! Actually, this is starting to
look a bit like Forth! There is a technique in Forth where you use a
semicolon in the middle of a definition as a return. This serves as
the terminator of the then part of a definition so it would look like

: Func1 int1 32 <> if 3 ; int2 16 <> if 2 ; int3 8 <> if 1 ; 0 ;

Normally a semicolon terminates a definition, but in this case it is
equivalent to a return. I don't expect people here to appreciate this
since it will obviously offend the sense of style if you are used to
using brackets on single statement blocks. But Forth can have its own
sense of style and greatly encourages paring down complexity allowing
the simplicity of the algorithm to emerge.

Rick
 | 
Pages: 1
Prev: Need help on getting the original source code of eZ430 Chronos
Next: email client: POP vs. POP3 differences