|
yeah, maybe like this:
Which whitespace style do you prefer?
if(func())...
or
if (func())...
or
if( func() )...
or
if ( func() )...
|
|
|
|
|
Well, I like option 2, but it don't always do it:
if( func() )
What about if statements with multiple expressions:
option one:
if( one && two && three )
option two:
if( one &&
two &&
three )
option three:
if( one
&& two
&& three )
|
|
|
|
|
2
------------------------------
Smaller Animals Software, Inc.
http://www.smalleranimals.com
|
|
|
|
|
i like this one:
http://www.possibility.com/Cpp/CppCodingStandard.html
------------------------------
Smaller Animals Software, Inc.
http://www.smalleranimals.com
|
|
|
|
|
I just looked at some of my old DOS programs, written in the glorious days of the 25 line monitor. The functions look something like this:
void Func(){
if(a == b){
Func1();
Func2();}
Func3();}
|
|
|
|
|
that looks like crap. I bet finding brace bugs were a bitch and a half.
|
|
|
|
|
> I just looked at some of my old DOS programs [...]
Then you must have been a bit inexperienced as well, if you wrote code like that! 
I will not even talk about the 2 space-wide intending...! 
-=- James.
|
|
|
|
|
1 - Men wear Jeans, Women do too!
2 - Men put ear rings, Women do too!
And then, which one of above is:
1- Wrong!
2- Right!
3- Common! No problem!
Then, so what? Who cares how any one does as long as code compiles?!
|
|
|
|
|
Who cares? everybody in the development team do! yes, you would not have any problem during the compilation but ... don't you care setting simple standards according to your team's taste or preferences in coding? cheers!
|
|
|
|
|
Let me tell you who cares... I DO!!! I recently came to a software team who previously, as many other places, enforced no standard on style. Yeah, the code compiled but what about 1 year or 2 down the road when the original developer is gone and features must be added and bugs must be fixed. Someone else is of course stuck with some obnoxious looking code trying to make heads or tails out of it. If the code was done cleanly, like style 2, and commented well then the problem is severly reduced and everyones life is a little easier. Compiling code is important but Clean Compiling Code is very important. It helps all those who come after manage what you write.
Joseph Dempsey
jdempsey@cox.rr.com
Joseph.Dempsey@thermobio.com
"Software Engineering is a race between the programmers, trying to make bigger and better fool-proof software, and the universe trying to make bigger fools. So far the Universe in winning."
--anonymous
|
|
|
|
|
Why not put this in context:
"Who cares about readability, as long as the code compiles?"
This ranks right up there with "We don't have time to write a spec - we have to start coding now becasue we have to show a demo in two months!".
Both of these statements should be grounds for ejection from the profession.
|
|
|
|
|
Its all about readability.
The quicker someone can read and match up logical blocks the better.
I still think that every logical block shoud be preceded with a comment stating the correct logic. Alot of people say why do that thats a waste of 40 seconds. I wrote it and the logic is correct. That is true today but what about next year. Will you still be here. Will you always maintain this code? What about 2 years from now will you still remember it?? This lets other programmers understand the intended logic for that block and aids in preventing the logic from being broken years down the road.
I wish this was a LAW of programming..
|
|
|
|
|
Oh, please... Another "code is for compiler" troll...
|
|
|
|
|
Sounds like a "Redmondtonian" to me:
"It compiles? Ship it!"
Remember that more than just the compiler "looks" at code...
-=- James.
|
|
|
|
|
Go read Code Complete - Now!!
And don't show up as anonymous - use your real name so the rest of us know who not to hire!;P
|
|
|
|
|
>And don't show up as anonymous - use your real name so the rest of us >know who not to hire!;
Really? And what if this was a survey question to see how many Fail or Succeed the evaluation?
Wrong answer and have you failed! Watch out on what you post.
|
|
|
|
|
if(blabla && (bla & bla) || (bla | !bla << 1)) /* comment
comment. blablabla.
other comment. */{
func(); func(); func() /*blabla*/}
how about that? 
|
|
|
|
|
... and then uou get some degree.
|
|
|
|
|
|
|
of course it is easier to read code the way we are used to doing it, and
option number 1 is the traditional way of doing it so most people find
the code easier to read. But I'm always one for logical change for the
common good of all - even if it takes a little getting used to.
The braces lining up is a good way of seeing the scope but option number
one also easily allows for this.
function blah(){
___write(); //(underlines are spaces)
}
the scope can be seen by looking at the indentation, something on the same
column is in the same scope.
The advantage to this style is that more code can fit on the same page so
less scrolling is required to debug some long function or indeed group of
functions. our eyes can see it all at the same time, or atleast more of it
which I find is a great advantage in programming. how many of us have raised
the resolution of our monitors because of this very reason?
the amount of spaces in the indentation is another controversial issue, for petty
people like programmers anyway. for the same reason I like 2 or 3 rather than the
usual 4 so less scrolling is required sideways. although up and down screen space
seems more important to me seen as though I can usualy guess what the contents of
the line are from the viewable section of the line.
my two cents
|
|
|
|
|
You hit space three times instead of TAB ? Or you set the indents ?
On another note, I run 1600 x 1200 on my 17" and 1200 x 1024 on my 15 ( I have two monitors, couldn't do without it ). Is that typical ? I find at that rate I have no worries about horizontal space, and the scroll wheel makes vertical space not at a premium.
If it's any consolation, at work we had MAJOR discussions on style regarding this issue, as I was outnumbered. ( But I'll have you know that my style won the arguement )
Christian
|
|
|
|
|
Whoah!!!
1600x1200 on a 17" and 1280x1024 on a 15"?????? I have a 19" monitor and run at 1153x864. My eyesight is bad granted but I think thats crazy!! (no offence, just kidding!). Having said that I know that people with 20/20 do tend to use much higher resolutions than me.
cheers,
Andrew.
|
|
|
|
|
I know this feeling of having MAJOR discussions at work about this subject. We also had to define -what we call- styling guides and it was a pain in the ... to satisfy everybody. Actually, satisfying everybody is simply not possible.
What we did was, instead of discussing with 30 or more people about styling, having a discussion in a smaller group that was representable for the total development crew. At the end, the 'compromise' was not ideal for every individual, but acceptable for everybody.
But this is a very 'discussable' subject. You can start long philosophical discussions about this for days, weeks, months and -why not?- ages. But at the end, you must come up with a 'common divisor'.
Although I have to admit that we still sometimes daily have discussions about styling guides. Especially with new people who joined us after the 'styling guide commitee' had decided how to work.
On the other hand, having such a styling guide makes it very easy for everybody to read each others code, since we all look into the same direction. Even if you don't fully agree with one or more of the stylings... But that's typically human beings, isn't it??? 
|
|
|
|
|
"Braces starting on line under control line, non-indented" is the only way to go. With this layout (and possibly the indented version with each brace on its own line) you can see at a glance which closing brace ends which opening braces, as they are aligned, without spending ages placing comments after each closing brace to say what it is you are closing.
When using code formatted the other way (with the opening brace on the same line as the statement/condition/etc) it makes it much more difficult to see this at a glance. I always have to reformat code so each brace has it's own line in this case, or I wont be able to 'skim read' the code.
Visual Assist makes it much easier to use my preferred method too, with the brace 'bolding'.
But then again, we all have our preferrer styles, like the people who double-indent case labels in a switch statment, or the guys who seem to like using '/* */' comments instead of multiple lines of '//' (which makes it harder to quickly comment out large blocks with comments in it). Some people, like me, just like being productive. Others who are paid by the hour tend to like making things take longer .
David Wulff
dwulff@battleaxesoftware.com
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
