查看 GNU 编码标准： gnu.org/prep/standards/standards.html" rel="nofollow">http://www.gnu.org/prep/standards/standards.html
查看 gnu make 手册以获取简单的示例 Makefile 。您还可以选择任何开源项目并查看 Makefile。浏览 sourceforge.net 中的代码存储库可能会有用。
Structuring code needs some experience but mostly common sense.
For splitting code, you usually go for readability: conceptually coherent functions/datatypes should go in the same file. You can take c standard library as a good example. It is better to keep your data structure definitions and function declarations in separate headers. This allows you to use the data structures as part of a compilation unit even if you have not defined all the functions.
Files that provide similar functionality should go in the same directory. It is good to avoid deep directory structure (1 level deep is best) as that complicates building the project unnecessarily.
I think Makefiles are OK for small projects, but become unwieldy for bigger ones. For really serious work (if you want to distribute your code, create an installer etc) you may want to look at cmake, scons, etc.
Look at the gnu make manual for a simple example Makefile. You can also pick up any opensource project and look at the Makefile. Browsing code repositories in sourceforge.net may be useful.
Declare structs in a header so that their size is known by client code. Then declare init and deinit functions to the following convention:
The first parameter is a struct foo*.
The return type is a struct foo*.
If they might fail, the last parameter is either int* (simplest), enum foo_error* (if there are several ways it can fail that the calling code might care about) or GError** (if you're writing GLib-style code).
foo_init() and foo_deinit() return NULL if the first parameter is NULL. They also return the first parameter.
Why do it this way? Calling code doesn't have to allocate heap space for the structure, it can go on the stack. If you are allocating it on the heap, though, the following works nicely:
发布评论
评论（4）
构建代码需要一些经验，但主要是常识。
对于拆分代码，您通常会追求可读性：概念上一致的函数/数据类型应该放在同一个文件中。你可以把c标准库作为一个很好的例子。最好将数据结构定义和函数声明保存在单独的标头中。即使您尚未定义所有函数，这也允许您将数据结构用作编译单元的一部分。
提供类似功能的文件应位于同一目录中。最好避免较深的目录结构（最好是 1 级），因为这会使项目的构建变得不必要的复杂化。
我认为 Makefile 对于小型项目来说还可以，但对于大型项目来说就变得笨拙了。对于真正严肃的工作（如果您想分发代码、创建安装程序等），您可能需要查看 cmake、scons 等。
查看 GNU 编码标准： gnu.org/prep/standards/standards.html" rel="nofollow">http://www.gnu.org/prep/standards/standards.html
查看 gnu make 手册以获取简单的示例 Makefile 。您还可以选择任何开源项目并查看 Makefile。浏览 sourceforge.net 中的代码存储库可能会有用。
Structuring code needs some experience but mostly common sense.
For splitting code, you usually go for readability: conceptually coherent functions/datatypes should go in the same file. You can take c standard library as a good example. It is better to keep your data structure definitions and function declarations in separate headers. This allows you to use the data structures as part of a compilation unit even if you have not defined all the functions.
Files that provide similar functionality should go in the same directory. It is good to avoid deep directory structure (1 level deep is best) as that complicates building the project unnecessarily.
I think Makefiles are OK for small projects, but become unwieldy for bigger ones. For really serious work (if you want to distribute your code, create an installer etc) you may want to look at cmake, scons, etc.
Have a look at the GNU coding standards: http://www.gnu.org/prep/standards/standards.html
Look at the gnu make manual for a simple example Makefile. You can also pick up any opensource project and look at the Makefile. Browsing code repositories in sourceforge.net may be useful.
阅读互联网上提供的众多 C 编码标准之一，并遵循看起来合理且符合您要求的标准。一些链接：
以下书籍还包含编写良好 C 代码的有效指南：
Read one of the many C coding standards available on the internet and follow one that looks reasonable for your requirements. A few links:
The following books also contain effective guidelines on writing good C code:
这有时会被忽视，但安全性是大型项目中的一个问题。以下是有关如何安全编程。
This is sometimes overlooked, but security is an issue in big projects. Here's some advice about how to program securely.
这是我喜欢的一个习惯用法：
在标头中声明 struct ，以便客户端代码知道它们的大小。然后按照以下约定声明 init 和 deinit 函数：
struct foo*。int*（最简单）、enum foo_error*（如果调用代码可能关心多种可能失败的方式）或GError**（如果您正在编写 GLib 风格的代码）。如果第一个参数为
NULL，则foo_init()和foo_deinit()返回NULL。他们还返回第一个参数。为什么要这样做呢？调用代码不必为结构分配堆空间，它可以进入堆栈。但是，如果您在堆上分配它，则以下内容可以很好地工作：
即使调用
foo_deinit时a_foo == NULL，一切都可以很好地工作。Here is an idiom I like:
Declare
structs in a header so that their size is known by client code. Then declare init and deinit functions to the following convention:struct foo*.struct foo*.int*(simplest),enum foo_error*(if there are several ways it can fail that the calling code might care about) orGError**(if you're writing GLib-style code).foo_init()andfoo_deinit()returnNULLif the first parameter isNULL. They also return the first parameter.Why do it this way? Calling code doesn't have to allocate heap space for the structure, it can go on the stack. If you are allocating it on the heap, though, the following works nicely:
Everything works nicely even if
a_foo == NULLwhenfoo_deinitis called.