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!

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: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.

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? :)

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.

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 *);" ...

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: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.