当你写一个这样的程序时，它被称为unity build。这样一个程序的一个很好的例子是Odin programming language的编译器。所以它可以完成，但像其他任何东西一样，有权衡。

优点

• 它将更多的源代码放入一个翻译单元中，这有助于优化，类似于链接时优化的工作方式，因为编译器实际上可以从其他C文件中的函数中看到源代码。
• 项目文件中的混乱更少（更少的标题），因此，重复更少。
• 大大简化的构建;即使项目中有多个文件，也可以像只生成一个文件一样简单。

cons

• 对于使用更常见实践的同事来说，这很难理解。
• 你不能再在C文件中用一个非常通用的名字定义一个静态变量，因为那个C文件可能是一个更大的翻译单元的一部分。
• 这通常会减慢编译速度。编译系统（如make）可以通过重新编译依赖于所有更改的内容来加快编译速度。如果您将内容组合到单个翻译单元中，则需要为每个更改构建整个内容。在大型项目中，这将导致构建期间消耗更多内存。
• 不能并行化生成。

是否违反MIRSA协议？

我不知道，但这并不违反你发布的规则：
Misra规则3-3 -1规定，具有外部链接的对象或函数应在头文件中声明
通过包含一个C文件，您知道不再有外部链接，因为它们在同一个翻译单元中。

这也是一个安全问题，您可能不想提供您的代码，所以您只给予头文件和目标文件

您引用的是MISRA C标准，而不是MISRA C标准。在MISRA C标准中，规则3-1-1不限制您将C文件包含在其他C文件中，因为任何C文件都可以包含彼此，并且不声明任何内容具有外部链接。规则/要求是关于外部链接的，不是关于C文件包含。我相信如果他们要添加一个包含其他C文件的规则，那将是在“源文件包含”规则16-2-X节下，但我刚刚检查过，没有任何关于包含其他C文件的规则。就我个人而言，我不介意包含其他C文件，因为我认为#include只是一个复制和粘贴操作，可以按照您认为合适的方式使用。

使用#include“component.c”是否被视为不良做法
一般来说，是的。
通常，预处理器的文件包含特性被保留，以支持将公共声明分解到它们自己的文件中，这样它们就不需要在多个源中复制。这种分解为除了最小的项目之外的所有项目的可维护性提供了巨大的好处，并且它几乎是库可用的要求。只包含这种声明的文件通常被称为“头”。并且通常以.h后缀命名。从这个意义上说，问题部分与文件命名和编程模式有关。
另一方面，包含函数或对象定义的C源文件（与声明相反）通常使用.c后缀命名。（函数或变量名），因此此类.c文件不能被#include转换为一个以上的翻译单元，从而为程序做出贡献，如果它们被包含在一个文件中，那么它们也不能被直接编译。从多个.c文件构建一个程序的通常方法是独立编译它们，然后将它们链接在一起。
只要确保避免重复定义，将一个#include文件转换为另一个.c文件本身并不是错误的。但这只有作为一种特殊用途的安排才有意义。它会产生额外的风险，而且就语言规范而言，它没有提供任何特别的优势。此外，由于它违背了惯例，它往往会让开发人员感到惊讶和困惑--甚至可能是更有经验的未来的您。
是否违反了misra标准规则？（可能违反了规则3-3-1）
它本身并不违反MISRA规则3-3-1，但它使编写违反该规则的代码变得不那么痛苦。这是通过将所有需要的外部声明放在单个.c文件中以及它的包含项中，而不是提供单独的头文件。
我没有看到任何其他MISRA-2012规则会被这样的包含所违反，但这在代码审查中对我来说并不成立。

规则3-1-1是MISRA C++：2008规则
适用的MISRA C：2012指南（可能）是规则20.2和20.3 -不禁止使用.c扩展。

在MISRA C：2004中，规则8.5禁止在头文件（假设是.h文件）中使用源代码。MISRA C：2012中删除了此规则，以允许使用inline函数。

就我个人而言，我认为#include-ing一个.c文件是一个坏主意-它表明了对语言，编译器和链接器的错误理解。
如果您这样做，扩展的文件将被视为一个 * 单个翻译单元 *，用于分析目的...
(see Affiliation的个人资料）