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?)
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.
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:
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.
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.
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.
发布评论
评论（9）
有人提到了一些编译器开关，但拥有语法流畅的代码并不能确保最终产品的质量，因为软件质量远不止于此。
软件质量有多种分类，但这里有一个列表可以用作检查表：
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:
在编译器中启用警告。 对于 gcc，我使用这些标志：
如果您的代码无法更改为不产生警告，请删除
-Werror或不使用产生警告的特定标志。Enable warnings in your compiler. With gcc, I use these flags:
If your code can't be changed to not produce warnings, drop the
-Werroror don't use the specific flag producing the warning.传统上，人们使用 lint 来帮助解决这个问题。
Traditionally, people have used lint to help out with this.
使用静态分析工具，传统上称为 lint，但我使用了 splint ，这很好。 请参阅此问题中的建议。 我个人建议启用警告并修复它们。
就规则而言，
编辑：
具体到 C，这个 C 陷阱 列表是必不可少的阅读内容，即使它是针对 C++ 的，也值得浏览 CERT C++ 安全编码标准
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
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
到目前为止，人们已经提到了工具。 然而，超出某一点，实际上只有一件事可以真正提高您编写的代码的质量：
编写代码。
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.
编写单元测试！
与更现代的语言相比，用 C 编写单元测试可能有点麻烦，但仍然非常值得。
我想说，适当的单元测试是确保任何代码质量的第一方法。 您可以使用您想要的所有静态分析工具和代码审查，但没有什么比实际运行代码并验证结果更好的了。
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.
这部分取决于“优质 C”代码的含义。
该程序的一个重要方面是“它是否达到了设计目的”？ 这很难衡量，但却至关重要。
然后，您需要知道代码是否可以被编译器接受 - 使用 由 Cristoph 提供的一组 GCC 编译器选项 将表明代码状态良好。 （尽管我会对
-Wno-long-long争论不休，但这取决于您的代码可能需要移动到的位置）。代码布局很重要。 代码对于人类和编译器来说都是可读的吗？ 布局是否统一？ 它是否采用标准格式之一 - 有几种，都具有主要的以下格式，只要您一致地使用其中一种，代码就应该没问题。 评论是否恰当？ 这意味着有足够的评论，但不要太多！ 该文件应该有一个标头注释，指示其中的内容 - 可能还包括编写它的人，以及分发它所依据的许可证。 SO 上有多个与此相关的问题，包括专业#include 评论。 不过，按照良好的布局标准编写代码很快就会成为惯例。
文档可能是相关的——通常是相关的。 其他人如何知道该代码存在、它的作用、如何使用它、何时使用它、何时不使用它？
代码应该使用足够好的算法来编写 - 它不应该使用过多的内存、磁盘或 CPU 时间。 它也不应该泄漏资源。 将性能增强的最后一个 CPU 周期从每次运行程序时使用一次的例程中提取出来也是没有意义的，该例程在程序启动时持续几毫秒，除非您能够证明它是程序的性能瓶颈。程序作为一个整体。
Wouter van Nifterick 给出了 一组优秀的指针。
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.
很难亲自判断自己是否在编写高质量的代码，当然有大量的自动化和标准，但是如何应用他们所看到的一切呢？
这就是我非常喜欢将同行评审作为判断代码质量的方法。 让其他人看到（并学习）您的代码，这将是质量的评判。
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.
一些加强代码质量的现代软件生命周期实践：
后一种方法可能特别适用于 C 语言。
Some modern software lifecycle practices that enforce quality of code:
The latter one may in particular apply to the C language.