Brace Style? Why should I care? 
Author Message
 Brace Style? Why should I care?

After already spending my $2e-02 on this issue (recommending K&R OTBS)
let's add some more flamebait:

  Why should I ever care what brace style me or anyone else is using?

  The whole discussion reminds me of the 'optimization' threads.
  Many programmers will care to spend days tuning their code to
  make it run 0.1% faster. Ridiculous, isn't it?

  Management will never get tired of seeking pseudo-scientific justification
  that one brace style is superior over the other because of redability,
  comprehensibilty (sp?), maintainability or whatever bogus reason they
  may care to name.

Let's face it, fellow programmers:

  If a particular brace style reduces (or improves) readability or whatever
  so that it takes you 0.1% more or less time to understand what the code
  does -- SO WHAT! I could not care less. What is time consuming is under-
  standing the *semantics* of the code. And any *code layout* will aid or
  harm only to a *negligible* amount. (Leaving IOCCC source aside :-)

Let me illustrate my point by quoting a recent article:
[this is about white space style actually, but I hope you get the point]

Quote:
>For if's, and such, I would hesitantly point out that these aren't
>functions, and shouldn't be written as though they were functions.
>Writing ``if ( ... )'' and ``sin( ... )'' helps achieve that.

  Oh boy. If anyone could be confused by that, s/he better look
  for another job.
  Let's make a survey: everyone who ever took 'if()' as a function
  e-mail me when and why. [Everybody who never did please do so, too]

  In a similar spirit, everybody who uses

          if (cond) {
                ...
          } else {
                ...
          }

  and is confused to the max upon reading

          if(cond)
          {
                ...
          }
          else
          {
                ...
          }

  (or vice versa) please email me when and why. I will summarize.

Unbelievable what traffic these 'brace style' threads produce.
Aren't there better issues to talk about? Dear mod: How about
excluding brace style from the list of on-topic issues? What
about pointing inquiring minds to the unmoderated c.l.c?

[Well, I feel bad bouncing posts that aren't, say, about inflatable sex
 VGA cards for Windows NT, now hiring in Georgia.  -mod]

Phew. I feel better now.

        Jens
--

SIGSIG -- signature too long (core dumped)



Thu, 29 Apr 1999 03:00:00 GMT  
 Brace Style? Why should I care?

Quote:

>Unbelievable what traffic these 'brace style' threads produce.
>Aren't there better issues to talk about? Dear mod: How about
>excluding brace style from the list of on-topic issues? What
>about pointing inquiring minds to the unmoderated c.l.c?

The brace style thread introduced me to ideas that I hadn't thought of
before. It also made me think about, "How should I decide on a good style
for my own code, instead of just blindly using the one that I have
'evolved' over time?" And it provided a reference to a fairly good (though
expensive) book: "C Style: Standards and Guidelines" by David Straker.

I have no objection of the moderator stops the thread (including this
message), but it was worthwhile for at least some people.

-------------------------------------
Michael A. Quinlan

http://www.primenet.com/~mikeq
"If it doesn't fit, you must acquit!"
-------------------------------------



Thu, 29 Apr 1999 03:00:00 GMT  
 Brace Style? Why should I care?

Quote:

>   Why should I ever care what brace style me or anyone else is using?

>   Management will never get tired of seeking pseudo-scientific justification
>   that one brace style is superior over the other because of redability,
>   comprehensibilty (sp?), maintainability or whatever bogus reason they
>   may care to name.
> I agree.  There are many "valid" styles of code layout.  *Which* one you choose

is not so important, *that* you choose one is - especially if you are working
as part of a programming team.

Quote:
>   What is time consuming is under-standing the *semantics* of the code.
>   And any *code layout* will aid or harm only to a *negligible* amount.

Actually code layout *does* make a difference on the ability to understand
code.  The basis for why lies in the realm of Cognitive Psychology.  There
have been studies done that show that structure helps experts to perceive,
comprehend, and remember important features of programs.

"Our studies support the claim that knowledge of programming plans and
rules of discourse can have a significant impact on program comprehension.
In their book 'The Elements of Programming Style', Kernighan and Plauger also
identify what we would call discourse rules.  Our empirical results put
teeth in these rules: It is not merely a matter of aesthetics that
programs should be written in a particular style.  Rather there is a
psyhological basis for writing programs in a conventional manner: programmer
have strong expectations that other programmers will follow these discourse
rules.  If the rules are violated, then the utility afforded by the
expectations that programmers have built up over time is effectively
nullified."  Soloway,and Ehrlich, 1984  -"Empirical Studies of Programming
Knowledge"

This and other studies show that structure helps experts to perceive,
comprehend, and remember important features of programs, and the it
helps more and more as the experience of the programmer increases.
Choosing a reasonable layout style and sticking with is important.

Quote:
> Let me illustrate my point by quoting a recent article:
> [this is about white space style actually, but I hope you get the point]

> >For if's, and such, I would hesitantly point out that these aren't
> >functions, and shouldn't be written as though they were functions.
> >Writing ``if ( ... )'' and ``sin( ... )'' helps achieve that.

>   Oh boy. If anyone could be confused by that, s/he better look
>   for another job.
>   Let's make a survey: everyone who ever took 'if()' as a function
>   e-mail me when and why. [Everybody who never did please do so, too]

>   In a similar spirit, everybody who uses

>           if (cond) {
>                 ...
>           } else {
>                 ...
>           }

>   and is confused to the max upon reading

>           if(cond)
>           {
>                 ...
>           }
>           else
>           {
>                 ...
>           }

>   (or vice versa) please email me when and why. I will summarize.

No I am not going to be "confused to the max" on reading either of these.
I will however comprehend code more rapidly (and likely more accurately)
if it consistently follows one style or the other.  
Like you say, understanding the semantics of the code is the hard part. Any
deviations from a standard layout styles are just unneccessary distractions
from that task.  When there is a non-trivial body of code to read and
understand (and working in the real world, this is often the case) the
results of these distractions can be significant.

To summarize :  There are many reasonable styles of code layout.  *Which* one
you choose is not important, but it is *very* important to pick one and
to stick with it.

Tom Keane



Sat, 01 May 1999 03:00:00 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. SUMMARY: Brace style -- why should I care?

2. C Brace Style

3. one true brace style

4. 'One True Brace Style'

5. Bracing style (was Re: Teacher mistake on code ???)

6. why no braces for single statement blocks?

7. WHY NO BRACES FOR SINGLE

8. re : why no braces for single statement blocks?

9. why was C coding style not standardized?

10. Why is WS_OVERLAPPED always being set as style?

11. I can't modify combox style ,why?

12. Why don't extended styles work.

 

 
Powered by phpBB® Forum Software