{ Coding can of worms }
53 messages in this thread
OK, all you C coders out there, nows your chance … <sound of the can
opener breaking through the tin to get to the worms>. It is my
understanding that many of you have preferences as to how you structure
your code for readability, i.e. where do you put your brackets. At least,
I've heard references to past debates on the subject. Well, I'm a neophyte
when it comes to C coding, and I'd like to know WHAT your preferences are,
and why you hold them, as well as your pet peaves and why you hold them.
Thanks for the input!
— Jane H. (Writing, it's easier read than done.)
You're right, this "debate" is never-ending… maybe it belongs in the
Ramblings section. 😉 Ultimately, I argue for consistency – picking a
scheme and sticking to it. This goes beyond brace-balancing and indent
levels… Among the code you've seen so far, what scheme seems best to
you?
John,
That's just it, the code I've seen isn't all that consistent. Sometimes
the beginning bracket is at the end of the line, and then the ending
bracket is indented on it's own. Other times, the bracket is stand-alone
at both ends. _In_the_same_program_. I thought maybe there was a method
to it that I wasn't seeing, that's why I asked for people's preferences.
— Jane H. (Writing, it's easier read than done.)
I'm partial to the original Kernighan and Ritchie style, where the left
brace is on the same line as the 'if', and the right brace is at the same
indent level with the 'if', and the inner code is indented a certain
level… for me, it's four spaces. I put braces on every 'if', even if it
encloses only a single statement.
Arghhhhhhhhhhhh! Yech! <grin>
Ben
Amateur Radio Callsign is A A 7 A S
Let the fur fly… Geez, the guy who indents two spaces and nests function
calls one within another like foo( roo( goo() ) ) is complaining about K&R
style? 🙂
You bet. K&R style is garbage.
Ben
Amateur Radio Callsign is A A 7 A S
Ben, I remember that once upon a time you mentioned a program which does
C indenting. Was it an editor or does it run from the CLI on a specific
text file?
— Ethan
It runs from the CLI on C source files. It's in the C Toolshed, among many
other items.
Ben
Amateur Radio Callsign is A A 7 A S
What kind of support specifically for C programming does CED provide?
What support for indentation, etc. Thanks.
— Ethan s
I have no idea – I don't use CED, Ethan. I use UEDIT.
UEDIT has auto-indent to the previous level; it' snot all I would want
(keep wishing I had time to write an editor!) but it's certainly useful.
Ben
Amateur Radio Callsign is A A 7 A S
I use the same coding style as most of the others have given. Unlike Don I
use the new ANSI style of function argument declaration. I.e.:
void main(int argc, char **argv)
{
as opposed to
void main(argc, argv)
int argc;
char *argv;
{
Another suggestion would be to adopt a consistent naming convention. At my
company any variable name that starts as lower-case is a local variable and
any variable in upper-case is a global variable. Little things like that
can make it much easier to understand what is going on in code.
— Mike Roth
I agree with that last. The new variable declarations I odn't have any
particular argument with, either. Bracing, un*x or K&R (similar) is just as
important (more so, in fact) as anything else in style, and bad bracing
styles like Un*x and K&R screw up productivity.
Ben
Amateur Radio Callsign is A A 7 A S
If my brain is trained to recognize my brace, indent and variable naming
styles, and I'm damn consistent, then why, wise One, would it screw up my
productivity?
Because, o uninformed and prejudiced one, there are higher performance
recognition behaiviors you could be utilizing; there are certain types of
repair/update/insert behaviors you could be using that aren't possibel with
the staggered and badly indented bracing techniques; because, even tho you
may be massively familiar with your particular bracing techniques, you
could be just as familiar with another style – which would gain you in
productivity, my feeling is.
You know by now that Black Belt is a pretty productive software house. More
than most Amiga vendors, there is no question of that. In fact, a LOT more.
This is one of the primary reasons why – not that there aren't good
programmers onvolved – that's a primary requisite, and I make that
assumtion about you (or I wouldn't be planning on putting your software
into my machines !) but the best programmer will perform better in an
environment that enhances his performance.
You seem to think that because you're used to your style, that you couldn't
get more out of another style. Learning curve? Confidence that your style
is the highest performance style? Both?
Will you grant me that there are better ways to do some things, yet often
both will work, just some are faster and better? Perhaps, just perhaps, the
Un*x way might not be it, eh?
Ben
Amateur Radio Callsign is A A 7 A S
Isn't it possible that I've examined the other brace/indent methods, and
that I think this one is optimal for me? I've only argued that consistency
is one good part of C style… You're arguing that your style is best, but
you haven't given me any reasons why, or any way to judge these wonderful
adjectives you use to describe your style…
Sure, there can be better ways of doing things. I think the important ones
don't have anything to do with indent levels.
Hmm… I wonder if this debate is going to lead to the old 'ILAC' debate
;).
I prefer my braces on the line that follows the if,else if, else, for
etc., and indented 2 spaces. It may not be the best, but I am consistant!
My style has changed in the last few years though. I have been working on a
big job ( Writing to Write, IBM's follow up to Writing to Read ) over the
last few years, and found that working with a large team has helped.
Mike, when you worked for Manx (you did work for them right?), did you
ever look at the old C code they have for the IBM->APPLE cross compiler?
What a joke… I think we are the last people on earth that deal with it.
And it's not by choice! We had some real old jobs that needed to be
upgraded! Boy am I glad I didn't have to work with it (a poor soul that
worked for us got stuck with that job 🙂 ).
-Troy
But I have. I've been over this multiple times. I've written magazine
articles about it. Our company publishes a C kit that demonstrates the
style in tons of C code, and has a short description of some of the
advantages.
And indent levels are only one portion of the style I consider optimum,
there are several other issues. Many *involve* braces, but are not "indent"
issues at all.
Ben
Amateur Radio Callsign is A A 7 A S
John,
I tried Ben's style exclusively for about 2 weeks (ran my code thru his
Pretty Printer to change to his style). I found my productivity went down
the tubes because I couldn't find anything (ie, it wasn't what I was used
to so it took longer to find things). After 2 weeks I still wasn't
comfortable with it — I changed back to K&R. One thing I did keep from
Ben's style that has increased readability is the bracing of case
statements. That I like because at the end of a long group of case
statements the bracing comes out "even".
-sja
Ben,
In my case, going to some other style of bracing would screw up my
productivity. I am so used to the K&R style and have used it for so long
that anything else looks unnatural to me. I find that one thing which
helps my productivity is decent commenting and plenty of white space. I am
quite liberal with blank lines in my code, something that most people don't
put in often enough. Of course, I have a flickerFixer and run in interlace
mode, so I have plenty of screen lines to work with.
— Mike Roth
It would screw it up for a while, no question. After that, it would make up
for the time lost, though. Barry Chalmers, who started with us in November
of 1990, began using our style from the first day he began working for us.
After a few weeks, he was doing it consistantly, and now produces code that
conforms 100% and has had no loss in productivity – he indicates that there
is definitely a gain in productivity… he's sitting right here, and he
says "you make fewer mistakes, and you can make modifications more
efficiently". Barry has been working with me on Image Professional, by the
way.
Ben
Amateur Radio Callsign is A A 7 A S
One thing I was taught in college is to "know thyself." What this means is
to know the kinds of coding mistakes that you tend to make. This helps you
to locate and fix problems more efficiently. I very rarely make mistakes
involving bracing. I just can't see changing my style to be worth the time
and effort.
— Mike Roth
Ok. And as Master Lim used to say: "You no try… you no know".
Ben
Amateur Radio Callsign is A A 7 A S
Ben,
Boy…I just love your absolute statements…as if they were
pronouncements from on high.
You think that K&R style screws up productivity, and for you it may
well screw up productivity. But what applies to you don't necessairly
apply to others.
You see, I personally feel your style screws up productivity
because you have many more lines that have nothing but braces on
them…thus you can't see as much actual code in one screen.
But that's my opinon…and obviously you disagree with it. And I
know I'm not going to change your mind…and you aren't going to change my
mind, so I'll leave it at that.
Don
Ben,
As I said earlier, style debates end up in style wars. After looking at
the style on C ToolShed I'd have to say (IMHO) that it screws up
readability and productivity. That being said, style is highly subjective,
what might be right for one is not necessarily right for all (we'd all be
using clones if that were not the case). The important point is to decide
on a style to use (whether one person working on a project or a team) and
stick to it.
-sja
Well, the only two major bracing styles I can think of are Unix and K&R.
You seem to dislike both. Perhaps you could share your bracing style with
us?
—–> Brian Simmons, Denver, Colorado.
Mike,
I try (but don't always succeed) to use capitalization in function
names to indicate externally callable functions vs lower case names to
indicate functions only used within that specific module.
Don
Don,
I never really thought about variable name conventions too much until
I had to conform to standards at my current job. I'm really sold on them.
Another convention we use is to prepend submodule functions with a prefix
for that submodule, i.e., SysConvertFileName() to convert filenames from
one file system standard to another. That is a "Sys" module function.
This makes it much easier to locate functions when you have hundreds of
them.
— Mike Roth
I agree about variable naming conventions too. It seemed crazy the first
time that I saw it, but having used them (by force, at first) at school for
a compiler design class the benefits quickly became clear.
steve
Ben,
John's style seems very responsible. The only difference from mine is
that I indent 3 spaces. The first thing I do when I get code that someone
else thinks is formated a "better way" is run it through Indent and make it
readable again.
-sja
Jane,
I prefer the so-called UNIX standard method of using braces and
indents:
if (a == b) {
do_something();
do_anotherthing();
}
for ( i = 0 ; i < 99 ; i++ ) {
do_something_else(i);
}
while (a < b) {
a += c;
c += d;
}
and so forth. Note that the for loop above doesn't require braces
at all since there's only a single statement enclosed within them; however,
I belive it's good coding practice and makes the code more readable.
The reason I use that form of bracing rather than the :
for (i = 0 ; i < 99 ; i++ )
{
do_something_else():
}
(likewise with the others)
is that that is the way I learned it, it's the way the example code
is given in K&R (the original definition of the language) and I personally
find it much more readable, neat and clean.
Obviously, others find different methods just as readable, neat and
clean to them. In the end, it's strictly a matter of personal taste.
Don
Thanks Don,
I assume you line up the ending bracket with the same indentation as the
loop statement.
— Jane H. (Writing, it's easier read than done.)
Jane,
The closing brace for the function goes at the left edge…as does
the opening brace for the function. Other braces have the opening brace at
the end of the line containing the for, while, switch, if, etc. statements.
Closing braces go even with the start of the for, while, switch, if, etc.
statement like this:
|<—- presume this is the left edge of your screen
my_funct(a,b,c)
int a,b;
char c;
{ /* opening brace of
function */
/* local vars */
int counter;
for (counter = a; counter < b ; counter++ ) { /* open for
*/
do_something(c);
if (check_something(counter)) { /* open if
*/
foo(global_var);
break;
} /* close if
*/
do_some_more();
} /* close
for */
} /* close function */
again…this is MY preference. You and others may not like it, and
that's fine. The important thing is to select a style you are comfortable
with, but once you find that style…keep it uniform. I noticed an earlier
message from you where you saw mixed styles in one program. That's
generally a bad coding practice…at least for me…it makes things very
difficult to follow.
Don
Don,
Thanks for your input!
— Jane H. (Writing, it's easier read than done.)
Jane,
Coding style wars can get as bad as the "my computer is better than
yours" wars. Pick a style you are comfortable with and stick with it.
-sja
Steve,
I thought it would be best to define the styles before I tried picking
one, you see.
— Jane H. (Writing, it's easier read than done.)
Jane – you asked about the C Toolshed. Please look at it before you choose
a style. Steve is right on one thing – C style is a hot subject; having
said that, let me also say that the advice on style I've seen here so far
ranged from bad to awful, in my opinion.
C style has a *major* effect on how well you will be able to write software
– and don't you believe anyone who tells you different. In many ways, it's
similar to writing for people – the better you write, the easier it will be
to go back later and change things, and the easier it will be to understand
what it was you wrote previously. It also has a major effect on the reader
(who is the computer in this case) in that the better you express yourself,
the more concisely and cleanly, the more likely it is that the reader will
"get the point", and that you will be sure that the point you made was the
one you WANTED to make.
I view C style as critical. I view the Unix, K&R, and wack-hacker styles as
some of the things that drove people to more structured languages… when C
really has everything going for it, including a great deal of freedom of
choice which (like real writing, and life) you can use to screw yourself
until you don't know whether you're coming or going.
Me? Opinoinated? <grin> er, yeh.. opinionated.
Ben
Amateur Radio Callsign is A A 7 A S
Ben – that's always the response I get when I talk to other programmers. "C
sure is a neat language, but it's almost impossible to maintain." Mainly, I
assume, because it's so hard to read. I will take a look at the C
Toolshed, since it's so reasonably priced.
Thanks,
— Jane H. (Writing, it's easier read than done.)
How hard it is to read is directly related to how it is written. Like
english.
Ben
Amateur Radio Callsign is A A 7 A S
Personally, I like those lines with 10 different ++s and –s and *s and
&s floating all over it! Illegible, but does lots and lots with one line.
— Ethan
Ethan,
Don't forget to use the ?: construct, preferably having three or more
of them nested in one line. 🙂
— Mike Roth
Even I have some standards! ?: goes on two lines!
— Ethan
You know, (I'm not kidding) there is a contest that runs now and again that
awards a prize for the most obscure C code. And beleive me, when you TRY to
be inscrutable, you can really go a distance with C. :^)
Ben
Amateur Radio Callsign is A A 7 A S
I heard of one entry (winning?) to that contest which may considerable use
of in-line hex code. I guess that can qualify as being obscure.
Jeff Schweiger
No, that's not the worst. How about identifiers that consist of only an
underbar (_) character. This includes multiple #defines with lots of
parameters. I believe that the contest is in on of the C language
magazines (C Gazette?).
– via Whap!
Hmmm… I'll have to see if I can dig up some details on the status of
the obscure C coding contest, and get some better specifics.
Jeff Schweiger
Speaking of interesting looking C code, someone on USENET posted a C
program that looked like a maze and it creates random mazes. (The code
itself spelled out the word MAZE in capital letters). That's interesting
enough, but he also wrote some macros for the "vi" editor that would solve
these random mazes. Just load the generated maze into vi, load the macros,
hit the "g" key, and watch. Pretty interesting.
Some people have WAY too much time on their hands! 🙂
Steve
You said it. :^) And that guy could probably do amazing things if someone
simply pointed him at a real job.
Ben
Amateur Radio Callsign is A A 7 A S
Gawd, how I hate show offs! (Wish I could be one…) 😉
– Nelson …
Being a UNIX guy by day, I use the same coding style that Don does. But,
as noted elsewhere in this thread, the best thing to do is to find a style
you're comfortable with and stick with it!
General rule of thumb: Don't be stingy with tabs or spaces when you're
coding…it's really annoying to see code that is jammed up to the left
side of the screen. And, if your code seems to be floating all the way to
the other side of the screen and begins to wrap around, re-think the way
you're writing the code. There's probably a better way to write it.
Steve
Steve, regarding your style of bracketting, how do you bracket functions,
or main()?
main() {
do_something(); }
* Or like this:
main() {
do_something(); }
— Jane H. (Writing, it's easier read than done.)
I use the same style that Don described in Message # 7714.
Steve
Thanks, Steve, I appreciate your input.
— Jane H. (Writing, it's easier read than done.)