Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Blocks, or not?

Reply
Thread Tools

Blocks, or not?

 
 
Gordon Burditt
Guest
Posts: n/a
 
      08-21-2005
>> Once, when modifying code, I made a mistake that could have
>> been avoided if I had originally written the code with braces.
>> I can't remember what the mistake was.

>
>You avoid that problem if you write the braceless versions as:
>
> if (condition) action();
>
>i.e. in one line. You also save vertical space and make your code
>more readable.


You can just as well make the mistake:

if (condition) action(); action2();

and I'll disagree that the code is more readable if either condition
or action() takes up much more horizontal space than shown above.
In other words:

if (color != NULL && color[0] != '\0') printf("A color (%s) has already been assigned to %s\n", color, objectname);

is better written on multiple lines.

Gordon L. Burditt
 
Reply With Quote
 
 
 
 
Malcolm
Guest
Posts: n/a
 
      08-21-2005

"Rob" <(E-Mail Removed)> wrote
>
> Functionally, the two following pieces of code are the same:
>
> if(p == NULL) {
>
> break;
> }
>
> if(p == NULL)
> break;
>
> However, I am wondering whether there are any performance implications
> in choosing one over the other. Is there any extra overhead created by
> defining a block? Will a compiler optimize the former code to the
> latter? Does it even need to?
>
> The reason I ask is, I'd much prefer to go with the former code, simply
> because I prefer the appearance.
>

The cost is two extra characters in your source, plus extra space. There
will be no difference in the compiled code.
So as far as the narrow technical issues are concerned, go with the former.

However you want to consider whether you are writing beginner's C. For a
leaner, code set out with lots of braces, lots of whitespace, and lots of
comments is easier to read, because he doesn't really know the syntax very
well. To the expert this becomes annoying.

I would write

if(!p)
break;

not to save typing or ACSII source, but because the break statement must
already be nested within a block, and to introduce an extra level of curly
braces just confuses things.


 
Reply With Quote
 
 
 
 
CBFalconer
Guest
Posts: n/a
 
      08-21-2005
Gordon Burditt wrote: (and failed to preserve attributions)
>

.... snip ...
>>
>> You avoid that problem if you write the braceless versions as:
>>
>> if (condition) action();
>>
>> i.e. in one line. You also save vertical space and make your code
>> more readable.

>
> You can just as well make the mistake:
>
> if (condition) action(); action2();
>
> and I'll disagree that the code is more readable if either condition
> or action() takes up much more horizontal space than shown above.


If any line exceeds about 72 chars it should be split. The above
error should not happen, because there is no indentation to lull
the revisor. I.e. having:

if (condition)
action();

is more likely to be fouled on revision. However if you need:

if (long_winded_excruciating_conditional_expression) {
action();
}

is better written with the braces just to keep the line length
down.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

 
Reply With Quote
 
Spiro Trikaliotis
Guest
Posts: n/a
 
      08-22-2005
Hello,

CBFalconer <(E-Mail Removed)> wrote:

> You avoid that problem if you write the braceless versions as:
>
> if (condition) action();
>
> i.e. in one line. You also save vertical space and make your code
> more readable.


Obviously, you never had to deal with 3rd party environments like the
Windows DDK, where many 'function calls' are actually macros (which are
not "guarded" via "do { ... } while (0)"), do you?

To add to the confusion, the "what-is-a-macro, what-is-a-function"
properties are subject to change between different version of the DDK,
and even between different compile options of the DDK.

Even if you do not need this environment yourself, you or a collegue of
your might be required to take the code you wright today and use it in
the future with such an environment. I'd like to tell: Have fun!

Regards,
Spiro.

--
http://www.trikaliotis.net/
 
Reply With Quote
 
Emmanuel Delahaye
Guest
Posts: n/a
 
      08-22-2005
Spiro Trikaliotis wrote on 22/08/05 :
> Obviously, you never had to deal with 3rd party environments like the
> Windows DDK, where many 'function calls' are actually macros (which are
> not "guarded" via "do { ... } while (0)"), do you?


Good point !

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

..sig under repair


 
Reply With Quote
 
John Bode
Guest
Posts: n/a
 
      08-22-2005

