5 ms·

Best practices for programming in C

33 points by twampss 17y ago

silentbicycle 17y ago
"Errors cannot be avoided by recipe. If they could, we could eliminate automobile accidents by plastering the countryside with Drive Carefully signs!" -- Andrew Koenig, _C Traps and Pitfalls_ Some of the article's examples come straight from that book, BTW.
- smhinsey 17y ago
  is that quote meant seriously? certainly it's obvious that the analogy doesn't work. we do have signs plastered around the countryside that are recipes for driving, they just actually include the ingredients. i would think the same applies to code, but rather than recipes, to hold the analogy, you are providing templates for recipes, or maybe style guides for writing recipes. (bad analogy, imho.)
  - silentbicycle 17y ago
    More like listing mistakes to watch for. I was mostly posting to note that the book was a much more in-depth collection of same.
windsurfer 17y ago
C; I <3* u;
saucetenuto 17y ago
"Since function calls usually take a long time, getchar is often implemented as a macro." And then I stopped reading. Does anyone know of a meaning for this sentence that's more sophisticated than "function call overhead is punishing, don't call functions if you can help it", advice that was out of date when C was /invented/, for God's sake? Something special about getchar(), maybe?
- spc476 17y ago
  getc() and putc() can be implemented as macros in standard C (although a non-macro version needs to be supplied as well), so I think the author was trying to explain why getc() may appear slower in some circumstances than others. Of course, nowadays, it would be difficult to measure the difference between a macro getc() and a function getc().
- visitor4rmindia 17y ago
  Um...function calls do have an overhead. Yes it is negligible in most cases but it certainly made a difference when C was invented. In fact, C++ still carries the "inline" declaration around to avoid function call overhead. The compiler can ignore when knows better but the fact that inlining exits implies that function call overhead is not imaginary.
- silentbicycle 17y ago
  Generally, function call overhead is absolutely worth the added ability to abstract, but adding that overhead per character in all IO operations adds up quickly. Getchar is often the innermost loop of IO-bound processing, so inlining it (in this case, by making it a #define macro) is worth doing as a special case.
jonke 17y ago
This is like a never ending issue. One way to start the path to a better practice of C is to read http://www.amazon.com/Expert-Programming-Peter-van-Linden/dp/0131774298 http://www.amazon.com/Expert-Programming-Peter-van-Linden/dp... after you finished http://www.amazon.com/Programming-Language-Prentice-Hall-Software/dp/0131103628 http://www.amazon.com/Programming-Language-Prentice-Hall-Sof...
philwelch 17y ago
I like how gets() and scanf() are both considered unsuitable for use. There's something wrong with a language when you can't trust the standard library's input functions, and I say this as someone who rather likes C in the right context. Where's the mention of the three-argument main() variation? (int argc, char argv, char env)? Is this not standard?
sb 17y ago
just for the record: i always found rob pike's advice on c programming very thoughtful and readable (and, common: he should know ;) http://www.lysator.liu.se/c/pikestyle.html http://www.lysator.liu.se/c/pikestyle.html

33 points by twampss 17y ago

"Errors cannot be avoided by recipe. If they could, we could eliminate automobile accidents by plastering the countryside with Drive Carefully signs!" -- Andrew Koenig, _C Traps and Pitfalls_ Some of the article's examples come straight from that book, BTW.

smhinsey 17y ago
is that quote meant seriously? certainly it's obvious that the analogy doesn't work. we do have signs plastered around the countryside that are recipes for driving, they just actually include the ingredients. i would think the same applies to code, but rather than recipes, to hold the analogy, you are providing templates for recipes, or maybe style guides for writing recipes. (bad analogy, imho.)
- silentbicycle 17y ago
  More like listing mistakes to watch for. I was mostly posting to note that the book was a much more in-depth collection of same.

windsurfer 17y ago

C; I <3* u;

saucetenuto 17y ago

"Since function calls usually take a long time, getchar is often implemented as a macro." And then I stopped reading. Does anyone know of a meaning for this sentence that's more sophisticated than "function call overhead is punishing, don't call functions if you can help it", advice that was out of date when C was /invented/, for God's sake? Something special about getchar(), maybe?

spc476 17y ago
getc() and putc() can be implemented as macros in standard C (although a non-macro version needs to be supplied as well), so I think the author was trying to explain why getc() may appear slower in some circumstances than others. Of course, nowadays, it would be difficult to measure the difference between a macro getc() and a function getc().
visitor4rmindia 17y ago
Um...function calls do have an overhead. Yes it is negligible in most cases but it certainly made a difference when C was invented. In fact, C++ still carries the "inline" declaration around to avoid function call overhead. The compiler can ignore when knows better but the fact that inlining exits implies that function call overhead is not imaginary.
silentbicycle 17y ago
Generally, function call overhead is absolutely worth the added ability to abstract, but adding that overhead per character in all IO operations adds up quickly. Getchar is often the innermost loop of IO-bound processing, so inlining it (in this case, by making it a #define macro) is worth doing as a special case.

jonke 17y ago

This is like a never ending issue. One way to start the path to a better practice of C is to read http://www.amazon.com/Expert-Programming-Peter-van-Linden/dp/0131774298 http://www.amazon.com/Expert-Programming-Peter-van-Linden/dp... after you finished http://www.amazon.com/Programming-Language-Prentice-Hall-Software/dp/0131103628 http://www.amazon.com/Programming-Language-Prentice-Hall-Sof...

philwelch 17y ago

I like how gets() and scanf() are both considered unsuitable for use. There's something wrong with a language when you can't trust the standard library's input functions, and I say this as someone who rather likes C in the right context. Where's the mention of the three-argument main() variation? (int argc, char argv, char env)? Is this not standard?

sb 17y ago

just for the record: i always found rob pike's advice on c programming very thoughtful and readable (and, common: he should know ;) http://www.lysator.liu.se/c/pikestyle.html http://www.lysator.liu.se/c/pikestyle.html