Brace style
-
Bet you didn't know that! 20+ years ago I read an interview with the two and this topic was broached. They both said they were stunned at the attitude of "...if it's good enough for K & R, it's good enough for me" and the thought by some that copying the K & R style of braces made them a good programmer. Of course we are talking about their infamous book, "The C Programming Language." What they also divuldged was that it was not their brace style at all! Their explanation: The publisher discovered that they could save a whole line of space in the book by moving the opening brace to the end of the previous line and the program would still work. They also remarked, and I'm paraphrasing here, "Thank God the publisher didn't know you could write the whole program on one line!" Now you know the rest of the story... Page 2... :-D The last edition of "The C Programming Language" was updated for ANSI C in 1988. It is still in print! :omg:
Is the interview up on the web anywhere?
-- You have to explain to them [VB coders] what you mean by "typed". their first response is likely to be something like, "Of course my code is typed. Do you think i magically project it onto the screen with the power of my mind?" --- John Simmons / outlaw programmer
-
Pete O`Hanlon wrote:
Who cares?
I care, the first leads to unreadable code and working for many software houses, the first think you learn are the programming standard for that company and at a time top of the list if braces style. You'd get hanged if you coded the brace
if(blah de blah){ }If so freakin unreadble!.net is a box of never ending treasures, every day I get find another gem.
Read the entire post and then comment on it. The key bits are: 1. Does the code work? 2. Does it follow coding guidelines? If you have guidelines that state how it should look then you follow them - regardless as to how distasteful you find them. I have my preferences for bracing style, but that doesn't mean that my opinion carries any more weight than somebody else who likes a different style.
norm .net wrote:
the first think you learn are the programming standard for that company and at a time top of the list if braces style. You'd get hanged if you coded the brace if(blah de blah){ } If so freakin unreadble!
Now extend that to include all the companies where you'd get hanged for using
if(...) { }. I've been in this game so many years and I've been forced to use both styles by so many clients that I don't think it's worth getting worked up about. There are arguments on both sides, so don't get worked up about it. BTW - you haven't come down with a position on the use of braces for single line statements.
if(...) { DoThis(); }versus
if(...) DoThis();Deja View - the feeling that you've seen this post before.
-
John R. Shaw wrote:
simple logic and experience will eventually show you what the problem is
I can over-complicate things for anyone. Sadly, simple logic really is not one of my strong points. :( However, I'd be delighted to benefit from experience, and I don't doubt that yours is more extansive than mine. Please, do enlighten me. I would like to learn.
If you keep the lines short then the former works just fine (experience), but the longer the lines get the more likely it is that you will fail to notice the opening brace. Modern environments allow you to place the cursor at a brace and use a key combination to find the other one, but you should not need to do that. If you failed to place the brace after the test statement then you may be confused as to why the compiler generated and error until you search for the missing brace, provided you realize that is the problem. Indention tells you it is supposed to be a block but the compiler does not recognize your intensions, only the facts. When you look at a test statement with an opening brace following it on the next line, you know that it is being blocked out. Of course symmetry also helps when reading the code. I resonantly spent a lot of time programming in ‘.Net’ and the default code generation produced very long lines and it is even hard to stay away from them in standard C++. Which means that unless you start wrapping your test statements to the next line (which I do and hate doing), then the opening brace may not be visible (if you use the former style). If you look at it from a strictly indention point of view then the brace would be in the wrong place because it would be inconsistent with the rest of the code. What all that bull amounts to is that the latter makes it easier to read and debug the code, and I have done enough of both to drive myself a little crazy.
INTP "Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
-
That reminds me, how the hell do I make VS 2005 go to the next freaking line when I press Enter after typing 'try'? This is one of the most intrusive behaviours in this IDE.
-
Read the entire post and then comment on it. The key bits are: 1. Does the code work? 2. Does it follow coding guidelines? If you have guidelines that state how it should look then you follow them - regardless as to how distasteful you find them. I have my preferences for bracing style, but that doesn't mean that my opinion carries any more weight than somebody else who likes a different style.
norm .net wrote:
the first think you learn are the programming standard for that company and at a time top of the list if braces style. You'd get hanged if you coded the brace if(blah de blah){ } If so freakin unreadble!
Now extend that to include all the companies where you'd get hanged for using
if(...) { }. I've been in this game so many years and I've been forced to use both styles by so many clients that I don't think it's worth getting worked up about. There are arguments on both sides, so don't get worked up about it. BTW - you haven't come down with a position on the use of braces for single line statements.
if(...) { DoThis(); }versus
if(...) DoThis();Deja View - the feeling that you've seen this post before.
Pete O`Hanlon wrote:
I've been in this game so many years and I've been forced to use both styles by so many clients that I don't think it's worth getting worked up about
Not worked up about. I suppose when contracting any old style will do (from experience working as a contractor with other contractors you couldn't give a sh@t as long as the code worked), but when working for software houses or development teams standard is a must and postion I've been in has always opted for brace per newline. And for single line coding I'd vote for
if (...) Func();But at the end it's entirely up to you come which style you'd use..net is a box of never ending treasures, every day I get find another gem.
-
Pete O`Hanlon wrote:
I've been in this game so many years and I've been forced to use both styles by so many clients that I don't think it's worth getting worked up about
Not worked up about. I suppose when contracting any old style will do (from experience working as a contractor with other contractors you couldn't give a sh@t as long as the code worked), but when working for software houses or development teams standard is a must and postion I've been in has always opted for brace per newline. And for single line coding I'd vote for
if (...) Func();But at the end it's entirely up to you come which style you'd use..net is a box of never ending treasures, every day I get find another gem.
norm .net wrote:
Not worked up about. I suppose when contracting any old style will do (from experience working as a contractor with other contractors you couldn't give a sh@t as long as the code worked), but when working for software houses or development teams standard is a must and postion I've been in has always opted for brace per newline.
Errm - reread what I said. Any contractor should care about the standards they follow. Where there is an in-house standard, this MUST be followed. I've stated that twice now. What doesn't matter is what the standard is - use it and concentrate on your logic.
Deja View - the feeling that you've seen this post before.
-
Pete O'Hanlon wrote:
Does this actually improve the quality of your code in any way?
No, but religious wars are fun.:) Pointless, but fun.
Kevin
-
norm .net wrote:
Not worked up about. I suppose when contracting any old style will do (from experience working as a contractor with other contractors you couldn't give a sh@t as long as the code worked), but when working for software houses or development teams standard is a must and postion I've been in has always opted for brace per newline.
Errm - reread what I said. Any contractor should care about the standards they follow. Where there is an in-house standard, this MUST be followed. I've stated that twice now. What doesn't matter is what the standard is - use it and concentrate on your logic.
Deja View - the feeling that you've seen this post before.
Pete O`Hanlon wrote:
Any contractor should care about the standards they follow
They sure should, but in reality don't;P. Yes I agree with you on following the in-house standard, it's a no-brainer we don't wont varying version of the brace, do we now?:rose:
.net is a box of never ending treasures, every day I get find another gem.
-
Pete O`Hanlon wrote:
Any contractor should care about the standards they follow
They sure should, but in reality don't;P. Yes I agree with you on following the in-house standard, it's a no-brainer we don't wont varying version of the brace, do we now?:rose:
.net is a box of never ending treasures, every day I get find another gem.
You said it about a lot of contractors there - no-brainer.:laugh: Mind you, I must admit that I cheat - I let the IDE take care of it for me. BTW - my personal preference is braces on a new line.
Deja View - the feeling that you've seen this post before.
-
John R. Shaw wrote:
I automatically use what ever style is currently used
Dexterity... :laugh: Frankly though, as long as tabbing is consistent (preferably spaces though), either style should provide a relatively clear indication of where the blocks are.
Lots of practice! :laugh: It depends on how long the lines are. I posted an apology a couple of years ago to anyone who may have had to modify the code I created when I was writing in the first style. I thought being able to see a few more lines made since, but experience show me otherwise.
INTP "Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
-
Kevin McFarlane wrote:
don't think it's unreadable. But it's less readable
Ok I over-exaggerated somewhat, but brace per newline line seems to be the standard in every company I have worked.
.net is a box of never ending treasures, every day I get find another gem.
In most companies I've worked there isn't a standard, although (in the MS-centric dev world at least) a brace per newline is the most common. It was also the first style I ever saw, probably from seeing Turbo C++ and VC++ 1.0 code when learning.
Kevin
-
Which one you prefer ?
if{
//do something
}Or
if
{
//do something
}
printf("Navaneeth!!") www.w3hearts.com
I prefer the latter style as well. For those using VS2k5, there is a very simple way to convert source code to your chosen form: Ctrl-A, Ctrl-E, Ctrl-F will reformat the entire file based on your formatting settings for the current language. One idea would be to add a check-in trigger to your revision control system that reformatted each file to the corporate standard. Developers could use any formatting style that they were comfortable with because what is in revision control would be 100% consistent.
-- Paul
-
Niall Joubert wrote:
As long as there are braces, there will be debate, some fierce...
True. ;) I can switch between both at will and once thought the former was a good idea. I have since learned the errors of my ways, because the former makes it more difficult to see where the block begins or if there is even a block to begin with. Regardless of the project, I automatically use what ever style is currently used if I am modifying or adding to someone else’s code.
INTP "Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
John R. Shaw wrote:
Regardless of the project, I automatically use what ever style is currently used if I am modifying or adding to someone else’s code.
Same here. Although if the style is especially bad, as was the case recently in some JavaScript I was maintaining, I ignore the existing style.
Kevin
-
This is interesting, I myself used the latter, but in the programming course Ive done they teach using the former, although Ive gotten used to programming like that i still dont like it and prefer having the extra line breaks
-
John R. Shaw wrote:
Simple the second choice, because it makes more since and is easier to read. I used the first one for a few years and eventually found it very annoying when reading the code, because it is too easy to miss where the block starts.
I fully agree.
John R. Shaw wrote:
he third option would be to indent the braces, but that has never made since to me.
Same here.
John R. Shaw wrote:
Of course writing ‘if ()’ as opposed to ‘if()’ still does not make since to me
It makes perfect sense to me. I hate not having the space after the keyword. However, it's not a big deal. It's less of a deal than bracket placement and that's not much of a deal.
John R. Shaw wrote:
And I would like to know which idiot started the trend of writing ‘i++’ instead of ‘++i’, because that is not a matter of formatting but is a matter of understanding the language.
Most of the time it makes no difference and on most of the occasions when it does we shouldn't be writing code that way anyway. I've got used to writing i++ and it just looks nicer to me. However, I'm clued up enough to use ++it for STL iterators. But I haven't done any C++ for over 2 years.
Kevin
The space is not big deal, but I like consistency and placing that space suggests to me that a space should be place before every ‘(‘ character. When I started programming (in C) using ‘++i’ as apposed to ‘i++’ was a very minor optimization, as the compilers did not do the optimization for you. In C it was not really that important, even when the machines where slow, but is C++ it can make a big difference. As you noted “Most of the time it makes no difference”, but if you make it a habit and teach others to do the same thing, which most books do now, then they are learning the wrong thing. Even Bjarne Stroustrup uses ‘++i’ instead of ‘i++’ although I have never read a statement by him as to why he does that. But other experts on the language have explained it in detail.
INTP "Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
-
pascal poisoning. Indenting
Begin Endpairs actually did make some degree of sense IMO. People who do the same in C style languages are as bad as those usinglpszFoostyle naming in VB.-- You have to explain to them [VB coders] what you mean by "typed". their first response is likely to be something like, "Of course my code is typed. Do you think i magically project it onto the screen with the power of my mind?" --- John Simmons / outlaw programmer
Ouch! Don’t make me laugh like that, I pulled a muscle in my back yesterday and that hurt. :laugh:
INTP "Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
-
The space is not big deal, but I like consistency and placing that space suggests to me that a space should be place before every ‘(‘ character. When I started programming (in C) using ‘++i’ as apposed to ‘i++’ was a very minor optimization, as the compilers did not do the optimization for you. In C it was not really that important, even when the machines where slow, but is C++ it can make a big difference. As you noted “Most of the time it makes no difference”, but if you make it a habit and teach others to do the same thing, which most books do now, then they are learning the wrong thing. Even Bjarne Stroustrup uses ‘++i’ instead of ‘i++’ although I have never read a statement by him as to why he does that. But other experts on the language have explained it in detail.
INTP "Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
John R. Shaw wrote:
that space suggests to me that a space should be place before every ‘(‘ character.
Well, I'd like to do that as well but it's too irregular in the C-family languages. Eiffel uses this style and it looks very nice. I would follow it if I was using Eiffel. It looks odd when there are no function arguments. But in Eiffel you don't have () so in their context it looks neat. Still, we more-or-less see eye to eye. :)
Kevin
-
I have never written anything significant in Perl.
-
Which one you prefer ?
if{
//do something
}Or
if
{
//do something
}
printf("Navaneeth!!") www.w3hearts.com
I much prefer the latter, code is easier to follow... Now a follow-up question for those that prefer the latter style: Which do you use/prefer when there is only one executable statement after an 'if' or 'else'? Style 1-
if (this)
doThis();
else
doThat();OR Style 2-
if (this)
{
doThis();
}
else
{
doThat();
}Me? I use Style 2. Yes it takes up more space, but I think it is more readable and is less prone to error if later adding another statement to the if or else section(s). (I just noticed that this question was discussed a bit earlier in the thread... sorry for the repeat) -- modified at 9:53 Thursday 17th May, 2007
-
Which one you prefer ?
if{
//do something
}Or
if
{
//do something
}
printf("Navaneeth!!") www.w3hearts.com
In college (late 80s), I was all about lined up braces (choice 2). However, once I stopped hacking so much, and instead started writing better planned-out code, readability of individual code statements became less important to me than readability of class-level design (function prototypes, member variables). Thus, I developed a consistent style of cramming code together. No empty lines unless it's temporary (fill in the blank later type of thing), and no newlines for braces unless there are two or more statements. Here is an extreme example of a one-function class. Assume that the set is one statement and the get is one statement (if more than one, I split it out like choice 1 in the original posting). namespace abc { class xyz { public string ToolTip { set { do; } get { return something; } } } } Basically, once I write it, I don't want to have to look at the implementation of it again. Sometimes during development of longer functions, I'll spread it out. Then, when it's all correct and tested, I shrink it down according to the one-statement rules. I'm always consistent with the {} usage. Of course, I couldn't pull off this crammed style in a typical team environment because people wouldn't trust each other to get it right the first time. If you did trust each other, it could work in that environment. Dale P.S. For the last two years, I wrote VB.Net code and got totally used to spread-out code. Experienced programmers can get used to any consistent style, I think. Newer programmers are typically more insistent on their own unique style. -- modified at 9:46 Thursday 17th May, 2007