Best Practices for Programming in C

An anonymous reader writes "Although the C language has been around for close to 30 years, its appeal has not yet worn off. It continues to attract a large number of people who must develop new skills for writing new applications, or for porting or maintaining existing applications. This article provides a set of guidelines that can help you with your coding."

Comments

I wish C were that popular!

[bluethundr]

Although the C language has been around for close to 30 years, its appeal has not yet worn off.

I'm sure that in some ways that statement may be true, but I've been trying for MONTHS to get people interested in the C/C++ Meetups! Compared to Python you'd think we were trying to start a Sanskrit study group!

btw..fp? hee hee!

Re:I wish C were that popular!

[iendedi]

I've been trying for MONTHS to get people interested in the C/C++ Meetups! Compared to Python you'd think we were trying to start a Sanskrit study group!

The King is dead. Long live the King!

This is the way it always is. Established, dead, boring... You do your work with it but don't get emotional about it. Newer tech, newer languages - these attract a certain personality type that tends to be more passionate about evangilizing and promotion.

Looks like the author also knows VB

[stef0x77]

From the article:

for(i=0 to 100)
array[i]=0

Maybe I missed something but since when is that C?

Re:Looks like the author also knows VB

[vadim_t]

That doesn't look like any language I know. If that was VB then it would have been:

For i = 0 To 100
array(i) = 0
Next

Brain fart, I suppose.

Re:Looks like the author also knows VB

[avalys]

The article specifically refers to the snippet you mentioned as pseudocode, not C.

Re:Looks like the author also knows VB

[smittyoneeach]

VBScript, you mean.
In VB, you need:
Next i

Re:Looks like the author also knows VB

[Anonymous Coward]

No you don't.

Re:Looks like the author also knows VB

[vadim_t]

No, you don't. It's considered a good thing to do, but it's definitely not necessary.

Re:Looks like the author also knows VB

[jilles]

they probably left out some #define's that make it valid C :-)

Re:Looks like the author also knows VB

[DWEB]

The article clearly states pseudo code jack-ass.

I wish that the code i'm debugging had...

[neosake]

Whitespace :)

Write in C

[pauljlucas]

(Sing this as you would "Let it Be.")

When I find my code in tons of trouble,
Friends and colleagues come to me,
Speaking words of wisdom:
"Write in C."

As the deadline fast approaches,
And bugs are all that I can see,
Somewhere, someone whispers:
"Write in C."

Write in C, Write in C,
Write in C, oh, Write in C.
LOGO's dead and buried,
Write in C.

I used to write a lot of FORTRAN,
For science it worked flawlessly.
Try using it for graphics!
Write in C.

If you've just spent nearly 30 hours,
Debugging some assembly,
Soon you will be glad to
Write in C.

Write in C, Write in C,
Write in C, yeah, Write in C.
BASIC's not the answer.
Write in C.

Write in C, Write in C
Write in C, oh, Write in C.
Pascal won't quite cut it.
Write in C.

scanf replacement?

[ichimunki]

(please note: I'm still learning C) So what should I be using instead of scanf? The article recommends against it, but doesn't say whether there is a better way to get some input and get interesting chunks out of it.

Re:scanf replacement?

[McAddress]

use fget, and then ato[i | f ] #excuse the perl syntax

Re:scanf replacement?

[Saint Nobody]

ack! no way!

use strtol, strtoll, strtoul, strtoull, strtof, strtod, and/or strtold. they're much better functions. all of them except strtol, strtoul and strtod are relatively recent additions, though, so you might want to stick to those 3 for now.

Re:scanf replacement?

[wtf]

I'm not sure ato[i|f] is the best answer either, consider the following code:

#include <stdlib.h>
#include <stdio.h>

int main( void )
{
printf( "atoi( \"1\" ) = %d\n", atoi("1") );
printf( "atoi( \"-1\" ) = %d\n", atoi( "-1" ) );
printf( "atoi( \"0\" ) = %d\n", atoi( "0" ) );
printf( "atoi( \"foo\" ) = %d\n", atoi( "foo" ) );
}

and the resulting output:

atoi( "1" ) = 1
atoi( "-1" ) = -1
atoi( "0" ) = 0
atoi( "foo" ) = 0

Not exactly what you want. btw if I had a better idea I'd mention it. Maybe fgets and then sscanf? But then you'd still have to worry about numerical overflows, so maybe not.

Pat

Re:scanf replacement?

[jguthrie]

Functions in the scanf family are truly useful, if you can grok them. However, error recovery can be a pain, so it's not generally advisable to use scanf() or fscanf(). Instead, one practice that I use is to read lines into a buffer (using fgets so that you'll be less likely to have a buffer overflow) and then run sscanf on it.

You should always check the return value from any functions in the scanf family against the number of items whose value you want to set. That will tell you whether or not you've read everything you expected. Also, bear in mind that it can be tricky to set up the format string properly. I can't think of any examples of nonobvious behavior off the top of my head, but I find I use a lot character sets when I use scanf.

Re:scanf replacement?

[egoots]

fscanf can be used in a safe manner in conjunction with sprintf to dynamically format and constrain the input buffer length. See the following code snippet:

char inbuf[80], format[10];
sprintf(format,"%%%ds", sizeof(inbuf)-1);
if (fscanf(fp, format, inbuf)!=EOF)
// do stuff

See "The practice of programming" by Kernighan and Pike, for more details.

Re:scanf replacement?

[Anonymous Coward]

getchar() all the way, baby.

Re:scanf replacement?

[stonecypher]

Generally, when people suggest that printf/scanf are evil, they're advocating the use of the operator>. Note that these are C++, not C. There are a number of reasons, not the least of which is that they're much more easily guarded regarding insane inputs, and that they're able to handle any type (useful for generic programming.)

Other people just want you to bootstrap your machine with a paperclip.

Re:scanf replacement?

