467,859 Members | 1,381 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 467,859 developers. It's quick & easy.

matching { } syntax style

Why is it that everybody likes the follwowing curly braces syntax

function() {
implementations;
}

I find the following much better to read (C style)

function()
{
implementations;
}

kind regards,
Bart
Jul 19 '05 #1
  • viewed: 2133
Share:
31 Replies
> Why is it that everybody likes the follwowing curly braces syntax

function() {
implementations;
}
They don't. Some like it and some don't.
I find the following much better to read (C style)

function()
{
implementations;
}


For style, I follow the ultimate acknowledge reference for English - /The
Elements of Style/.

It says to use parallel construction on parallel concepts.

Don't say, "The big red lion lay down with the lamb, small and furry".

Say, "The big red lion lay down with the small furry lamb."

The adjectives parallel their relation to their noun.

So, in programming, put the curly braces where they parallel each other.

--
Phlip
Jul 19 '05 #2

"bart" <ba**@thatissecret.nlm> wrote in message
news:3f***********************@news.xs4all.nl...
Why is it that everybody likes the follwowing curly braces syntax

function() {
implementations;
}

I find the following much better to read (C style)

function()
{
implementations;
}


I don't think everybody does like the former. I think at least half the
people prefer the latter.
Jul 19 '05 #3

"bart" <ba**@thatissecret.nlm> wrote in message news:3f***********************@news.xs4all.nl...
Why is it that everybody likes the follwowing curly braces syntax

function() {
implementations;
}

I find the following much better to read (C style)

function()
{
implementations;
}

What makes you think the latter is C style? And what makes you think it's
easier to read?
Jul 19 '05 #4
bart wrote:
Why is it that everybody likes the follwowing curly braces syntax

function() {
implementations;
}

I find the following much better to read (C style)

function()
{
implementations;
}

kind regards,
Bart


Some of us don't like either; they're there to make compiler writers lives
easier, not ours.
Jul 19 '05 #5
While it was 10/10/03 2:50 pm throughout the UK, bart sprinkled little
black dots on a white screen, and they fell thus:
Why is it that everybody likes the follwowing curly braces syntax

function() {
implementations;
}
I'm one of everybody, amn't I? I personally hate it when people can't
be bothered to indent.
I find the following much better to read (C style)

function()
{
implementations;
}


Well, I guess that

function() {
implementations;
}

gives the best of both worlds. :-)

Stewart.

--
My e-mail is valid but not my primary mailbox. Please keep replies on
on the 'group where everyone may benefit.

Jul 19 '05 #6
bart wrote:
Why is it that everybody likes the follwowing curly braces syntax

function() {
implementations;
}

I find the following much better to read (C style)

function()
{
implementations;
}

kind regards,
Bart


Some people like this style:
return_type
function()
{
implementation;
}
The braces show the indentation.

I prefer to have the braces line up to help show the indentation
levels.

But this is what they call a religious issue; there is no
correct answer, only what people believe.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book

Jul 19 '05 #7
Hi bart,
function() {
implementations;
}
This style has a very big advantage when you use a single-line debugger, In
fact not for a function. Try an if instead.

When you use these two cases with a single-line debugger...

if (someboolexpression)
dosomething;

if (someboolexpression) {
dosomethingmore;
}

...and the line with an if appears the curly brace tells you that a block is
following. If not one single command follows.
function()
{
implementations;
}


I personally like this style more. In my opinion it is more readable. But I
do not use a single-line debugger. So I assume that I am not part of
"everybody".

Regards,
Patrick
Jul 19 '05 #8
Tim Clacy wrote:
bart wrote:
Why is it that everybody likes the follwowing curly braces syntax

function() {
implementations;
}

I find the following much better to read (C style)

function()
{
implementations;
}

kind regards,
Bart


Some of us don't like either; they're there to make compiler writers
lives easier, not ours.


....and just to set the cat amongst the pigeons, I'm quite fond of this:

void fn() {
while (...) {
switch (...) {
case :
case :
default : } } }

:-)
Jul 19 '05 #9
bart wrote:

Why is it that everybody likes the follwowing curly braces syntax

function() {
implementations;
}

