|
I never liked the 'Braces starting on control line' because i always have a hard time finding or spotting the brace on the first look.
Some people also write code that is so hard to read because it is all compacted on few lines. I dont think that the speed at which code is written should have precedence on the clearness and effectiveness of code.
I think a nice and simple rule is to write code keeping in mind that other people may use it or need to work on it. Especially in a team of programmers, would you accept different styles ? I dont, as long as the difference is not confusing to others and to me. As for braces, I've always prefered the 'Braces starting on line under control line, non-indented' format, and i can see i am not alone. That is also the programming style i learned back then (1986 or so). It clearly shows the starting of new block for the controlling command. No confusion and clear code.
So in conclusion, keep in clear and clean.
Happy coding to all 
Louis.
|
|
|
|
|
Everyone knows that code which takes less space excecutes faster. Try to minimize the length of variable names, avoid multiline comments, and never let a brace have its own line...
|
|
|
|
|
Really ?
Writting code in C/C++ that takes less space executes faster ?
I dont believe so, where did you read that ? 
|
|
|
|
|
of course... and use assembler whenever possible!
You're a funny guy
|
|
|
|
|
Well, i think you have to go back and check your books.
Writting:
if( a == 2 )
{
c = b + a;
}
else
{
c = b;
}
will produce the same code as:
if(a==2) c=b+a; else c=b;
Just check the assembler output from the compiler.
And you say:
'Try to minimize the length of variable names, avoid multiline comments'
Holy!! this has absolutely no incidence on execution speed. Comments are just in your souce file andd produce no machine code whatsoever. Variable length...dah.
If you learned this from your tutor, then i am very sorry, but you have been missled badly  If not, I to have to say that you are a funny guy
BTW, are you to shy of your response to put your name with it ?
cheers.
Louis.
|
|
|
|
|
> Everyone knows that code which takes less space excecutes faster.
> Try to minimize the length of variable names, avoid multiline
> comments, and never let a brace have its own line...
It figures that some of the people that responded to your post so far have missed the " " at the end of it. There seems to be a lot of that going on around here...
Anyway... I remember a "developer" who insisted on single and double character variable and function names. His idea was that a good developer would do this, in order to optimize compilation times.
But it never occurred to him that a "good" developer would not have to worry about that, because a good developer would not have to compile so often (read: would not use the compiler to find stupid errors, or to fix previous bugs).
Peace!
-=- James.
|
|
|
|
|
With all due respect to K&R, I also think that Option 2 is the best. But the reason for its popularity is not primarily visual. It is conceptual. Option 2 most clearly helps differentiate a block of code from a control statement. The style puts on screen how a programmer thought.
As to the Option1 (K&R). It is best regarded as historic. Nowadays all developers have hundreds megs of RAM (if not in early gigs), 17+" screens (more like 20+") , 768+ vert res (more like 1K+). We no longer are restricted to 23 vertical lines (more like 20 after discounting menu/status/help/command lines). So, we can certainly afford an extra line for clarity. Remember, our projects too are no longer 5000 LOC in totality. They are more likely to have at least 25,000 lines written by the team, integrated with at least 100,000 lines of library code. Simple stylistic measures such as clearly distinguished blocks of code help more in bigger projects.
That said, I realize that people can form habits. Many programmers from the early C generation can easily spot blocks of code in Option1 (K&R) style. Yes, even nested ones. And I know they are honest. Of course, these same people can also spot blocks in Option2 just as easily. But the other way is not true. I mean, people habituated to Option2 (e.g. me) find it very tough to spot nested blocks if written in Option1. So, all in all, for team rules, Option2 turns out better.
|
|
|
|
|
Even though I agree with most of you, for historic reason, there is one valid argument for the first choice.
think of the following code
if( something );
{
dosomething;
}
if( something ) {;
dosomething;
}
Now, most of the compilers catch the bug in the first code, but long time ago, it was a real hard bug to find. imgine debugging someone's mess like that?
|
|
|
|
|
Even though I agree with most of you, for historic reason, there is one valid argument for the first choice.
think of the following code
if( something );
{
dosomething;
}
if( something ) {;
dosomething;
}
Now, most of the compilers catch the bug in the first code, but long time ago, it was a real hard bug to find. imgine debugging someone's mess like that?
|
|
|
|
|
Just wanna share how I write "if-else, while, for, switch" blocks.
if (bSomeBool)
{
SomeFunction();
}
else
{
SomeOtherFunction();
}
while (bSomeBool)
{
}
do
{
DoSomeStuff();
}
while (bSomeBool);
for (int i=0; i < 10; i++)
{
ForSomeStuff();
}
switch (iSomeVal)
{
case 0:
Case0();
break;
case 1:
Case1();
break;
default:
CaseDefault();
break;
}
|
|
|
|
|
Follows more or less my way of working. It looks, however, a little bit strange that you suddenly don't indent the cases in the switch statement. That's what I do too. So, my switch statement would look like:
switch ( iSomeVal )
{
case x:
DoSomething();
break;
case y:
DoSomethingElse();
break;
default:
ASSERT( FALSE );
break;
}
Note also the space I leave after a '(' and before a ')' plus the indentation of 2 spaces. Just for easier reading. Otherwise, everything looks so much 'packed' for me.
|
|
|
|
|
Aside from the spacing, my style is very similar. The only major difference is that I also use compound statements for "case" code. For example:
switch( iSomeVal )
{
case 0:
{
DoSomething();
DoSomethingElse();
break;
}
// Etc...
}
I do that because the code between a "case" and a "break" (or a fall-through) is treated as a compound statement, and I want it to look like that.
Strange, I know! But I never said that I was "normal".
Peace!
-=- James.
|
|
|
|
|
I do it precisely like that, except I put the break outside the curly brackets. I generally do it exactly as the first poster, although for if, I sometimes do this when I have a block of bounds checking to do:
if (pt.x < 0) pt.x=0;
if (pt.y < 0) pt.y = 0;
if (pt.x > rc.Width()) pt.x = rc.Width();
if (pt.y > rc.Height()) pt.y = rc.Height();
which segues into another point - I am a little obsessive in my own code about spaces either side of operators, largerly so I can search my code for statements like "if x < 0", knowing that "if x<0" isn't in my code ( and the other permutations possible ) makes that so much easier.
Does that make me neurotic ?
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
I agree with having extra curly braces in the 'case' sections, but I only use them when I want to declare a 'very local' variable. This way, I can 're-use' this variable different times into the same switch statement. So, in this case my code would look like:
switch ( iSomeVal )
{
case x:
{
int x = 0;
x = ...;
DoSomething( x );
}
break;
case y:
{
int x = 0;
x = ...;
DoSomethingElse( x );
}
break;
default:
ASSERT( FALSE );
break;
}
If I don't have local vars, I don't use the curly braces, because I'm afraid that at the end there will be too much drifing to the right...
But again, that's my personal opinion...
|
|
|
|
|
In fact, if you declare a variable within a switch and DON'T use the curly braces, your code will not compile.
|
|
|
|
|
("case: 0" --> "case 0:")
|
|
|
|
|
Showing an improvement... Demonstrated learning from someone else... Good.
Now... about working on that originality...
Peace!
-=- James.
|
|
|
|
|
1. if ()
{
}
else
{
}
2. if () {
}
else {
}
3. if () {
} else {
}
4. if ()
{
} else
{
}
|
|
|
|
|
Personally, I use #1. In the case of an "else if", I place the "else if" on the same line:
if( ThisCondition )
{
}
else if( ThatCondition )
{
}
Peace!
-=- James.
|
|
|
|
|
Hi,
I wondered who has changed the style they use from the one they were taught.
I define "taught" as the one featured in you favourite book when learning and well as the tutor you may have had.
I'd guess only a few.
TIA.
ATL Student 
|
|
|
|
|
> Hi, I wondered who has changed the style they use from the one they were taught.
I have...! (I recently uncovered a printout of source code to the first vertical shooter that I ever wrote in college! I scared myself with what I used to do!!! )
My coding style has morphed from:
int function ( void )
{
if ( this_variable_name!=0 )
call_this_function ();
return 0;
}
To:
int Function (void)
{
if (ThisVariableName != 0)
CallThisFunction();
return (0);
}
And finally to:
int Function( void )
{
if( iThisVariableName )
{
CallThisFunction();
}
return( 0 );
}
Guess I got smarter as I gained more experience! 
-=- James.
|
|
|
|
|
i learned C from the K&R book. that used style #1. so i used that style for many years. but, eventually, i found, tried and decided that i really prefer style #2.
the official style at the job i'm at now is style #3, but i refuse to use it (along with everyone else who's been here < 3 years)
so, yes, i changed style: on my own. but i won't do it for coding standards.
-c
------------------------------
Smaller Animals Software, Inc.
http://www.smalleranimals.com
|
|
|
|
|
I agree with your style preference, but isn't a slightly uncomfortable standard better than no standard at all? Alternatively, if everyone who's been there less than 3 years has the same preference, I would think you have a good case for banding together and proposing a change to the company standards. Maybe you could refer the more established programmers to this poll.
|
|
|
|
|
yeah right. you know that saying about old dogs and new tricks ?
b.t.w. the company in question here is *not* Smaller Animals. we do things right, there.
-c
------------------------------
Smaller Animals Software, Inc.
http://www.smalleranimals.com
|
|
|
|
|
I'm coming to the view that enforcing coding standards just isn't that beneficial. If the standards never change, then you better have got it right the first time and what's the chance of that? If they do change, then either you've got multiple standards in legacy code or you've got to rewrite it. Neither is a good solution.
And what if you use code acquired from CodeProject, or at any rate, outside the coverage of your standards? Do you want to rewrite all that code? Even if you're just using a library/API, you're not going to wrap all the member functions/ function calls to change the style from this_is_a_function() to ThisIsAFunction() or vice versa, are you?
I do think coding style consistency is beneficial at the function level and class level, but beyond that it becomes decreasingly important. Another programmer should be able to look at a function, recognize its style and therefore find it easier to read thanks to the consistency of style. That's all that's worth aiming for.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