[KewlPC]

Actually, it's because they don't have a length specifier, which means that sooner or later you'll get a buffer overflow from some idiot/malicious person giving the program too much input.

Re:Best practice? Don't use it!

[sporty]

C is really just glorified assembly language. It only provides a minimal of type checking over most macro assemblers and is about as easy to read. It does have alot of operators to save typing though.

But for embeded systems, where your resources may be very limited, wouldn't a good optimizing compiler do a better job than an OO one?

I'm sure an assembly code monkey could do better than a c junkie, but I wouldn't know the rankings between the compiled code now-a-days as a desktop programmer.

Re:Best practice? Don't use it!

[pauljlucas]

... most programmers don't have enough training to use a more complex language.

C is a fairly complex language, e.g.:

some_func( (void (*)(void*))x );

C is really just glorified assembly language.

I don't think this has ever been in distpute by anybody. However, it's still far easier to write in C than assembly.

I think that C and 'C++ used as C' is the reason alot of commercial software is so bug ridden. Hopefully Java, .NET/.GNU, scripting languages and competent use of modern C++ are starting to change that.

Java (and other "restrictive" languages) only prevent a small class of errors, e.g., memory leaks. They do nothing to prevent logic or algorithmic errors, and they all have their own gotchas. Try changing what hashcode() returns for an object at run-time after you've put in into a hashmap: have fun finding and debugging that!

Better site

[fredrikj]

Here is a much better article about coding practices. It also covers broad topics, not just C in specific.

Re:Better site

[Anonymous Coward]

From the site linked in parent post:

"If a maintenance programmer can't quote entire Monty Python movies from memory, he or she has no business being a programmer."

So true, so true.

Re:Better site

[asimulator]

I like this one better!!

Re:Best practice? Don't use it!

[jungd]

I've read many times that modern compiled C code or well written C++ code is typically far better than hand written assembly code. I don't know that definitively, however. I'd assume that for small snippets, like specific loops etc., that an assembly programmer could still look at the compiler output and perhaps improve it slightly (if they could understand it!).

C++ is a super-set of C, so in theory you can get the same output if you want. However, typically program efficiency is at a higher level than specifically optimized loops etc. - e.g. at the level of algorithm choice. In addition, a good C++ matrix class (for example) can do constant folding, loop unrolling and ensure the memory access order of common matrix/vector operations is appropriate for your CPU (via templates) - that you'd be hard pressed to do in C except for very small projects.

Best Practice 0

[__past__]

Wow, that article was really enlightening. *cough* However, here's what I think should be the first item in every "Best Practives for Programming in C" list:

Dont programm in C unless you have a really good reason to.

Good reasons are:

• You are extending an operating system kernel or other huge system that is written in C.
• You are writing a library and expect it to be used from several other languages. C is the lowest common denominator, every language has a C interface.

In all other cases, use a high-level language. Users and admins will be grateful for not having to download patched versions every time a buffer overflow or format-string error is found. You will like being able to concentrate on the core problem you want to solve instead of dealing with all the detail C and its libraries left for you to care about. If you need speed, use a high-level language with a good compiler. If you need to bit-fiddling, use a high-level language with good bit-fiddling support. They exist, and there's even some overlap between them.

Re:Best Practice 0

[torpor]

Bah! You only say that cause you're probably a crap C programmer.

Real C programmers never think "never program in language unless you have to".

Real C programmers think "I can make any new computer language under the sun in C, so why should I switch from C in the first place ..."

"(void *)(void *);" ...

Re:Best practice? Don't use it!

[sporty]

C++ is a super-set of C, so in theory you can get the same output if you want. However, typically program efficiency is at a higher level than specifically optimized loops etc. - e.g. at the level of algorithm choice. In addition, a good C++ matrix class (for example) can do constant folding, loop unrolling and ensure the memory access order of common matrix/vector operations is appropriate for your CPU (via templates) - that you'd be hard pressed to do in C except for very small projects.

Ah.. but with C++, you have complications like inheritence and polymophism that can make C++ more complex. I'd suspect OOP systems to be a little less efficient memory-wise at least, to be a bit more ineffficent for this dynamic type thing. But then again, what do I know? :)

Nothing new

[McAddress]

This article really does not say anything that any decent programmer does not know. Why we need an article to tell us the basic rules of C is beyond me.

1. Indent properly.
2. Make your code readable.
3. Use good variable names.
4. Avoid buffer overflows.
5. Avoid using statements like goto.

They missed the most basic rule of them all though, convert to C++.

Re:Nothing new

[Anonymous Coward]

They missed the most basic rule of them all though, convert to C++.

The basic rule if you want to screw things up worse. C++ only has one niche: game development. For anything else, use an adequate high level language (C++ does not qualify as high level, neither as adequate).

Re:Nothing new

[zulux]

Ahem...

1. Indent properly.
2. Make Your code readable. //this is a great idea
3. Use_good_variable_names.
4. Avoid buffer *overflows.
5. for (;;x = "Avoid using statements like goto.") {;}

Re:Nothing new

[Salamander]

They missed the most basic rule of them all though, convert to C++.

Better yet, convert to a language that doesn't have every wart from C plus some tumors of its own. Why settle for moving to a different piece of the swamp when you can climb onto dry land?

Re:Nothing new

[peterpi]

6. Be aware that rule number 5 said 'Avoid', and not 'Never'.

When a goto is safe, readable and tidy then you should use a goto.

Re:Nothing new

[Anonymous Brave Guy]

Better yet, convert to a language that doesn't have every wart from C plus some tumors of its own. Why settle for moving to a different piece of the swamp when you can climb onto dry land?

Because no-one's found dry land yet? :-)

(Yes, there exist languages that are technically superior to C++ and/or have stronger underlying programming models, but none of them yet has the critical mass of users and support, particularly libraries, that C++ has, without compromising some other way.)