Rob wrote:
> Functionally, the two following pieces of code are the same:
>
> if(p == NULL) {
>
> break;
> }
>
> if(p == NULL)
> break;
>
> However, I am wondering whether there are any performance implications
> in choosing one over the other. Is there any extra overhead created by
> defining a block? Will a compiler optimize the former code to the
> latter? Does it even need to?
>
> The reason I ask is, I'd much prefer to go with the former code, simply
> because I prefer the appearance.


I would be surprised (nay, astonished) if there were a runtime
performance difference between the two, but I've learned to never say
never when it comes to things like this. I wouldn't worry about it,
though.

My personal bias is to put everything in a compound statement, whether
it actually contains more than one statement or not, just because I've
been bitten too many times in the past by the

if (a)
b; c;

bug. And I prefer my code to have a little vertical breathing space;
it just makes it easier for *me* to read.

 
Reply With Quote
 
Michael Wojcik
Guest
Posts: n/a
 
      08-22-2005

In article <(E-Mail Removed)>, "Emmanuel Delahaye" <(E-Mail Removed)> writes:
> Spiro Trikaliotis wrote on 22/08/05 :
> > Obviously, you never had to deal with 3rd party environments like the
> > Windows DDK, where many 'function calls' are actually macros (which are
> > not "guarded" via "do { ... } while (0)"), do you?

>
> Good point !


Unfortunately, it is equivalent to the thesis "You may encounter
problems if you use headers written by idiots", which ought to be
patently obvious; and as such is not particularly informative or
useful.

Clearly, if you are working in an environment where inobvous macros
with nasty syntatic or semantic side effects have been defined,
pretty much any coding practice could be dangerous.

--
Michael Wojcik http://www.velocityreviews.com/forums/(E-Mail Removed)

An intense imaginative activity accompanied by a psychological and moral
passivity is bound eventually to result in a curbing of the growth to
maturity and in consequent artistic repetitiveness and stultification.
-- D. S. Savage
 
Reply With Quote
 
akarl
Guest
Posts: n/a
 
      08-22-2005
Rob wrote:
> Functionally, the two following pieces of code are the same:
>
> if(p == NULL) {
>
> break;
> }
>
> if(p == NULL)
> break;
>
> However, I am wondering whether there are any performance implications
> in choosing one over the other. Is there any extra overhead created by
> defining a block? Will a compiler optimize the former code to the
> latter? Does it even need to?
>
> The reason I ask is, I'd much prefer to go with the former code, simply
> because I prefer the appearance.
>


As others have pointed out, the difference in terms of efficiency is
negligible.

As far as I know, all languages in the Pascal tradition after Pascal do
require explicit termination of control statements (we're talking 1970's
here). What seemed to be a good idea at first -- the distinction between
statements and statement sequences in control statements (e.g. Algol,
Pascal and C) -- turned out not to be, so I see no reason why ANSI/ISO
never decided to make braces mandatory in C.

As I see it, the advantages of explicit control statement termination are:

* Bugs are avoided (multiple statements on one line, the classical
else-if situation, wrong indentation...)

* If you use braces only when necessary, you have to decide if they are
required or not at every control statement you write. If you add one
statement to a single statement you have to add the braces, and if you
remove one of two statements you probably want to remove the braces as
well to achieve consistency throughout the code. This requires some
extra editing. Since all choices in programming are distracting, the
irrelevant ones should be removed.

* With explicit control statement termination the language gets less
complicated and more regular.


Disadvantage:

* The code gets somewhat more cluttered and slightly less readable in
case of short control statements.


August
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      08-26-2005
Eric Sosman <(E-Mail Removed)> writes:

> Rob wrote:
> > Functionally, the two following pieces of code are the same:
> >
> > if(p == NULL) {
> >
> > break;
> > }
> >
> > if(p == NULL)
> > break;
> >
> > However, I am wondering whether there are any performance implications
> > in choosing one over the other. Is there any extra overhead created by
> > defining a block? Will a compiler optimize the former code to the
> > latter? Does it even need to?

>
> This wins the Grand Prize for worrying about the
> wrong things.



Eric, please consult the Awards Committee. In this case it
seems more appropriate to award the Grand Prize for
wondering whether to worry about the wrong thing. That's
not nearly so prestigious an award.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off




Advertisments