Slashdot Mirror
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."
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.
-
ping -f 255.255.255.255 # if only
If you reply, do so only to what I explicitly wrote. If I didn't write it, don't assume or infer it.
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.Programming can be fun again. Film at 11.
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++.
Apparently it was too obfuscated for IBM. The first code example is missing a } at the end of the line.
=================
Unix is very user friendly, it's just picky about who its friends are.
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.
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.
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.
C++ is effectively a super-set of C, though not a strict superset of C.
Good enough for you?
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.
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.
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.
A classic