Re:Nothing new

[jcochran]

The real rule in programming is:

1. Write your code as if the person maintaining it is a homicidal maniac who knows where you live. All else is commentary.

Re:Nothing new

[Anonymous Coward]

2. Make Your code readable. //this is a great idea

/* Too bad you forgot to avoid C++ style comments */

Re:Best practice? Don't use it!

[__past__]

Java (and other "restrictive" languages) only prevent a small class of errors, e.g., memory leaks.

About every language except C and C++ (including some that are more "enabling" than "restrictive") effectively prevent code injection by buffer overflows and format string errors, which make for a significant portion of exploits. Of course, a system is not automatically safe if you get rid of these problems, but scince logic or algorithmic errors (or plain stupidity :-) are possible in C as well, you can only win by not using it.

Re:Best practice? Don't use it!

[jungd]

When writing C++ you have full control over the use of dynamic type info, static or polymorphic method lookup, memory use and object lifetime, etc.

So, a good programmer can ensure that for performance critical code, none of those expensive features are used (selectively).

Re:Best practice? Don't use it!

[_xs_]

Well, in my job it's common to see C code for almost all our embedded firmware. The only exceptions to this that I've seen is the stuff written in assembly. It's also used to write most of the test software we use. Our department has consciously chosen to limit us to C or VB for development unless you can come up with a truly good reason for using another language. Our department is concerned mostly with testing the products manufactured in our factories. Programming was an interesting little course taught on the side in our electronics courses. From experience we've found that it's easier to train people on one or two languages, rather than have them try to remember (and purchase licenced copies of) VB, VC++, LabWindows, LabView, QuickBasic, HP Vee, Perl... I think that the deficiencies in any language are usually minor. It's more important to build up good techniques and practices like the original author had intended.

The old saying "It's a poor workman who blames his tools." applies here too.

Obfuscated Error

[wbav]

Apparently it was too obfuscated for IBM. The first code example is missing a } at the end of the line.

peephole

[LarryRiedel]

FYI, the article seems to be something like a company "basic C coding standards" rather than anything to do with what I understand as "best practices"; maybe a coding tips sheet for an introductory C programming class.

Larry

Re:peephole

[Zarf]

FYI, the article seems to be something like a company "basic C coding standards" rather than anything to do with what I understand as "best practices"; maybe a coding tips sheet for an introductory C programming class.

From what I've seen in industry there are plenty of PHB's that need to read things like this. I've had PHB's argue that "Everything should be a global variable" because it "makes everything easier." Real businesses need to hear things like this... if it comes from IBM someone just might listen.

Re:Best practice? Don't use it!

[BrokenHalo]

Not sure about other "real programmers" (yes, I'm 40 years old, and old enough to know what a real programmer is :-)) but I can write buggy code much more quickly in assembler than in C... :-)

use good libraries

[nthomas]

In addition to the good advice proffered by the article, I should also like to add that using good libraries can make a world of difference.

For example, for the C program that I'm writing right now, I decided to use GLib -- the base utillity library used by GTK.

I initially chose it for portability reasons, but soon discovered it had a wealth of cool stuff in it. In addition to providing the standard data structures (trees, hashes, linked lists), it also has a string type ( GString, ) which handles a lot of the string issues that C programmers get bogged down with.

A lot of the gotchas (buffer overflows, et. al.) mentioned in this article have to do with these string issues, and using GLib's GString data type has enabled me to avoid those.

There is another library similar to GLib, The Apache Portable Runtime, used in the Apache webserver, and also in Subversion.

In addition to all this, I'm using XML as the storage format for my program, mostly because libxml takes care of the file parsing issues so I don't have to.

Bottom line, choose your libraries carefully, they can make a world of difference.

Thomas

Re:use good libraries

[Anonymous Coward]

Or just use Objective C with NextStep/OpenStep/Cocoa/GnuStep.

Re:use good libraries

[Photar]

Huh huh, you said gstring. Huh, /beavis.

Re:use good libraries

[Josh Booth]

I never realized that you could do real object oriented programming in C until I used GTK+. Admittedly, I'm an ameteur programmer who taught myself C by way of C++ (screwy, ain't it?), but with C you can do all your OOP and with GLib, it's not too bad. I just wish there was decent documentation on GObject, which might be a nice idea to me if I know how to use it. From my viewpoint of not being able to use it, though, it seems very overcomplicated. Oh, and libxml is really a great programming library too.

Re:use good libraries

[IamTheRealMike]

Yes, GObject is over complex. Regardless, it's useful anyway. Find more info here.

More Tips!

[mugnyte]

Oh what enlightenment!

- When you've learned all there is to know about C, find out how to simplify it a bit in C++. Notice the job security and look of awe when you master the ++.

- After mucking around in these low-density languages, step up to Perl and see how a language built by a task-oriented person stomps one built by a system-oriented person. See your project file sizes shrink before your very eyes!

- Now take your newfound magic ability to learn new languages and apply it to whipping out pages with PHP and MySQL for all your friends quickly! You'll be the talk of the C crawlers crowd! Hey! Gimmie some content! Aw, forget it - let me just play!

- Now plumb the depths of (supposed) machine-independent laguanges by writing some Java and finding out what "Sun-certified" means! (hint: Sun owns it)

- Optional: Head back to school to get a PhD in autoprogramming theory and self-construction methods. Sequester yourself away to your dorm room for endless hours of experiments training a neural net to convert tasks to code using the most efficient method possible.

- Finally, wrap up your technical life by examining all these related language nuances holistically and achieve the zen of programming: "there is no language"

Re:More Tips!

[12357bd]

Oh master, you missed the entropy mantra! "No Code, no Data, random and order are equal, MMMMMMMMM"

Re:More Tips!

[Salamander]

Nice satire. Unfortunately, I think a lot of Slashdotters will take it (especially the second bullet) seriously.

