How do you ensure that you as programmer have writ

问题:

I m looking to write some quality C code. Can someone point me to some articles , websites..whatever I need something with examples. I have already seen and read K&R C book.

But times have changed, some one must have more to say on quality C Code. and another important thing is How do you ensure that you as programmer have written quality C code??

回答1:

Someone mentioned some compiler switches, but having syntactically smooth code is not going to ensure a quality end-product, because there's more to software quality than that.

There are several classifications of software qualities, but here's a list that you can use as a checklist:

• Correctness (does it work according to spec?)
• Reliability (can de user depend on it?)
• Robustness (does it work in unexpected situations?)
• Performance (does it do the job fast enough for the user?)
• Usability (is it user-friendly?)
• Verifiability (can its properties be verfified easily?)
• Maintainability (can modifications be made easily?)
  • Repairability (can defects be fixed within reasonable time?)
  • Evolvability (can new functionality be added simply?)
• Reusability (can the code easily be used in other projects?)
• Portability (can it run easily in different environments?)
• Understandability (can maintainers easily understand it?)
• Interoperatability (how well does it cooperate?)
• Productivity (efficienct and performant delivery)
• Timeliness (ability to deliver on time)
• Visibility (are all steps documented clearly?)

回答2:

Enable warnings in your compiler. With gcc, I use these flags:

-std=c99 -pedantic -Wall -Wextra -Werror -Wmissing-prototypes
-Wmissing-declarations -Wshadow -Wpointer-arith -Wcast-align -Wwrite-strings
-Wredundant-decls -Wnested-externs -Winline -Wno-long-long -Wconversion
-Wstrict-prototypes

If your code can't be changed to not produce warnings, drop the -Werror or don't use the specific flag producing the warning.

回答3:

Traditionally, people have used lint to help out with this.

回答4:

There are a lot of aspects for quality of code and tons of articles, books, blogs

but I can advice you this ones as beginning:

Code complete

Code secure

回答5:

Use a static analysis tool, traditionally called lint, however I've used splint which is good. See recommendations in this question. Personally I'd recommend enabling warnings and fixing them.

In terms of the rules

• Do not trust input data - validate everything, size, type, content.
• Protect against buffer overruns - strcat and many others aren't safe.
• Do use unit testing,ddj article.
• Do get your code reviewed by someone else
• Do not make assumptions.
• Do keep functions short, and test each one thoroughly.
• Use meaningful names.
• Write readable code.
• Don't be lazy - if you need to change a something to make it more meaningful then do it sooner rather than later.

Edit: Specific to C, this list of C gotchas is essential reading, and even though it is for C++ it is worth going through the CERT C++ Secure Coding Standard

回答6:

A previous discussion, what-are-some-good-resources-for-learning-c-beyond-kr, might point to more (books) examples.

回答7:

It's tough to see for your own self whether or not you are writing quality code, sure there's tons of automation and standards out there, but how can one apply everything they've seen out there?

This is where I'm a big fan of peer review as a method of judging code quality. Let other see (and also learn) from your code and that'll be the judge of quality.

回答8:

People have so far mentioned tools. However, beyond a certain point, there is really only one thing you can do to really improve the quality of the code you write:

Write code.

回答9:

Write unit tests!

It might be a bit more cumbersome to write unit-tests in C compared to more modern languages, but it is still very much worth it.

I would say that proper unit tests are the #1 way to ensure the quality of any code. You can use all the static analysis tools and code reviews you want, but nothing beats actually running the code and verifying the results.

回答10:

It depends in part on what you mean by 'quality C' code.

One important aspect of the program is "does it do what it was designed to do"? That is hard to measure, but is crucial.

Then you need to know whether the code is acceptable to compilers - using the set of GCC compiler options provided by Cristoph would indicate that the code is in good shape. (Although I would quibble over -Wno-long-long, that depends on where your code might need to be be moved to).

The code layout is important. Is the code readable by humans as well as compilers? Is the layout uniform? Is it in one of the standard formats - there are several, all with major followings, and as long as you use one of them consistently, the code should be fine. Is it appropriately commented? That means enough comments, but not too many! The file should have a header comment indicating what's in it - and probably who wrote it, and maybe the licence under which it is distributed. There have been multiple questions on SO about that, including Professional #include comments. Writing code to a good layout standard is routine after a short time, though.

Documentation may be relevant - usually is relevant. How would someone else know that the code exists, what it does, how to use it, when to use it, when not to use it?

The code should be written with good enough algorithms - it should not use exorbitant amounts of memory, disk, or CPU time. It should also not leak resources. There's also no point in wringing the last CPU cycle of performance enhancement out of a routine that will be used once per run of a program, for a few milliseconds, when it starts up, unless you can demonstrate that it is a performance bottleneck for the program as a whole.

Wouter van Nifterick has given an excellent set of pointers too.

回答11:

Some modern software lifecycle practices that enforce quality of code:

• integration tests (planned at project startup)
• peer reviews of code (during development)
• pair programming (during development)
• the use of consolidated libraries (instead of a 'reinventing the wheel' approach)

The latter one may in particular apply to the C language.