正在使用#include"部件.c"；被认为是不良行为，还是有任何违反misra标准规则的行为？(潜在规则3-3-1)
到目前为止，据我所知，这通常被归类为不良做法，但可以用于某些场景，这对安全关键型应用程序有什么特别的担忧吗？
Misra规则3-3-1规定，具有外部链接的对象或功能应在头文件中声明
当您编写这样的程序时，它被称为统一构建。这种程序的一个很好的例子是Odin编程语言的编译器。所以这是可以做到的，但和其他任何事情一样，也有权衡。
专业人士
-
它将更多的源放入一个翻译单元中。这可以帮助优化，类似于链接时间优化的工作方式，因为编译器实际上可以从其他C文件中的函数中看到源代码。
-
减少项目文件中的混乱(减少标题)，从而减少重复。
-
大大简化的结构；即使项目中有多个文件，也可以像只构建一个文件一样简单。
缺点
-
对于使用更常见做法的同事来说，更难理解。
-
您不能再在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"部件.c"；被认为是不良做法
一般来说，是的。
通常，预处理器的文件包含功能是保留的，以支持将公共声明分解到它们自己的文件中，这样它们就不需要在多个源中重复。这种分解为除最小项目外的所有项目的可维护性提供了巨大的好处，而且它几乎是库可用性的要求。只包含这种声明的文件通常被称为"文件"；标题"；，并且通常用CCD_ 1后缀来命名。从这个意义上说，问题的一部分是关于文件命名和编程模式。
另一方面，包含函数或对象定义(与声明相反)的C源文件通常使用.c后缀命名。C语言禁止在同一程序中对同一标识符(函数或变量名)进行多个外部定义，因此此类.c文件不能被#included转换为对一个程序有贡献的多个翻译单元，如果它们被包括在一个翻译单元中，则它们也不能直接编译。从多个.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删除了此规则，以允许使用.h0函数。
--
就我个人而言，我认为#include创建.c文件是个坏主意——这表明对语言、编译器和链接器的理解有误。
如果这样做，出于分析目的，展开的文件将被视为单个翻译单元。。。
(参见附属公司简介)