Re:More Tips!

[Anonymous Brave Guy]

Nice satire.

Satirical, but well paid nonetheless. ;-)

I agree, and was it wrong about NULL?

[AdamBa]

I thought you could use NULL to calculate structure offsets, so with something like

struct _x {
int a;
int b;
}

it was legal to say &(((struct _x *)NULL)->b)

to figure out the offset of b within the structure?

So I agree, it seems like pretty basic tips, not any sort of "best practices" thing.

- adam

Re:I agree, and was it wrong about NULL?

[orthogonal]

I thought you could use NULL to calculate structure offsets, so with something like

struct _x {
int a;
int b;
}

it was legal to say &(((struct _x *)NULL)->b)

to figure out the offset of b within the structure?

The compiler may be able to do it; you can not, as it involves dereferencing a null pointer, which makes it undefined according to the C Standard.

You should use the offsetof macro that the Standard supplies, which your compiler may or may not define as (similar to) the construct you're attempting to use.

You'd use
offsetof( struct _x, b ) ;
add apply it to an instance of struct _x as:

#include <stddef.h>

void doit( struct _x* ix ) {
int i = offsetof( struct _x, b ) ;
int b = *(int*)( ( (char*)ix ) + i ) ; // or
int* bp = (int*)( ( (char*)ix ) + i ) ;
}

ah, filks...

[pb]

You can find many more of these here...

Re:Best practice? Don't use it!

[Anonymous Coward]

Instruction sets have gotten harder to program directly. Longer pipelines and other CPU optimizations make it advantageous to have instructions in a particular order to prevent register stalls. Computers are excellent at keeping track of information like that.

In the old days, many CPUs were simple, they only concerned themselves with the current instruction. And, with their lower speeds, compiler optimizations were too slow (and required too much memory) to be worth it. These days, it's not an issue.

Re:Best practice? Don't use it!

[Watcher]

This is getting a little rediculous. I'm seeing people confuse exploits with all other bugs. Buffer overruns and the like, which are a side effect of sloppy coding, make up a minority of the total bugs I see on a daily basis in production code. The only reason they are so well known is the consequences. Higher level languages, such as Java and Python, may protect the programmer against the effects of such sloppyness, but they do nothing to protect you against algorithmic bugs, which make up an overwhelming percentage of the bugs I see. Coding in a higher level language may protect you from easily writing exploits, but they do not guarantee you bug free, stable code. Only paying attention to every line you write, and making it as bullet proof and stable as possible, will help safeguard you from all of the many bugs we see. C and C++ are entirely appropriate languages to work in, if they fit the needs of your project.

the best practice

[pyros]

don't right code that sucks.

Re:the best practice

[Nick of NSTime]

No, sucky code is always left by bad programmers.

Re:the best practice

[stonecypher]

You know, if you don't correct him, but assume that really is what he meant, this becomes funny.

GString?

[nycsubway]

...it also has a string type ( GString, ) which handles a lot of the string issues...

G-String?? Could they have come up with a different name for that type of string? Issues like butt-flossing and the like..

The article is all good, but...

[smittyoneeach]

What I want to see is material on setting up a project in an intelligent way.
I've got Lakos' book, but there just isn't much out there on non-trivial stuff.
How about articles that show intelligent uses of CVS, Doxygen, and autotools?
What about using C++, boost.python, mod_python, and apache for that killer website?

Re:The article is all good, but...

[jdennett]

http://www.accu.org/, by programmers for programmers. There's even a mailing list
open to non-members, though membership is
cheap and includes journals covering C,
C++ and related languages as well as tools,
techniques, and more.

Re:The article is all good, but...

[stonecypher]

Um. You might want to look into the o'reilly and addison wesley catalogs.
CVS: OReilly: Essential CVS, CVS Pocket Reference
C++: Addison Wesley: Effective C++, More Effective C++, C++ Gotchas
Mod_Python, Apache: each have multiple o'reilly books

Boost.python, doxygen: small use solutions in a bigger pool. Notably, for doxygen, you should consider looking into literate programming.

As far as books that are *really* about setting up a project in an intelligent way, try design patterns, fowler's refactoring, code complete, the practice of programming, the mythical man-month, agile software development. That phrase could mean anything.

Re:Best practice? Don't use it!

[FroMan]

C is a fairly complex language, e.g.:

some_func( (void (*)(void*))x );

I would rather say that C allows you to do some pretty complex things than to say C is complex. While there is the obfusicated C coding contest which will show you much worse (complex?) code, it is not that the language is at fault.

C is really quite simple. The number of keywords is few, the syntax is not terribley difficult. I'd rather think of C like legos, very simple, but powerful enough to build awesome creations.

right?

[sczimme]

But code that sucks *should* be righted...

:-)

Re:Best practice? Don't use it!

[Gumshoe]

C++ is a super-set of C

Argh! No it isn't! If C++ were a superset, all valid C programs would be valid C++ programs. This is obvious tripe.

Presumably, this doesn't compile with your C++ compiler.

#include <stdio.h>

int
main(void)
{
int class, try, catch;

class = try + catch;

printf ("%d\n", class);

return 0;
}

Re:Best practice? Don't use it!

[sien]

I work with a guy who is a total guru who has actually done what you suggest, i.e. sat down with C++ code and improved the assembly output of parts of code. He said he would sometimes get a 5-10% improvement in some areas.

Re:Best practice? Don't use it!

[addaon]

In order of best to worst:
1) Code that works
2) Code that doesn't work
3) Code that endangers my computer
If Java can eliminate the bottom class, more power to it. If a program doesn't work, you don't use it. If a program is unsafe, you may get screwed before you figure out not to use it. Again, which is the real danger here?

Higher and Higher

[fm6]

Actually, C, or any language that talks in expressions rather than a symbolic representation of machine code, counts as "high level". The problems you mention really have more to do with the design philosophy of C than any lack of sophistication in the language.

