What are your curly-bracing style?
-
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
Peter Mulholland wrote:
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) { }
I use whitespace only when if I think the code would look complex without whitespace.
-
This doesn't relate to the curly braces, but your logic is incorrect. If a>b, b cannot be equal to a. Thus, "b is less than or equal to a" does not mean the same thing as "a is greater than b".
peterofthecorn wrote:
This doesn't relate to the curly braces, but your logic is incorrect. If a>b, b cannot be equal to a. Thus, "b is less than or equal to a" does not mean the same thing as "a is greater than b".
ya, u have spotted the wrong thing rightly. i just want to put something funny/rubbish, so in hurry, i have written what u have spotted. good observation!!
-
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"
}Thank you all for wasting some of your time here ;) However this was just a time-pass post from me, I got many responses and many of them very logical and informative. Many have talked about being consistent and getting used to any style if we are working on code which is coded by someone else. These are really nice approaches. As I am a teacher, I tell my students to better indent the code in whatever style and staying consistent with it. Sometimes its very hard to spot even a small silly mistake done by them if they have not formatted the code in any consistent way. BTW, some have spotted logic error in my sample code. Thumbs UP to them :thumbsup:.
-
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.
Joe Klemmer wrote:
Are you saying that the places you work have no concern for coding standards and code maintainability
The first in terms of this discussion has no provable impact on the second.
Joe Klemmer wrote:
I've had me share of dealing with 20 different code formatting styles.
I had my share of dealing with C++ programmers that do not deal with pointers consistently or use them incorrectly. I had my share of dealing with programmers in C++, C# and Java who do not deal with error scenarios at all. Or who deal with them incorrectly. I had my share of dealing with programmers that do not understand specifications, literally cannot follow specifications, ignore specifications, do not know specifications exist or assume that specifications are 100% correct. I had my share of dealing with programmers that think inheritance is used to provide code sharing. etc, etc, etc... All of those have had a measurable and significant impact on quality, performance and maintainability. Conversely I have never, not a single time, had a single situation where bracket placement had any impact on any project. And thus it follows that it never had a measurable or significant impact. I have however also seen programmers that think that code standards have some impact on code quality and yet are quite willing to ignore or even disparage process control techniques which have a proven impact.
-
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
Dan Neely wrote:
Might be an urban legend. I oculdn't find anything authoritative when I googled.
True. I spent some time one time trying to validate it but couldn't find anything. I thought that I read a micro interview in the magazine "C++ Reports" (believe that was the name) years ago that said that.
-
Please get a sense of humor.
Joe Woodbury wrote:
Please get a sense of humor.
I do laugh when I see people make statements that suggest that minor style elements have any measurable impact in software development. I don't laugh so much when some of those same people dismiss process control idioms that have a proven measurable and significant impact and instead think that a coding guideline by itself is going to having any positive impact on the code. I have attempted to find supporting evidence that suggests anything about style elements and have never found one (excluding one that showed that in written material using excessive fonts will have a negative impact.) Conversely there are probably hundreds if not thousands of studies about different process control practices with produced measured benefits.
-
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![^]Gary R. Wheeler wrote:
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 am fairly certain that one would find that say at least 90%+ of programmers would prefer code that has some white space in it to code that has none. And quite a few wouldn't care for code that has a large amount either. I am also fairly certain that probably something like 99%+ of people would find that something like user manual that uses a 3 point font would not be acceptable. It is certainly possible that a study that was used to test that might use the term 'readable' in qualifying preferences. I do not think that anyone has tried to measure that however.
-
Gary R. Wheeler wrote:
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 am fairly certain that one would find that say at least 90%+ of programmers would prefer code that has some white space in it to code that has none. And quite a few wouldn't care for code that has a large amount either. I am also fairly certain that probably something like 99%+ of people would find that something like user manual that uses a 3 point font would not be acceptable. It is certainly possible that a study that was used to test that might use the term 'readable' in qualifying preferences. I do not think that anyone has tried to measure that however.
My point was that brace style in and of itself is not a primary factor in readability for most programmers. Other factors like number of lines per function, indentation, and naming conventions are bigger considerations. I've read code written with K&R braces and no white space that was eminently readable. I've also read code with braces on new lines by themselves that I couldn't follow at all.
Software Zen:
delete this;
Fold With Us![^] -
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
Regarding BCPL; I didn't read the document I have (Richards 1967) too closely, but it seems to be even worse -- it's not necessarily braces; his examples generally use
$(and$)instead and the rule seems to be "anything that matches". Plus a "closing section bracket" can close multiple sections... a la LISP. X| As to semi-colons, they are mentioned and defined, but don't seem to be demonstrated in the examples. Certainly they are not used as they are in C. -
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.
Yes, as do I, but they each have their own line (unless they're on the same line) --
{}. -
My point was that brace style in and of itself is not a primary factor in readability for most programmers. Other factors like number of lines per function, indentation, and naming conventions are bigger considerations. I've read code written with K&R braces and no white space that was eminently readable. I've also read code with braces on new lines by themselves that I couldn't follow at all.
Software Zen:
delete this;
Fold With Us![^]Gary R. Wheeler wrote:
My point was that brace style in and of itself is not a primary factor in readability for most programmers. Other factors like number of lines per function, indentation, and naming conventions are bigger considerations.
I suggest you re-read the sub-thread since what I responded to was the specific point that brace placement itself caused the code to be unreadable.
-
Regarding BCPL; I didn't read the document I have (Richards 1967) too closely, but it seems to be even worse -- it's not necessarily braces; his examples generally use
$(and$)instead and the rule seems to be "anything that matches". Plus a "closing section bracket" can close multiple sections... a la LISP. X| As to semi-colons, they are mentioned and defined, but don't seem to be demonstrated in the examples. Certainly they are not used as they are in C.PIEBALDconsult wrote:
Regarding BCPL; I didn't read the document I have (Richards 1967) too closely, but it seems to be even worse -- it's not necessarily braces; his examples generally use $( and $) instead and the rule seems to be "anything that matches". Plus a "closing section bracket" can close multiple sections... a la LISP.
:((
3x12=36 2x12=24 1x12=12 0x12=18