我什么时候将我的项目拆分为多个 C 文件?(大型项目的良好做法) [英] When do I split my project to multiple C files? (good practices for large projects)

问题描述

我现在正在用 C 做一个大项目，我在做其中的一个特定部分(另一个是别人做的)，我想知道我的项目什么时候应该拆分成多个 C 文件，什么是最好的与团队(或单独)一起编写大型项目的实践.我以前的经验是使用标题(有一个标题和一个 .c，其中所有功能都在书面).

Im working on a big project in C right now, im doing a specific part of it (the other is done by others), I want to know when should my project be split into multiple c files, and what are the best practices for writing large projects, with a team (or alone). My previous experience was with headers (having a header and a .c where all the functions were written).

推荐答案

人们会告诉你不同的事情.一般:

People will tell you different things. In general:

• 如果出现以下情况，您应该将文件拆分为较小的文件:
  • 它有很多依赖
  • 编译时间过长
  • 它知道或做得太多
  • 哪些部分适用于哪些类型的数据
  • 哪些部分与项目的哪些其他部分一起工作
  • 仅在包含在特定订单中时才有效的标题
  • 包含大量项目的标头(依赖项太多)
  • 滥用预处理器宏
  • util.c"或类似的.根据个人经验，他们往往会失控

  在 C++(不是 C)中，我倾向于为我编写的每个主要类都有一个 .h 和 .cpp 文件，有时我可能会将一些支持类与其他类非常相关地合并到文件中，并且没有它们，它们或多或少毫无意义(有趣的是，我有一个中等项目，在同一个文件中包含诸如 Scheduler 和 SchedulerEvent 之类的类，其中一个 Scheduler 保存了 SchedulerEvents 的集合.该项目有大约 180 个文件，仍然易于维护).

  In C++ (not C), I tend to have a .h and .cpp file for each major class I write, and I may sometimes lump some supporting classes into files with other classes to which they are very closely related, and without which they are more or less meaningless (anecdotally, I have a medium project containing such classes as Scheduler and SchedulerEvent in the same file, in which a Scheduler holds a collection of SchedulerEvents. The project has around 180 files and is still easy to maintain).

  这篇关于我什么时候将我的项目拆分为多个 C 文件?(大型项目的良好做法)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！