Consider C++: you can screw up in all the ways you can screw up with C, and many more besides. I don't think anybody would consider C++ a low-level language.

I actually agree with your point. I'd just express it differently: C supports the kind of low-level tweaking most programmers shouldn't bother with any more. You should avoid C unless you really need to do this stuff. Otherwise, use a language/library combination that does the low level stuff for you, and probably does it better than you could.

Re:Higher and Higher

[spongman]

I don't think anybody would consider C++ a low-level language.

I'd argue that C++ can be just as low-level a language as C, as long as you disable exceptions and RTTI.

Re:Higher and Higher

[fm6]

So a language that allows you to do low-level things is low level, even if it has lots of high-level features? That's not a definition most people would accept.

I don't think you can have a meaningful definition of "high-level" that doesn't include everything more advanced that assembly language. And once you're past that point, I don't think you can go around insisting that Language X is or is not "more high level" than Language Y. If you try, you just end up with a simplistic assertion that isn't very useful and is only accepted by a few people.

Re:Higher and Higher

[spongman]

You're right of course, most languages allow you to do the equivalent of 'system("asm...");' and therefore they can all be as low level as any other, but my point is that not only is it as easy to do low-level stuff in C++ as it is in C (whereas with some other languages, it's not quite so easy), C++ also provides easier ways to code things that would be just as effient in C.

For example, it's extremely good at doing all sorts of things with tables of function pointers and sets of functions that take the same type of (struct *). In fact I'd say that if you're writing C code that uses either or both of those, then you should probably be using C++, for no other reasons than the code that's generated is at least as efficient (depending on your compiler), it's more readable, you have to write less of it, and you get better type checking.

It's not such a big step up on the 'high-level language' ladder, but AFAICT there should be no reason to write in C intead of C++ except: 1) my compiler sucks, and 2) I suck.

Re:Higher and Higher

[fm6]

OK, I guess I agree with you. C is obsolete except for the specific kinds of programming in your list. I just stick at saying that C is not a "high-level language". Probably doesn't matter, but I pick semantic nits for a living, and even on Slashdot I can't help myself.

Re:Best practice? Don't use it!

[leviramsey]

C++ is effectively a super-set of C, though not a strict superset of C.

Good enough for you?

Re:Best practice? Don't use it!

[Josh Booth]

Who modded him informative? Of course it won't work because he uses C++ keywords as variable names! IT'S A JOKE! LAUGH!!!

Using continue in place of the null statement?

[geoswan]

The null body of a for or while loop should be alone on a line and commented so that it is clear that the null body is intentional and not missing code.

while (*dest++ = *src++) ; /* VOID */

This could be rewritten as:

while (*dest++ = *src++)

continue;

I believe this is clearer, and less error prone.

Re:Using continue in place of the null statement?

[AuraSeer]

It's even clearer to use curly brackets, but the article doesn't mention that either.

IMO every loop should have brackets, and every 'if' statement too, even when not strictly necessary. They're as good as extra whitespace for visually separating chunks of code, and there's absolutely no downside to including them. I've never understood why many C programmers are so resistant to the idea of extra brackets.

Re:Using continue in place of the null statement?

[CrazyWingman]

I completely agree with your curly braces statement. The company I'm working at now specifically states in their "Coding Guidelines" that all loops - normal, empty, one-line - should have braces (also all if statements, try/catch blocks/etc.). This is mainly to allow for easy changes later. You don't end up with the random errors that come in to play when you change

while(something)
do something;

into

while(something)
do something;
and do something else; //oops

rather than

while(something) {
do something;
and do something else;
}

Admittedly, this is something that most programmers get used to finding fairly quickly (or even completely avoiding), but the braces already being there are nice.
BTW, the classes in software development at MIT recommend the same thing (putting braces in all loops/if statements/etc.). Just because I have no problem with specifically mentioning MIT, but doubt the company I'm working for wants me to use their name everywhere. :)

Re:Using continue in place of the null statement?

[whizzter]

i totally agree, altho i had to learn that lesson myself the "hard" way :P.

back in 99 a while after i started using c/c++ i was on a 50 hours spree to get a "demo" done. (check www.scene.org for the definition of demo)

it all looked fine and i sent the stuff away, then when viewing the demo on the bigscreen for the actual competition they had to select a special graphics mode that made the bug visible.

it was just the typical if () blabla; moreblabla; that wasn't in curlys and that piece of code was a boundcheck... needless to say it was properly f*cked.

funny tho. nowadays my code almost looks like the IBM guidlines, and that's mostly due to my own taste :)

/ Jonas Lund

Re:Using continue in place of the null statement?

[JamesP]

I prefer

while (*dest++ = *src++) malloc(1000);

Re:Using continue in place of the null statement?

[fnj]

I agree with you, but you have invoked a pet peeve of mine.

[pedantic]

They are braces, not "curly brackets", let alone "brackets".

These things have perfectly good names.

() parentheses
[] brackets
{} braces

[/pedantic]

Re:Using continue in place of the null statement?

[AuraSeer]

Of course. You'll have to pardon me for the error. I've been working a lot with English majors lately, and those people never know the right word for anything. ;)

Re:Using continue in place of the null statement?

[geoswan]

Good point.
Ted Nelson corrected me about not using these names, in 1979.
But what do you call the ">" in a preprocessor #include statement? "Angle brackets" is what I have heard them called...

Re:Using continue in place of the null statement?

[Anonymous Coward]

This could also be rewritten as:

while (*dest && *src)
{
*dest = *src;
++dest;
++src;
}

I believe this is clearer, and less error prone.

If you are were really worried about errors, you'd be using STL.

dest.resize( src.size() );
std::copy(src.begin(), src.end(), dest.begin() );

I believe this is even clearer and less error prone.

Re:Using continue in place of the null statement?

