What are your curly-bracing style?
-
Aaahhh, the other developer on earth that uses this horrid style. Our main developer uses this and we never let him forget how unreadable it is.
Joe Woodbury wrote:
Aaahhh, the other developer on earth that uses this horrid style. Our main developer uses this and we never let him forget how unreadable it is.
Please provide the objective method that you use to determine how something is "readable" in a positive or negative way. Also provide the measured impact that it has on productivity. I would also like to see the impact that your complaints about the code has on productivity as well.
-
nikunjbhatt84 wrote:
if(a>b) { // sometimes i write comment here about logic and parameters etc. print "b is less than or equal to a" print "it means a is greater than b" } else print "a is either either equal to or less than b"
That will just get you laughed at and generally ridiculed in our shop...
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997 -
Joe Woodbury wrote:
Aaahhh, the other developer on earth that uses this horrid style. Our main developer uses this and we never let him forget how unreadable it is.
Please provide the objective method that you use to determine how something is "readable" in a positive or negative way. Also provide the measured impact that it has on productivity. I would also like to see the impact that your complaints about the code has on productivity as well.
Please get a sense of humor.
-
My style is:
if (something)
{
DoSomething();
SoSomethingOther();
}
else
{
DoTheOpposite();
}As with every style or methodology I use, I try to have a reason for using it, so that I can justify it (even if only to myself!) and, importantly, change should a better method come along (using reasoning to define 'better') So: By having the 'if' aligned with the start and end brace, when scanning code it is trivial to visually see the structure - scan up from the end brace, you just need to look for another brace. If the start brace is at the end of a line of code, then scanning up from an end brace you need to look for if, while, do etc.etc. I always use braces, even with a single line. If, later on, I come back and need to add more cod to the If or the Else, then I insert it between the braces, and never forget - so I don't re-engineer
if (a==b)
printf("a is equal to b");to
if (a==b)
printf("a is equal to b");
HandleCasesWhereaEqualsb();With the advent of cleverer editors, with automatic indenting, highlighting of code blocks etc., the reasoniong becomes somewhat less important - but you don't get all of that when you open source in or print it (does anyone still print code?) And with the cost of VS2010 in the thousands, I can't guarantee that the editor of my choice will be on every workstation I need to edit on. Some of your reasoning is valid (in my view) but I always think that this obsession some programmers have with the reduction in keystrokes (I'd have to press TAB all the time to indent, I don't want to type two extra braces if I don't need to etc.) is plain silly. Much more time is spent looking at code than writing it - often looking for a problem, more often looking for divine intervention or, at least, inspiration!
___________________________________________ .\\axxx (That's an 'M')
_Maxxx_ wrote:
Some of your reasoning is valid (in my view) but I always think that this obsession some programmers have with the reduction in keystrokes (I'd have to press TAB all the time to indent, I don't want to type two extra braces if I don't need to etc.) is plain silly.
+10000 And yet some of these same programmers will UseCrazyLongMethodNamesLongerThanTheMethod unnecessarily. Something I'd like to see in an IDE is separate view and save format options. Open a file for editing, it reformats to my liking. Hit save and what gets written to disk is formatted to whatever the rest of the team wants to see, or some corporate standard, or whatever. Could make debugging tricky, especially if line numbers change. Or maybe put that functionality into the source management. Repository contains some canonical form of the code (maybe even an XML representation or something else) and when checked out your desired format is applied. Check in would convert back to the canonical form. Almost like using CSS to style HTML.
-
Which method do u use for curly braces to create scope of a programming structure? I mostly prefer this method:
if(a>b)
{ // sometimes i write comment here about logic and parameters etc.
print "b is less than or equal to a"
print "it means a is greater than b"
}
else
print "a is either either equal to or less than b"Note that, I don't use braces for a single line of scope and I indent the starting brace and ending brace and it is not on the same line where the control structure is defined. I use this approach because it makes easy (just hit Enter key, no need to press Tab key) to add a new line of code after the staring brace and before the first statement of the block. I use Notepad++ and it has slightly good matching braces hilting feature and this method helps to correctly lineup and identify scope content. Here are some more methods used my many programmers:
if(a>b) { // this is Flash's ActionScript's default formatting, I hate this style the most, I feel it most unreadable, some Java programmers and web designers working on CSS also use almost similar method for writing CSS rules
print "b is less than or equal to a"
print "it means a is greater than b"
} else {
print "a is either either equal to or less than b"
}if(a>b)
{
print "b is less than or equal to a"
print "it means a is greater than b"
}
else
{
print "a is either either equal to or less than b"
}if(a>b)
{ print "b is less than or equal to a"
print "it means a is greater than b"
}If I'm coding using VS, I use the third style because it's not worth the fight to get a different style. If I'm using notepad, I like the 2nd style. An anal observation. If this statement prints, it prints a falsehood.
nikunjbhatt84 wrote:
print "b is less than or equal to a"
if a == b evaluates to true the above statement won't be printed.
-
Yes, exactly! I still have my circa 1981 copy of K&R! :) /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
Notepad++ has replaced my notepad for all but the simplest views.
SS => Qualified in Submarines "We sleep soundly in our beds because rough men stand ready in the night to visit violence on those who would do us harm". Winston Churchill "Real programmers can write FORTRAN in any language". Unknown
I've tried it, in fact I have home computer set to run that when I type notepad at the command line, but I don't like it very much. At work we have TextPad, but I stick to what I know -- warts and all.
-
I also put each brace on its own line (although I will also put comments on that line), aligned with the statement begining the block, and indenting lines within that block. Likewise, I DO brace single line statements. Why? Because it makes adding console output debugging statements (like TRACE()) to the code far less perilous. I absoulutely hate the java convention of the first brace at the end of the invoking statement's line, but the end brace on its own line. If only C++ hadn't insisted on being a superset of C, much good would have been accomplished. Maybe it could ditch across-the-board C compatibility when the NEXT standard is released, and do things like REQUIRE braces around single line blocks. Maybe then we could answer the question once and for all whether
int* pInt;
long& rLong;or
int *pInt;
long &rLong;, or even
int * pInt;
long & rLong;should be the one and only correct way to decalre a pointer or reference.
Hear! Hear! When I get my time machine working I'm going back to have a word with Dennis Ritchie. :-D
-
For me, this is the easiest way to determine functional blocks. But, for the example of if..else, I seem to vacillate on the else part. Lately I have been using this style -
if (a > b)
{
print "b is less than or equal to a";
print "it means a is greater than b";
}
else
{
print "a is greater than b";
}But, sometimes, I find myself typing this -
if (a > b)
{
print "b is less than or equal to a";
print "it means a is greater than b";
} else {
print "a is greater than b";
}No idea why.
In the former, you can
#ifout theelseon its own (without the braces). -
Maybe, but IIRC K&R wrote their manuscript using this style originally:
if (something)
{
do stuff
do more stuff
}
else
{
do something different
}It was changed at the publishers request to save on printing costs.
3x12=36 2x12=24 1x12=12 0x12=18
That's what I've heard too, but Ritchie's 1974 document has it the "K&R" way:
struct tnode {
char tword[20];
int count;
struct tnode *left;
struct tnode *right;
};(Six SPACES!) And Thompson's B document has:
switch(x) {
case ’a’:
y = 1 ;
case ’b’:
z = 2;
}X| (Three SPACES!) It appears that BCPL has neither braces nor semi-colons.
-
_Maxxx_ wrote:
Some of your reasoning is valid (in my view) but I always think that this obsession some programmers have with the reduction in keystrokes (I'd have to press TAB all the time to indent, I don't want to type two extra braces if I don't need to etc.) is plain silly.
+10000 And yet some of these same programmers will UseCrazyLongMethodNamesLongerThanTheMethod unnecessarily. Something I'd like to see in an IDE is separate view and save format options. Open a file for editing, it reformats to my liking. Hit save and what gets written to disk is formatted to whatever the rest of the team wants to see, or some corporate standard, or whatever. Could make debugging tricky, especially if line numbers change. Or maybe put that functionality into the source management. Repository contains some canonical form of the code (maybe even an XML representation or something else) and when checked out your desired format is applied. Check in would convert back to the canonical form. Almost like using CSS to style HTML.
ZanyZapper wrote:
put that functionality into the source management.
Yes, the code should be formatted to the company standard before determining whether or not there are any changes.
-
I hope I never have to maintain any code you've written. This:
nikunjbhatt84 wrote:
if(a>b)
is just wrong. Use some whitespace!
if (a > b)
{
}Pete
Indeed, the only place I've worked that had (has?) a standard, specified single spaces around all operators (or maybe even tokens).
-
I vote for getting rid of braces and using indentation exclusively. Using braces the way many people do causes too many wasted lines (empty of anything useful).
SS => Qualified in Submarines "We sleep soundly in our beds because rough men stand ready in the night to visit violence on those who would do us harm". Winston Churchill "Real programmers can write FORTRAN in any language". Unknown
Jim (SS) wrote:
(empty of anything useful).
They contain elbow room; we all need a little elbow room...
-
Which method do u use for curly braces to create scope of a programming structure? I mostly prefer this method:
if(a>b)
{ // sometimes i write comment here about logic and parameters etc.
print "b is less than or equal to a"
print "it means a is greater than b"
}
else
print "a is either either equal to or less than b"Note that, I don't use braces for a single line of scope and I indent the starting brace and ending brace and it is not on the same line where the control structure is defined. I use this approach because it makes easy (just hit Enter key, no need to press Tab key) to add a new line of code after the staring brace and before the first statement of the block. I use Notepad++ and it has slightly good matching braces hilting feature and this method helps to correctly lineup and identify scope content. Here are some more methods used my many programmers:
if(a>b) { // this is Flash's ActionScript's default formatting, I hate this style the most, I feel it most unreadable, some Java programmers and web designers working on CSS also use almost similar method for writing CSS rules
print "b is less than or equal to a"
print "it means a is greater than b"
} else {
print "a is either either equal to or less than b"
}if(a>b)
{
print "b is less than or equal to a"
print "it means a is greater than b"
}
else
{
print "a is either either equal to or less than b"
}if(a>b)
{ print "b is less than or equal to a"
print "it means a is greater than b"
} -
Joe Woodbury wrote:
Aaahhh, the other developer on earth that uses this horrid style. Our main developer uses this and we never let him forget how unreadable it is.
Please provide the objective method that you use to determine how something is "readable" in a positive or negative way. Also provide the measured impact that it has on productivity. I would also like to see the impact that your complaints about the code has on productivity as well.
There is no 'objective' method for determining readability, since readability is inherently subjective. You could do a survey of 100 programmers to judge the readability of a body of code, and all you have at the end is a statistical result, averaging their opinions. I don't find one brace style particularly more readable than another. Consistency of style drives readability more than anything else for me.
Software Zen:
delete this;
Fold With Us![^] -
The proper way.
if (something){ do stuff do more stuff } else{ do something different }Am I showing my age if I mention Kernighan and Ritchie? :)
My older stuff uses K&R, since that's what I started it in. Nowadays I tend to do this:
if (a < b)
{
DoStuff();
}
else
{
DoOtherStuff();
}I need the added white space due to my weak, middle-aged vision :-O .
Software Zen:
delete this;
Fold With Us![^] -
That's what I've heard too, but Ritchie's 1974 document has it the "K&R" way:
struct tnode {
char tword[20];
int count;
struct tnode *left;
struct tnode *right;
};(Six SPACES!) And Thompson's B document has:
switch(x) {
case ’a’:
y = 1 ;
case ’b’:
z = 2;
}X| (Three SPACES!) It appears that BCPL has neither braces nor semi-colons.
PIEBALDconsult wrote:
That's what I've heard too, but Ritchie's 1974 document has it the "K&R" way:
Might be an urban legend. I oculdn't find anything authoritative when I googled.
PIEBALDconsult wrote:
It appears that BCPL has neither braces nor semi-colons.
The wikipedia article[^] lists it a the 1st curly brace language and includes a few examples which use them. The intending is even nastier than your B example and looks like someone gorged on a mix of basic, pascal, and C and vomited it all up again. X|
GET "libhdr"
GLOBAL { count:200; all:201 }
LET try(ld, row, rd) BE TEST row=all
THEN count := count + 1 ELSE { LET poss = all & ~(ld | row | rd) UNTIL poss=0 DO { LET p = poss & -poss poss := poss - p try(ld+p << 1, row+p, rd+p >> 1) } }LET start() = VALOF
{ all := 1FOR i = 1 TO 12 DO
{ count := 0
try(0, 0, 0)
writef("Number of solutions to %i2-queens is %i5*n", i, count)
all := 2*all + 1
}RESULTIS 0
}3x12=36 2x12=24 1x12=12 0x12=18
-
In the former, you can
#ifout theelseon its own (without the braces).True enough. But I prefer to put braces around every statement block, even if it is just one line. e.g.
if (a == 0)
{
x += 1;
}This keeps me from doing this -
if (a == 0)
x += 1;
return 1;when I mean -
if (a == 0)
{
x += 1;
return 1;
}if changes need to be made.
-
Places where I work have more important things to do that make observations on style structures that have nothing at all do to with functionality nor productivity.
Are you saying that the places you work have no concern for coding standards and code maintainability? At least that's what it sounds like you're saying. If so, I wouldn't want to work there. I've had me share of dealing with 20 different code formatting styles.
-
I also put each brace on its own line (although I will also put comments on that line), aligned with the statement begining the block, and indenting lines within that block. Likewise, I DO brace single line statements. Why? Because it makes adding console output debugging statements (like TRACE()) to the code far less perilous. I absoulutely hate the java convention of the first brace at the end of the invoking statement's line, but the end brace on its own line. If only C++ hadn't insisted on being a superset of C, much good would have been accomplished. Maybe it could ditch across-the-board C compatibility when the NEXT standard is released, and do things like REQUIRE braces around single line blocks. Maybe then we could answer the question once and for all whether
int* pInt;
long& rLong;or
int *pInt;
long &rLong;, or even
int * pInt;
long & rLong;should be the one and only correct way to decalre a pointer or reference.
Michael Waters wrote:
I absoulutely hate the java convention of the first brace at the end of the invoking statement's line, but the end brace on its own line.
It's not a Java convention it is a K&R (Kernigan and Ritchie) convention for C that many Java shops that just follow trends rather than thinking for themselves have inheritted. It has a highly arrogant and presumptuative name: TOOTBS (The One and Only True Brace Style). Personally, I think it should be called Really Unimaginably Bad Brace Indenting Style Hack (or RUBBISH for short - I need a better 'H' [suggestions?]). I am in the process of reading the C# book in the O'Reilly series and I am pleased to report that its authors use open braces aligned with close braces even with Visual Studio. Perhaps we ought to be equally as arrogant as K&R and call aligned braces TOOLBS (The One and Only Logical Brace Style) or TOOSBS (The One and Only Sensible Brace Style). :~