我一直从事Java/J2ee项目,其中我遵循Maven结构。 我想用 C 开发[比如 linux {ubuntu} 中的命令行解释器]。 我从来没有用 C 开发过项目。我想知道我应该遵循什么样的项目结构。
C 项目在这方面没有一个“标准”。当然,如果您的项目很小,那么通常所有内容都会放在一个目录中。
你可以尝试下载一些流行的开源C项目并看看他们的代码。
在较低的层面上,代码应该是模块化的。每个模块(在 C 中通常表现为一个数据结构,并具有一组对其进行操作的函数)都有自己的一对 .h 和 .c 文件,其中 .h 文件是该模块的客户端可见的公共接口。模块,.c 文件是私有实现。
正如 Eli Bendersky 所说,这严格取决于您的项目的复杂程度。
该标准建议尽可能多地分成库。关键是您可能想在其他地方重用您的库。例如,这是我的一个项目:
├── AUTHORS
├── COPYING
├── ChangeLog
├── Makefile.am
├── NEWS
├── README
├── configure.ac
├── libs
│ ├── featsel
│ │ ├── Makefile.am
│ │ ├── commander.c
│ │ ├── featsel
│ │ │ ├── commander.h
│ │ │ ├── feattuple.h
│ │ │ └── types.h
│ │ ├── featsel.h
│ │ ├── feattuple.c
│ │ ├── headers
│ │ │ └── datatypes.h
│ │ └── tests
│ │ ├── Makefile.am
│ │ └── test00.c
│ ├── mbox
│ │ ├── Makefile.am
│ │ ├── README
│ │ ├── control.c
│ │ ├── error.c
│ │ ├── headers
│ │ │ ├── datatypes.h
│ │ │ ├── mail.h
│ │ │ ├── parse.h
│ │ │ ├── split.h
│ │ │ └── strings.h
│ │ ├── interface.c
│ │ ├── mail.c
│ │ ├── mbox
│ │ │ ├── descriptor.h
│ │ │ ├── error.h
│ │ │ ├── mail.h
│ │ │ └── types.h
│ │ ├── mbox.h
│ │ ├── parse.c
│ │ ├── split.c
│ │ └── strings.c
│ └── thread_queue
│ ├── Makefile.am
│ ├── thrdqueue.c
│ └── thrdqueue.h
├── reconf
└── src
├── Makefile.am
└── main.c
我个人更喜欢将所有库放入
libs
目录中。除了普通库之外,每个库都有自己的私有头目录,并通过与库同名的目录导出公共头。
程序本身的源文件放在src目录下。
建议:
/project
README
LICENCE
Makefile
# mabe configure.am Makefile.am etc.
# see http://en.wikipedia.org/wiki/GNU_build_system
/src
Makefile
a.h
a.c
b.h
b.c
/subunit
x.h
x.c
y.h
y.c
# each file.c has a header file.h but not necessarily
...
查看github上的Nginx,在线浏览项目结构。
模块中的独立功能:具有实现细节/定义的 .c 文件与具有声明的 .h 文件配对。
尽量不要通过使用静态函数和外部符号的公共模块前缀来污染名称空间。
如果您有可以封装和重用的功能,请创建库。