C头文件和源文件的标准结构

我在想这样的事情（例如对于C源文件）：

 // static variables
 // public variables
 // static methods
 // public methods

来源

2010-07-01 kmalmur

你通常不会把静态的头文件为静态的意思是“可见只有这个编译单元”，和C不具有“公共” '方法' - 你确定你不是在谈论C++吗？上面的例子是 – 2010-07-01 09:00:02

是* .c文件。通过公共方法，我的意思是在头文件中声明的方法。一般来说，没有在头文件中声明的每个方法都应该是静态的，所以粗略地说，“公共方法”是“非静态方法” – kmalmur 2010-07-01 09:08:00

我不认为有“标准”;它是一个编码标准/建议，在你的情况下它是一个好的（对于C源文件） – INS 2010-07-01 11:27:42

这是一个完全主观的问题。但是，这是我的工作。

页眉：

// extern defines, constants and enums 
// public types 
// extern methods

没有的extern变量:-)

编制单位：

// includes 
// definitions for extern constants 
// static function prototypes 
// everything else

我倾向于认为是相关的一起群体的事情，所以我不严格把所有的静态变量或定义在oner的地方，但接近他们将要使用的地方。

来源

2010-07-01 12:45:06 JeremyP

您所使用的结构是好的。

最佳做法是关于命名公共变量和公共方法，前缀与产品名称/公司名称相同，以避免与其他库命名冲突。

来源

2010-07-01 08:59:30 Ramakrishna

考虑到这是一个C的问题，我相信：

// static variables 
// public variables 
// static methods 
// public methods

...含义：

// static variables 
// public variables (external linkage) 
// static functions 
// public functions

至于顺序，我不认为你能唤起什么，但一个对此的主观反应。除非您询问特定组织的编码标准，否则它肯定不是标准化的，在这种情况下，他们可能会制定相关政策。有些人可能更喜欢在公共场合下私人，其他人则可以在私人之前公开。有些人可能会先强调一个人对另一个人的重要性，而另一些人则可能会强调重要性高于其前任。关于这些风格偏好并没有一致的协议，并且它们对代码或其运行时行为没有逻辑影响。

重要的是保持一致，我建议避免任何非常奇特的事情，因为它会吓跑其他需要查看代码的开发人员。如果你想与其他工程师合作，那么异国情调的风格通常很糟糕。越是异国情调的风格越是独特，他们越需要别人适应个人喜好。

是否试图减少与外部链接（全局变量）的公共变量的数量。尽管听起来有点小差异，但编写一个公共函数来获取变量是一个很大的进步，即使它是简单的getter型函数，它会返回一个指向变量的指针，因为它至少会允许您修改代码是否有必要进行更改，还允许您在任何访问的位置轻松放置断点，将功能添加到该功能等。

来源

2010-07-01 09:15:52 stinky472

我通常使用对C以下：

// include guard 
#ifndef <filename>_H 
#define <filename>_H 

// define this as extern for c++ 
#ifdef __cplusplus 
extern "C" { 
#endif 

#include <libraries> 
#define <preproc variables> 
#define <preproc macros> 

enum <enums> { 
}; 

typedef <variables>; 
typedef <structs>; 

function prototypes(); 

// end c++ guard 
#ifdef __cplusplus 
} 
#endif 
// end include guard 
#endif

来源

2010-07-01 13:51:50

C头文件和源文件的标准结构

回答

相关问题