I find the following much better to read (C style)
If anything, the former is C-style, as it was used by the originators of
C in K&R. Often refered to as K&R style or OTBS (one true brace style).

function()
{
implementations;
}

I have a preference for Whitesmith's style:

if (1)
{
std::cout << "code!\n";
}
Just pick a style and use it consistently.

Brian Rodenborn
Jul 19 '05 #10
... And what makes you think it's easier to read?


Umm...the fact that *he* finds it easier to read, perhaps? (Does an opinion
need a reason?) And I agree. For some reason (i have no idea why), I find
it much easier to quickly spot braces that are aligned vertically than a
closing brace matching the start of a line of text. So, for me, it's easier
to read.

On the other hand, my boss, who wrote the code I'm updating and maintaining,
likes it the other way. Must be why he's the boss. :-)

-Howard


Jul 19 '05 #11

"bart" <ba**@thatissecret.nlm> wrote in message
news:3f***********************@news.xs4all.nl...
Why is it that everybody likes the follwowing curly braces syntax

function() {
implementations;
}

I find the following much better to read (C style)

function()
{
implementations;
}

kind regards,
Bart


I prefer your second style in functions only. If statement blocks like I
prefer to use the first. I just don't see the point in dedicating an ENTIRE
line to a measly '{'. I'd much rather write:

if (x == 10) {

}

than:

if (x == 10)
{

}

As long as my closing '}' is lined up DIRECTLY under the statement that
opened it, I find it easy to read.

Jul 19 '05 #12
bart wrote:
Why is it that everybody likes the follwowing curly braces syntax

function() {
implementations;
}

I find the following much better to read (C style)

function()
{
implementations;
}


Pick a style any style and stick to it. Personally I prefer

function()
{
if (expression) {
statements;
}
}

but that is because it is our house style. Prior to my
current place I preferred another style, it doesn't matter a
jot, which you use. But if you are programming with others a
standard style is a great help. I can look over any piece of
code in the company and the layout is the same, it looks my
code, and my code looks like anyone else's. The standard
layout helps you to understand what is happening.
Occasionally we receive code from some outside source that
does not conform to our standard, and it is always
difficult to read. That doesn't mean that it is wrong, or a
bad style, its just that it isn't the one we are used to.
Jul 19 '05 #13
"bart" <ba**@thatissecret.nlm> wrote in message news:<3f***********************@news.xs4all.nl>...
Why is it that everybody likes the follwowing curly braces syntax

function() {
implementations;
}

I find the following much better to read (C style)

function()
{
implementations;
}

kind regards,
Bart


Bart...I agree with the others. It's a matter of preference. I'm
pretty new to C++, and as I was getting started, I read several essays
on styles. I ended up using Bruce Eckel's book's style. eg:

function(){
implementations;
}

I like this style because:
1) it takes up less space, vertically.
2) you read the function name, immediately see the open bracket, and
then look down to where the scope for that indentation ends.

My one minor exception to that I sometimes adopt is for if else
statements:

function(){
if(expression){
statement1;
statement2;
}else{
statement1;
statement2;
}
}

However, I also sometimes do single line if else if it fits nicely
onto one line.

function(){
if(expression) statement; else statement;
}
Jul 19 '05 #14
Tim Clacy wrote:
...and just to set the cat amongst the pigeons, I'm quite fond of this:

void fn() {
while (...) {
switch (...) {
case :
case :
default : } } }

:-)


I'm fond of very short functions, and replacing switch statements with
virtual messages, so my bad-ass pidgeon is not alarmed by your silly
little cat.

--
Phlip
Jul 19 '05 #15
"J. Campbell" <ma**********@yahoo.com> wrote in message
news:b9**************************@posting.google.c om...
<snip>
< However, I also sometimes do single line if else if it fits nicely
< onto one line.
<
< function(){
< if(expression) statement; else statement;
< }

I don't meant to be fickle (I think this is the first occasion of me using
that word :)
but if your expression and statements fit nicely on a single line, wouldn't
you be better off writing

expression ? true_statement : false_statement;

