构建C代码的提示/资源？ [关闭]

Posted 2021-05-05

有没有人有关于如何以最佳方式构建C代码项目的提示/资源？ （不同的文件夹等）你怎么知道何时将代码分成单独的文件是好的？什么是一个好的Makefile的例子？

我的项目不是那么大，但我想在早期开始构建我的代码..

答案

构建代码需要一些经验，但主要是常识。

对于拆分代码，通常需要考虑可读性：概念上连贯的函数/数据类型应该放在同一个文件中。您可以将c标准库作为一个很好的例子。最好将数据结构定义和函数声明保存在单独的头文件中。这允许您将数据结构用作编译单元的一部分，即使您尚未定义所有函数。

提供类似功能的文件应位于同一目录中。避免深度目录结构（1级深度最好）是很好的，因为这会不必要地构建项目变得复杂。

我认为Makefiles适用于小型项目，但对于大型项目则变得笨重。对于非常认真的工作（如果您想分发代码，创建安装程序等），您可能需要查看cmake，scons等。

看看GNU编码标准：http://www.gnu.org/prep/standards/standards.html

查看gnu make手册，了解一个简单的Makefile示例。您还可以选择任何开源项目并查看Makefile。浏览sourceforge.net中的代码存储库可能很有用。

另一答案

阅读互联网上提供的众多C编码标准之一，并按照符合您要求的标准进行操作。一些链接：

• GNU Coding Standards
• C Coding Standards at IRAM（pdf）
• Indian Hill C Style and Coding Standards

以下书籍还包含有关编写优秀C代码的有效指南：

• The C Programming Language
• The Practice of Programming
• The Elements of Programming Style

另一答案

这有时会被忽视，但安全性是大项目中的一个问题。这里有一些关于如何program securely的建议。

另一答案

这是我喜欢的成语：

在标头中声明structs，以便客户端代码知道它们的大小。然后将init和deinit函数声明为以下约定：

• 第一个参数是struct foo*。
• 返回类型是struct foo*。
• 如果它们可能失败，那么最后一个参数是int*（最简单），enum foo_error*（如果调用代码可能有多种方法可能会失败）或GError**（如果你正在编写GLib风格的代码）。

如果第一个参数是foo_init()，foo_deinit()和NULL返回NULL。他们还返回第一个参数。

为什么这样？调用代码不必为结构分配堆空间，它可以放在堆栈上。但是，如果要在堆上分配它，则以下方法可以很好地工作：

struct foo* a_foo = foo_init(malloc(sizeof(*a_foo)));
if (a_foo == NULL) {
  /* Ruh-oh, allocation failure... */
}
free(foo_deinit(a_foo));

即使a_foo == NULL被称为foo_deinit，一切都很好。