我一直在Java / J2ee项目中工作,我遵循Maven结构。 我想在C中开发[在linux {ubuntu}中说一个命令行解释器]。 我从不用C开发项目。我想知道我应该遵循什么样的项目结构。
答案 0 :(得分:10)
在这方面,C项目没有一个“标准”。当然,如果您的项目很小,那么通常所有内容都将放在一个目录中。
您可以尝试下载一些流行的开源C项目并查看他们的代码。
在较低级别,代码应该是模块化的。每个模块(在C中通常表现为具有一组作用于其上的函数的数据结构)具有其自己的.h和.c文件对,.h文件是公共接口,对于客户端可见。模块,.c文件是私有实现。
答案 1 :(得分:8)
正如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目录中。
答案 2 :(得分:6)
模块中的单独功能:带有实现细节/定义的.c文件与带声明的.h文件配对。
尽量不要使用静态函数和外部符号的公共模块前缀来污染名称空间。
如果您具有可以封装和重用的功能,请创建库。
答案 3 :(得分:5)
建议:
/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并在线浏览项目结构。
答案 4 :(得分:3)
您可以参考OpenSSL项目结构。它是一个着名的开源,具有良好的项目结构。