That way, you dont have to write if, any brackets, an extra ; and the else.
Jul 19 '05 #16
Clive wrote:
"J. Campbell" <ma**********@yahoo.com> wrote in message
news:b9**************************@posting.google.c om...
<snip>
< However, I also sometimes do single line if else if it fits nicely
< onto one line.
<
< function(){
< if(expression) statement; else statement;
< }

I don't meant to be fickle (I think this is the first occasion of me using
that word :)
but if your expression and statements fit nicely on a single line, wouldn't
you be better off writing

expression ? true_statement : false_statement;

That way, you dont have to write if, any brackets, an extra ; and the else.


The problem with both of these 'styles' is that you can't
put a simple breakpoint on any of the statements. The best
you can do is put a conditional breakpoint (based on
expression) on the line and then single step the expression.

With the tertiary expression both true_statement and
false_statement also have to be type compatible.

Jul 19 '05 #17
Phlip wrote:
Tim Clacy wrote:
...and just to set the cat amongst the pigeons, I'm quite fond of
this:

void fn() {
while (...) {
switch (...) {
case :
case :
default : } } }

:-)


I'm fond of very short functions, and replacing switch statements with
virtual messages, so my bad-ass pidgeon is not alarmed by your silly
little cat.


The shorter the function, the more the relative waste of space the braces
become; so where so you put your braces in your 'very short functions'? How
about:

struct A {
virtual void fn0() { ... }
virtual void fn1() { ... }
virtual void fn2() { ... } };
Jul 19 '05 #18

"Clive" <cl***@clive.clive> wrote in message
news:bm**********@enyo.uwa.edu.au...

I don't meant to be fickle (I think this is the first occasion of me using
that word :)
but if your expression and statements fit nicely on a single line, wouldn't you be better off writing

expression ? true_statement : false_statement;


Statements are not allowed in expressions. You cannot
write, for instance ...

someFlag ? continue : break;

Also, if you used the syntactically correct form of...

expression ? true_expression : false_expression;

.... instead, it still must also be semantically correct so
that the types returned by the sub-expressions are
assignable to a common type (which then becomes the
type of the entire expression). This, for instance,
would be syntactically correct, but semantically illegal:

someFlag ? 123 : "";

IMO, it is always better to use the if(){}else{} instead
of the ?: operator in all contexts that allow a statement,
and use the conditional operator only when the context
*requires* (rather than just *allows*) an expression.

Cheers!

- Risto -

Jul 19 '05 #19
While it was 13/10/03 10:15 am throughout the UK, Risto Lankinen
sprinkled little black dots on a white screen, and they fell thus:
<snip>
This, for instance, would be syntactically correct, but semantically illegal:

someFlag ? 123 : "";
But I've just tried

someFlag ? (void) 123 : (void) "";

and gcc/g++ accepts it.
IMO, it is always better to use the if(){}else{} instead
of the ?: operator in all contexts that allow a statement,
and use the conditional operator only when the context
*requires* (rather than just *allows*) an expression.


Guess you're kind of right there.

But, which do most people prefer:

if(qwert > 100) {
yuiop = 50;
} else {
yuiop = 25;
}

or

yuiop = (qwert > 100) ? 50 : 25;

or even

yuiop = ((qwert > 100) + 1) * 25;

....?

Stewart.

--
My e-mail is valid but not my primary mailbox. Please keep replies on
on the 'group where everyone may benefit.

Jul 19 '05 #20
In order to avoid these kind of "religious" matters, I was looking for a
tool enabling each developper to have his own style.