[geoswan]

C is a living language, like English -- in that people develop idioms. I read an article, a long time ago, that made this point. It recommended adopting the good idioms of those around you.

Is:

while (*dest && *src)
{

*dest = *src;
++dest;
++src;

}

clearer than:

while (*dest++ = *src++)

continue;

I don't agree -- because of the idiom factor. Yes, the first is clearer to those who don't yet know C. But I believe the latter is clearer to experienced C programmers.

Interestingly, a moderator has moderated my original comment as "offtopic". LOL. A comment on C programming, that quoted a the original article, and inspired a dozen on-topic replies was "offtopic"? Why am I always the last to learn these things.

Re:Using continue in place of the null statement?

[Anonymous Coward]

IMHO "continue" for an empty loop body isn't currently an idiom (I've never seen it until now), though it is clear enough that it deserves to be.

Re:Best practice? Don't use it!

[Gumshoe]

"Who modded him informative? Of course it won't work because he uses C++ keywords as variable names!" Err, that was the whole point. It's a valid C program but not a valid C++ program, therefore C++ isn't a superset of C.

Re:Best practice? Don't use it!

[Anonymous Coward]

C++ is a super-set of C

*sigh*, common myth. The standards, which are available for a small fee from the ISO, say otherwise.

C++ is absolutely, postively not a superset of C. It is quite easy to create valid C code that a standards-compliant C++ compiler can't digest, even by accident.

Just like UNIX!

[Junks Jerzey]

Although the C language has been around for close to 30 years, its appeal has not yet worn off

UNIX is the same age, and it hasn't stopped people from thinking that UNIX-like operating systems are the pinnacle of good design.

Re:Just like UNIX!

[Anonymous Coward]

No, but most people, even Unix and Linux users, KNOW that unix is NOT the pinnacle of good design.

It just sucks slightly less than the other viable alternatives.

Re:Just like UNIX!

[Anonymous Coward]

Huh? What's your point? C is the pinnacle of good design! BTW, I'm not joking.

Re:Best practice? Don't use it!

[Junks Jerzey]

don't think this has ever been in distpute by anybody. However, it's still far easier to write in C than assembly.

IMO it isn't. Assembly is trivially easy to write. But assemblers have gotten progressively crappier over the years, as much more development effort has been put into C compilers. Even popular assemblers like NASM are barely passable compared to what could be done.

OTOH, Best practice? Don't use overkill languages

[QuasiEvil]

I'm an electrical engineer first and a programmer second. I write everything from BIOS-esque firmware clear up to applications that do data analysis from huge mainframe databases for my company. My language of choice? As close to ANSI C as I can get, though usually I get lazy and use some GNU extensions.

Now, why on earth would I do something like that? Just to piss off the comp sci types around me? Well, no, but that's a nice side effect.

Reasons I love/use C:

- It IS glorified assembly. As such, the compiler tries to be minimally helpful and just lets me do what I want to do.

