Brace style
-
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
-
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.
oh yes we have,......see above
Grady Booch: I told Google to their face...what you need is some serious adult supervision. (2007 Turing lecture) http://www.frankkerrigan.com/[^]
-
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
-
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
I agree with this. if (...) { DoThis(); } ...is just so much more readable when I've got a fairly long and complicated function. I also really despise this: if (...) { DoThis(); } else if { DoThat(); } else { DoThose(); } Extend the DoThis(), DoThat(), and DoThose() to something long, and you'll be going "huh? where the hell are my opening and closing braces?"
-
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
Some years ago I had an application switch over to me so I could fix all the (major) problems with it. By the time I was through all the problems where fixed and all the files where reformatted to my liking. I was still maintaining that code and adding to it till the day I walked out, and it has not been changed since.
INTP "Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
-
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
Navaneeth.Which one you prefer ? if{//do something} Or if{//do something}
Actually, I prefer: if (condition == true) { // do something }
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated.
-
Some years ago I had an application switch over to me so I could fix all the (major) problems with it. By the time I was through all the problems where fixed and all the files where reformatted to my liking. I was still maintaining that code and adding to it till the day I walked out, and it has not been changed since.
INTP "Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
if you left how do you know the code never was changed since then?
-- 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
-
The latter. The former is used only by miscreants and rogues. :suss:
----
i hope you are feeling sleepy for people not calling you by the same.
--BarnaKol on abusive words
Personally, I think it's a question of who really cares as long as you can read the thing and it kinda depends on what language I'm working with. For C# I pretty much go with the second example but as a complete heretic who occasionally finds himself coding Perl in a hurry, I've been known to chuck both examples and go with the following blasphemy:
do something if true;Or even (gasp!):do something unless true;Both of which eliminate the braces altogether... :-D