Found "C++ SourceStyler" from OchreSoftware
(http://www.sourcestyler.com/) but it is expensive and not available on
Unix/Linux.

Does anybody know of a FREE "C++ styler" available on Unix/Linux ?
Please don't answer with "indent".

Marc

Jul 19 '05 #21
Marc Ferry wrote:
In order to avoid these kind of "religious" matters, I was looking for a
tool enabling each developper to have his own style.


Do you mean each developer reformats everything at check-out time?

That will fill the source control system up with irrelevant changes. I have
heard this suggested before; has anyone ever actually done it?

Developers should share a team style, and all code should match it. One can
support the style electronically, but the common style should support team
bonding. Developers can find more productive ways to be individualistic.

--
Phlip
Jul 19 '05 #22
> The shorter the function, the more the relative waste of space the braces
become; so where so you put your braces in your 'very short functions'? How about:


struct
A
{
virtual void fn0() { ... }
virtual void fn1() { ... }
virtual void fn2() { ... }
};

There. A is in the first column. 'struct', being less important, is out of
the first column, and the braces parallel each other.

The functions are so short that the next stiff breeze will make them
collapse into something using even less lines of code.

--
Phlip
http://www.c2.com/cgi/wiki?TestFirstUserInterfaces
Jul 19 '05 #23
Phlip wrote:
Marc Ferry wrote:

In order to avoid these kind of "religious" matters, I was looking for a
tool enabling each developper to have his own style.

Do you mean each developer reformats everything at check-out time?

That will fill the source control system up with irrelevant changes. I have
heard this suggested before; has anyone ever actually done it?


Have a look at "SourceStyler C++" at http://www.sourcestyler.com/
Source file doesn't seem to be reformated.
Marc

Jul 19 '05 #24
Marc Ferry wrote:
Phlip wrote:
Marc Ferry wrote:

In order to avoid these kind of "religious" matters, I was looking for a
tool enabling each developper to have his own style.


Do you mean each developer reformats everything at check-out time?

That will fill the source control system up with irrelevant changes. I
have
heard this suggested before; has anyone ever actually done it?

Have a look at "SourceStyler C++" at http://www.sourcestyler.com/
Source file doesn't seem to be reformated.
Marc


Actually it is reformatted:
http://www.ochresoftware.com/sourcestyler-gui.html

I emailed the link to colleagues and you could tell when
they had opened it by the laughter.

A coding style contains much more than where you place a
brace or how many spaces you indent. It will have rulings on
language constructs to be avoided, naming schemes for
variables, classes, and functions etc, lots of stuff that
reformatting just doesn't address.

If you are going to adopt a coding style you need to pick
one have a meeting to discuss any contentious issues, and
have someone who is in a position to make a final ruling.
Then adopt and enforce the scheme, no one should be exempt
from the adopted style.

Jul 19 '05 #25
lilburne wrote:
Actually it is reformatted:
http://www.ochresoftware.com/sourcestyler-gui.html

I emailed the link to colleagues and you could tell when
they had opened it by the laughter.

A coding style contains much more than where you place a
brace or how many spaces you indent. It will have rulings on
language constructs to be avoided, naming schemes for
variables, classes, and functions etc, lots of stuff that
reformatting just doesn't address.

If you are going to adopt a coding style you need to pick
one have a meeting to discuss any contentious issues, and
have someone who is in a position to make a final ruling.
Then adopt and enforce the scheme, no one should be exempt
from the adopted style.


If you are going to adopt coding styles, start by defining your terms.
There are two kinds - esthetic and technical. The OP asked about an
esthetic guideline.

You list technical things. The two guidelines should be democratic and
meritocratic, respectively. If we declare a technical guideline, and
you find a way to exceed it, you may simply tell us what the actual
technology is. (Tip: Fighting on USENET helps teach us how to defend
our principles ;)

For example, suppose we agree on camelCase for identifiers, and on
"complete words without excess abbreviations". But if you want to
write a big identifier, like camelCaseWithFullPack, you are allowed to
write and defend "camelCase_withFullPack". You added a _ for major
breaks in identifiers, and this has merit.

--
Phlip
Jul 19 '05 #26
Phlip wrote:
lilburne wrote:

If you are going to adopt a coding style you need to pick
one have a meeting to discuss any contentious issues, and
have someone who is in a position to make a final ruling.
Then adopt and enforce the scheme, no one should be exempt
from the adopted style.

If you are going to adopt coding styles, start by defining your terms.
There are two kinds - esthetic and technical. The OP asked about an
esthetic guideline.

The poster to this sub-thread was talking about a standard
layout that wasn't a standard layout, something about not
having a religious war over brace style and such. I've yet
to see an in-house style that didn't combine the aesthetic
and the technical.

But consider for the moment what was being proposed:

"In order to avoid these kind of "religious" matters,
I was looking for a tool enabling each developper to
have his own style."

the idea is that when the file is extracted from the
repository it is formatted into the devvies prefered style,
then when it is returned to the repository it is converted
into house style. This presupposes there is a "house style"
or common layout, but the motivating factor for doing this
is that there isn't "each developer to have his own style".
If this group of developers can agree a common layout format
why can't they adopt it as *the* style?

Now think about what happens when two devvies are working
together, joint debugging, or extreme programming session,
or whatever. Whose layout style are they going to use?

I hope the company that produces this software makes a lot
of money from it, I pray that all my industry competitors
adopt it too.

You list technical things. The two guidelines should be democratic and
meritocratic, respectively. If we declare a technical guideline, and
you find a way to exceed it, you may simply tell us what the actual
technology is. (Tip: Fighting on USENET helps teach us how to defend
our principles ;)

For example, suppose we agree on camelCase for identifiers, and on
"complete words without excess abbreviations". But if you want to
write a big identifier, like camelCaseWithFullPack, you are allowed to
write and defend "camelCase_withFullPack". You added a _ for major
breaks in identifiers, and this has merit.


Of course, the standard will be revised from time to time
and there ought to be a way of managing that. What you don't
want is ad hoc changes or worse yet someone taking the
attitude that they are not bound by it. Practically all of
the in-house style will have some technical basis even the
aesthetic ones.

Jul 19 '05 #27
"Phlip" <ph*******@yahoo.com> wrote in message news:<Ab*****************@newssvr16.news.prodigy.c om>...
Marc Ferry wrote:
In order to avoid these kind of "religious" matters, I was looking for a
tool enabling each developper to have his own style.


Do you mean each developer reformats everything at check-out time?

That will fill the source control system up with irrelevant changes. I have
heard this suggested before; has anyone ever actually done it?

Developers should share a team style, and all code should match it. One can
support the style electronically, but the common style should support team
bonding. Developers can find more productive ways to be individualistic.


I've done that. But I didn't check in that reformatted version.
Instead, I would run vdiff (a function from an old version of PVCS) to
determine what really changed and then make those same changes in a
fresh copy of the code. I'd then vdiff the two modified versions
again to make sure I'd copied in all of my changes before checking the
code back in. That way I could format the code in whatever way best
suited my understanding, and the resulting code didn't overburden the
source control system.
Jul 19 '05 #28
bart wrote:
Why is it that everybody likes the following curly braces syntax

void function(void) {
implementations;
}


Style is a very subjective and personal consideration.
C and C++ programmers develop or adopt a style
in order to make their code easier for themselves
and other programmers to read, understand and maintain.
If you are developing your own style, there are no rules
except that you should try to be consistent.
Otherwise, you should try to adopt a style
with which other C and C++ programmers are comfortable,
familiar or that they will at least recognize.
Personally, I try to use the same punctuation rules
that are used for ordinary (mathematical) typesetting.
Here are my recommendations:

Terminators always follow immediately after an expression

x@ for all @ in {?, :, ,, ;}

and are followed by at least one white space.
Write

x? y: z

instead of

x ? y : z

or

x?y:z

and write

void f(int, int, int); void g(double);

instead of

void f(int,int,int);void g(double);

for example.

There is no space
between some binary operators and their operands

x@y for all @ in {::, ., ->, .*, ->*, *, /, %, &, ^, |}

but there is always a space
between other binary operators and their operands

x @ y for all @ in {+, -, <<, >>;, <, <=, >, >=, ==, !=,
&&, ||, =, *=, /=, %=, +=, -=, <<=, >>=, &=, |=, ^=}

except when expressions appear as subscripts.
Write

x + y

instead of

x+y
and

x*y

instead of

x * y

for example.
But you may wish to write

A[i+1][j-1]

instead of

A[i + 1][j - 1]

for example to subscript array A.
Most unary prefix operators never have any whitespace
between themselves and their operands

@x for all @ in {::, ++, --, ~, !, -, +, &, *}

but others do

@ x for all @ in {sizeof, new, delete, delete [], throw}

No unary postfix operators

x@ for all @ in {[], (), ++, --}

ever have any whitespace between themselves and their operands.

Use the normal typesetting rules for parentheses (),
square brackets [], angle brackets <> and curly brackets {}.
No space after (, [, < or { and no space before ), ], > or }.
Write

(x)

instead of

( x )

or

(x )

or

( x)

and write

[x]

instead of

[ x ]

or

[x ]

or

[ x]

for example.
There are, of course, exceptions
where extra white space helps to make your code more readable:

double A[2][3] = {{ 1, -1, 0},
{-10, 11, -21}};
Don't give identifiers cryptic, mangled names.
Use ordinary, meaningful words, conventional symbols
or abbreviations with annotations.
Write

double distance, velocity, acceleration, mass, Force;

Force = mass*acceleration;

or

double x; // distance
double v; // velocity
double a; // acceleration
double m; // mass
double F; // force

F = m*a;

for example.

Don't rely on defaults. Make declarations explicit.
Write

int i = 1;

instead of

i = 1;

to declare and initialize integer i and write

class X {
private:
// Representation
int I;
public:
// Constructors
// ...
};

instead of

class X {
// Representation
int I;
public:
// Constructors
// ...
};

to define the private data members of class X for example.
Use indentation to emphasize scope.
Everybody is comfortable with standard indentation:

void f()
{
// indent
}

But I indent curly brackets to the scope of the function body:

void f()
{
// indent
}

And I include the open curly bracket with the function heading:

void f() {
// indent
}

to save a line of code.

I always indent just two spaces at a time and
I place just one statement on each line so that
there is usually room for a comment at the end of each line
beginning in column 33 or 41.

Write

if (condition) {
// statements
}

instead of

if(condition) {
// statements
}

and

while (condition) {
// statements
}

instead of

while(condition) {
// statements
}

to distinguish flow control structures from function calls.

I use

// comment

for comments in C++ and I reserve

/*
a = b;
// comment
b = c;
*/

to comment out code which may include comments.
If you find yourself in an environment
that requires you to conform to style rules with which you are not
comfortable,
consider investing a little time and effort in a program like astyle

Artistic Style
http://astyle.sourceforge.net/

which changes the appearance of C or C++ programs
by inserting or deleting whitespace.

Write

constant == variable

instead of

variable == constant

when comparing a variable to a constant for equality
so that if you write

constant = variable

by mistake, the compiler will detect the error.

I always write

x < y

or

x <= y

instead of

y > x

or

y >= x

when comparing two values so that the expression is true
when the left hand side is to the left of the right hand side
on the real number line.

Jul 19 '05 #29
In article <3F**************@jpl.nasa.gov>,
E. Robert Tisdale <E.**************@jpl.nasa.gov> wrote:

Is there a hyphen in anal(-?)retentive?
Jul 19 '05 #30

"Keith A. Lewis" <ka*@panix.com> wrote in message news:bm**********@panix2.panix.com...
In article <3F**************@jpl.nasa.gov>,
E. Robert Tisdale <E.**************@jpl.nasa.gov> wrote:

Is there a hyphen in anal(-?)retentive?


It is when it is used as a adjective prior to a noun. For example:
Robert posts anal-retentive messages
but not when used by itself:
Robert is so anal retentive.
Jul 19 '05 #31
Roxann Higuera wrote:
I've done that. But I didn't check in that reformatted version.
Instead, I would run vdiff (a function from an old version of PVCS) to
determine what really changed and then make those same changes in a
fresh copy of the code. I'd then vdiff the two modified versions
again to make sure I'd copied in all of my changes before checking the
code back in. That way I could format the code in whatever way best
suited my understanding, and the resulting code didn't overburden the
source control system.


There's also the minor issue that the more frequently one integrates,
the lower the cumulative cost & risk of integration. Integrating once
per function is always cheaper than integrating weekly or less often.

--
Phlip
Jul 19 '05 #32

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by Peter Fein | last post: by
9 posts views Thread by Xah Lee | last post: by
1 post views Thread by Stephen | last post: by
18 posts views Thread by Chris Mantoulidis | last post: by
4 posts views Thread by Bob hotmail.com> | last post: by
3 posts views Thread by Magnus.Moraberg | last post: by
21 posts views Thread by REH | last post: by
reply views Thread by jack112 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.