- It doesn't allow OOP crap. I won't argue that OOP doesn't have its place, somewhere, but that place isn't in anything I've needed to build yet.
Why do I hate OOP so much? First and foremost I find it only a tool of obfuscation in the stuff I write. It's much easier to debug procedural code by just following the execution path than wondering what the hell the object that was just instantiated invoked in the constructor, etc. Too much jumping around in the code - basically causes me to forget to look, because it's not intuitive. Same exact reason I hate FORTH (but I'm still fluent in it anyway). I'd rather just have an initializer function called immediately following the declaration of a new variable than having behaviours tacked on.

- C is faster than C++ if you do everything according to the OOP model that C++ leads you toward. I guarantee my pointer math blows away any "safer" solution in terms of raw speed. It's also just as safe, because all the inputs are bounds checked once so I know they can't exceed certain limits. However, for intelligent mixes of OOP-model code and C-style fun, there's no significant speed difference.

- Also, C is standard. C is everywhere. I can use it (with code appropriate to the task) on everything from a PIC12xxx series part clear up to our IBM big iron (though that lack of curly braces it quite annoying). As long as I hang out close to ANSI, my code tends to be very portable. As such, I have a library that is used on everything from small, embedded M68k-series processors up to 16-proc Unix boxes and even larger yet mainframes. Completely threadsafe, no memory leaks, and very, very portable.

Basically, don't use bloat-o-language unless you have a good reason. Remember - CPUs still essentially execute one instruction at a time, mostly in order. Programming is all about moving register 1 to register 2, possibly while performing an arithmetic operation involving register 3.

I would assert that inappropriate use of OOP model programming, a complete disregard for effeciency in the face of beauty-of-design, and an unholy fascination with language du jour has lead to the sorry, bloated, buggy, slow state of modern applications. IMHO, OOP has lead us down this path, without buying us much. Much except the ability to hire less competent programmers to build their tiny chunk of the application, because everything's overdesigned and all the interfaces are pre-specified, because that's how humans would model the problem. Usually there's little regard for how a machine could best handle the problem.

atoi is a bad idea, too much undefined behavior

[jdennett]

atoi has undefined behavior for some error conditions. strtol is a safe version. You should only consider using atoi if you are entirely sure that the input is valid. And even then you should choose to use strtol to make the code rubust in the face of changes.

(For C++ heads, just read an int from a stream of whatever kind with >>, just as you do for any other type, and then check the stream status afterwards to make sure the operation succeeded, as in if (mystream >> myint) it_succeeded(); )

They're already written

[andy@petdance.com]

Buy a copy of "Code Complete". Scrawl "coding standards" on the front in big black marker. Live & breathe it.

Rob Pike: Notes on Programming in C

[Rick BigNail]

A classic

Relative performance of asm/C/C++

[Anonymous Brave Guy]

I'm sure an assembly code monkey could do better than a c junkie, but I wouldn't know the rankings between the compiled code now-a-days as a desktop programmer.

Possibly, but he'd have to be a very good monkey. Many instruction sets and processor architectures are so complex now that writing things the "intuitive" way in assembler does not yield the optimal result. It takes a lot of specialist knowledge to get a good assembly implementation of non-trivial algorithms on such systems, and the best place for those specialists is... writing compilers. IOWs, Joe C Newbie may well get a better implementation of some common algorithm than the average assembler programmer, because Joe has John C Compiler on his side.

As for C against C++, right now, optimising compilers for C do better than for C++, and hence C is faster than C++-used-as-C, though the gap is closing as C++ optimising compilers catch up. OTOH, C++ has much more potential, principally because it supports higher level constructions like exceptions and polymorphism natively, and because templates are a tool for improving efficiency that C will never match. Overall, well-written C++ that uses the language's features effectively is already faster than similarly well-written C, and the gap is widening.

Re:OTOH, Best practice? Don't use overkill languag

[Hast]

There certainly are areas were OOP or other even more "ivory tower of computer science" ideas are not very useful. Low level programming being the most apparent.

And processing of large data volumes in a fairly straight forward manner is also very good to do in straight and "simple" code. And C is really good for that. (I'm think eg cryto code, which is both quite math intensive and highly sequential.)

I won't comment on your views on OOP, while I don't agree with them I don't think anything good will come out of the discussion. (The general idea with all higher level languages is however to map the language as closely as possible to the algorithms as possible. It becomes obvious when you compare eg sorting algorithms in different languages.)

It IS glorified assembly. As such, the compiler tries to be minimally helpful and just lets me do what I want to do.

Remember - CPUs still essentially execute one instruction at a time, mostly in order. Programming is all about moving register 1 to register 2, possibly while performing an arithmetic operation involving register 3.

Now this is just plain wrong. Perhaps you work mainly will micro-controllers but the types of CPUs that are in a typical PC today are not this easy to use at a low level.

First off, /know your compiler/. If you don't you'll end up doing work that the compiler already does better than you. Both easy stuff like constant propagation and strength reduction (change division by 2 to a shift), as well as more complex things like software pipelining. An optimizing C compiler does a hell of a lot more work then you want to do yourself. (You might want to look into how you use pointers in math operations as you hinted. Pointers often confuse compilers and makes it impossible to optimize as much as with indexed arrays.)

Second, a typical PC today doesn't even execute x86 asm. It's translated internally to it's own micro code (typically more towards RISC) and executes that. Furthermore it is super-scalar and as such executes several instructions at once. It also moves code around and a bunch of things that will make your brain go numb if you start trying to optimize it by hand. Hell, you can't even access all the registers manually in many cases.

And that's just looking at the instructions. If you start taking the memory hierarchy into consideration then you'll soon find yourself in a world of confusion.

Fortunately compilers don't get confused by this. So the way I see it a big importance in the future will be not only how well a language maps to hardware and how it maps to the "algorithms". Of even bigger importance could be how clear things are to the compilers so they can do a proper job. (And in many cases C is very suitable for this today.)

Re:Best practice? Don't use it!

[statusbar]

Assembly is trivially easy to write

It depends on the cpu architecture.

For a neat learning experience, try programming the Texas Instruments C6701 family of VLIW DSP's. 8 different execution units allowing you to specifically designate 8 instructions to execute in parallel - depending on the instruction type - 'flying' registers, manually specified wait states - NOP takes a parameter! Multiple busses, 256 bit wide program memory, etc, etc. The TI tools include an 'Optimizing Assembler' which is totally amazing - without it you would end up spending days on a 10 cycle loop plotting out flying register dependancies and opcodes in a 2 dimensional matrix...

--jeffy++

Re:Best practice? Don't use it!

[pla]

Wow, no down-mods as a troll for you yet?

Well, let's pretend you didn't mean to start a "better language" war, and address your points.


Don't even get me started on the 'C is faster than C++ myth'. Only in the hands of an idiot.

MYTH??? Bring it on, Java-boy. Pick any CPU intensive task, and my C code will DESTROY your best Java code for speed.

Java does have its uses, including decent type checking and memory management, as you mentioned. Those carry a cost, however. You don't get something for nothing, and with Java, the cost comes in the form of a performance hit.


most programmers don't have enough training to use a more complex language.

A curious statement... Would you care to give a few examples of more "complex" languages? Particularly with regards to their greater-than-Turing-completeness compared to C?

Or do you mean syntactically, in the sense that you find Brainfuck and Malbolge the epitome of a perfect programming language?


C is really just glorified assembly language.

Yes and no. For the most part, you can trivially convert C to assembler line-by-line, without too much effort. However, the nice neat flow control mechanisms of C makes it almost immeasurably easier to work with than assembler. Don't get me wrong, I do like asm (just can't beat it for speed), but it works best for drop-in function replacements, not for creating the entire framework of a large application.


I think C is only still alive because it is supported on most systems,

Heh... Which, ironically enough, counts as the ONLY reason Java came into existance, and even now that it has "matured", I can build an ANSI-C compatible program on about 6x more platforms than you can run a standard Java app on (whichver "standard" of compatibility you want to pretend exists for Java).

Now go ahead, suck up the humility and grudgingly point out that, since most Java implementations come written in C, you could build a VM on any machine with a C compiler. But that kinda defeats your own point. (And, at least half of those platforms lack the resources to actually *use* the Java VM, although I have to admit I'd like to see someone try using Java on an embedded 68HC05 with 4k ROM and 256 bytes of RAM, if just for the amusement value).


Java has its place. C has its place. Scheme has its place. Perl and Python have their place. Tcl/Tk have their place. I won't pretend people can (or rather, "should", since technically anything the machine can do, you can use C to make it do so) use C for everything, if you don't pretend that C hasn't made it as the single most widely supported and generally hardware-wise powerful language for a reason - Namely, it works, and what it does, it does well. You can try to use a hacksaw to cut lumber, but don't blame the hacksaw for doing the job poorly.

Re:Best practice? Don't use it!

[pyrrho]

>Java (and other "restrictive" languages) only prevent a small class of errors, e.g., memory leaks.

perhaps you and I should form a PAC on this subject!

so true.

And the funny part is this does not prevent memory mismanagement.

Idiosyncratic (and some Wrong) Notes on ...

[fnj]

Jeeze, there's nothing like taking a bunch of idosyncratic preferences and treating them as best practice, let alone enforcing them at a workplace.

I note that Pike doesn't even come close to labeling his piece "Best Practice For C Coding" - for which I thank him.

He does have points that are at least arguably valid, but he lost me at the end.

"Include files should never include files" ?! Pure bull-freaking-crap hogwash. Rather the opposite is the case! Every include file should include every dependency include file. And order dependency of include files is a no-no. It is quite easy to eliminate all order dependencies, and if I have a religious rule, this is it.

Re:Idiosyncratic (and some Wrong) Notes on ...

[Rick BigNail]

I never say I agree with all his points. He is not a god, and he never pretends to be one.

OTOH, Henry Spencer ...

Best practice of C programming

[GnuVince]

I think the best practice of C programming is to use it only when absolutely necessary. Otherwise, use modern language which will boost your productivity and make your applications easier to write and with fewer bugs (and no presence on Bugtraq due to a buffer overflow)

Best Practice, Avoid Dynamic Memory

[tjstork]

Everyone defends higher level things like Java, C# and other scripting languages on the basis that we should have tons of little dynamically allocated little objects floating around, and that you need to have a beefy memory manager floating around to deal with it.

Why do you have to have tons of tiny objects floating around? All that tiny little allocating over and over again just slows everything down, and probably makes your programs more complex. I say, screw dynamic allocation, just use big virtual memory backed vectors of fixed length structures. It's simpler, more reliable, and faster.

Re:Using continue in place of the (NOP)

[Anonymous Coward]

I believe the most common names are:
() parentheses
[] square brackets
{} curly braces
<> angle brackets (although true angle brackets would have a less acute angle)

That way you can be accurate and people who don't know what the difference is will still understand you.

Re:Best practice? Don't use it!

[Anonymous Coward]

Java does not elimitate any of these errors, it just relinquishes responsiblity away to the JVM. Supposedly that can make things safer if the JVM is of high quality, but this is not always the case.

In general, programs that `endanger the computer' are system components. It's going to be a while before they are written in Java.

Maybe It's Just A Cultural Thing

[istartedi]

Maybe C coders just don't cotton to "meetups". Maybe newer languages are more likely to give rise to such things. Mayber newer technologies give rise to such things. Trying to have a C "meetup" today might be a lot like trying to re-create the Homebrew Computer Club or Woodstock.

Of course hardware hacking and Jimi Hendrix music still attract a lot of people. They just don't attract them in the same way.

Origin of that awful phrase "best practices?"

[dpbsmith]

Where did it come from?

Does it mean ANYTHING different from"recommendations?"

Does anyone ever give any evidence that the "best practices" are actually best?

Re:Origin of that awful phrase "best practices?"

[DukeyToo]

I cannot help with your first 2 questions, but the answer to your 3rd is yes.
See Business Case for Better Software Practices from Professional Software Development (2nd Edition of After the Gold Rush).

he sewed his eyes shut because he was afraid to C

[Anonymous Coward]

"Java is as fast as C++"
"C++ is as fast as C"
"C is as fast as assembly"

tell us some more funny ones santa claus.

Re:Best practice? Don't use it!

[dtfinch]

I'm not sure if it's easier to write, I suppose it might be for some, but I think it is a lot easier to learn. In order, the first 4 languages I learned were Basic, Assembly, Pascal, and then C.

Insightful? Give me a break.

[Anonymous Coward]

Why write C when you can write assembler? After all your C compiler can't be as efficient as hand-tuned assembly!

You can draw this efficiency line ANYWHERE -- it is basically the language you learned on that you are predisposed towards and accept the runtime penalty for.

You sound like you learned C first -- mainly because you refer to OOP as crap and everything else as a "bloat-o-language." Realize that there is no one true language. Don't let yourself be defined by the tools you have at your disposal. Generally, you probably used classes in your applications without realizing it, and ironically while patting yourself on the back about not using them. You just didn't use the class keyword.

a complete disregard for effeciency in the face of beauty-of-design
Except that beauty of design often leads to efficiency and simplicity which drastically reduces the number of bugs. Beautiful designs are minimal, yet complete and impose very small overhead for their usage.

Usually there's little regard for how a machine could best handle the problem.
This is a really dangerous statement, almost as if you are justifying writing obscure code in the name of performance. Most C optimizers will do the necessary pointer arithmetic that you pride yourself on automatically. Software is written to be maintained by humans and be used by humans. The computer only executes it. A lot of requirements allow more code clarity over raw performance, and using a higher level language is an important step in that regard.

I am only a college student who is working my 5th or 6th summer doing programming work, and cannot fathom how a 'professional' can make statements like these.

Support? Libraries?

[Haeleth]

Most languages have some kind of foreign function interface, so they can link to C/C++ libraries. Most languages have good mailing lists where, in some cases, even the designers of the language hang out to answer any questions you have and (if you're lucky) to take on board your suggestions for _improving_ the language.

And nearly all of them are more maintainable than C++ (which, as the saying goes, combines the power of Java with the readability of Brainfuck).

Java? Ruby? Perl? Ada? O'Caml?

In American English, that is.

[Haeleth]

In British English, make those

() brackets
[] square brackets ...and guess what...

{} curly brackets.

Re:In American English, that is.

[Anonymous Coward]

If I am to believe this, you would have me believe that British use "bracketical comment" instead of "parenthetical comment"?