关于在 C++ 应用程序中组织代码，没有广泛接受的规则。例如，我更喜欢使用命名空间，为每个命名空间创建一个单独的文件夹，并将与该命名空间相关的所有标头和源放入相应的文件夹中，因此项目根目录仅包含带有 main()、makefile 的文件，可能还包含其他几个文件。然而，其他人可能有不同的偏好。
There are no widely-accepted rules about organising the code in a C++ app. I, for example, prefer using namespaces, creating a separate folder for each namespace and putting all the headers and sources related to that namespace into the corresponding folder, thus the project root contains only the file with main(), makefile, and possibly a couple of other files. However, others might have different preferences.
I'd suggest taking, for example, a look at Google Chrome's source code. It is large, but since Google made it, and I believe they do take coding standards seriously, it can't be bad to explore a bit.
IDE: this won't be a show-stopper, but still could decide number 2.
Is it a GUI or console only or library project: this will IMO force your to structure your program differently, especially if you obey the unspoken rule of splitting GUI and "processing" functions. A library will need a nice API header set, where another (non-library API bound) project will let you be free in that regard.
What do you think is best? If you don't feel right in a certain set-up, don't use it and refactor (if it doesn't take all your time of course...
I have just started a humble C++ project, with a small platform abstraction layer, maybe that can give you some hints/suggestions. Source code is viewable here (it is quite nonfunctional now and uses qmake to build): http://sourceforge.net/p/ambrosia/git -> browse
What I did: - One platform abstraction header which provides platform-independent function definitions which are implemented in (currently) one source file per platform. - One global header including several headers which contain stuff needed virtually everywhere. - Some subfolders logically organized per goal of the code.
Generally, the first thing to do before you start coding is decide on naming conventions. Variable names, class names, namespaces, method names etc. Then you have to decide the separation of the code in header files and cpp files and the directory they will reside (same dir or different). The directory names should be meaningfull (more conventions here) i.e. a class that offers utility methods used by many components should be placed in the subdirectory e.c. /common or /util. You should decide on versioning system e.g. clearcase. Also a very important point (IMHO) is how the logging is done. This must be implemented and consistent to all modules. These are strong points to focus, as in studying a ready project, may be time consuming, since you have to study it quite a bit, to notice all the convention and underlying relation of code. Additionally you would not know why one convention was preferred over another.
发布评论
评论（5）
关于在 C++ 应用程序中组织代码，没有广泛接受的规则。例如，我更喜欢使用命名空间，为每个命名空间创建一个单独的文件夹，并将与该命名空间相关的所有标头和源放入相应的文件夹中，因此项目根目录仅包含带有 main()、makefile 的文件，可能还包含其他几个文件。然而，其他人可能有不同的偏好。
There are no widely-accepted rules about organising the code in a C++ app. I, for example, prefer using namespaces, creating a separate folder for each namespace and putting all the headers and sources related to that namespace into the corresponding folder, thus the project root contains only the file with main(), makefile, and possibly a couple of other files. However, others might have different preferences.
您可以将它们放在不同的文件夹中，并使用另一个文件来获取/包含文件中的两个文件，您将使用它们作为包含。访问下面的链接，我将向您展示如何实现您自己的文件组织结构。
http://codednotes.blogspot.com/2014/01 /organising-headers-and-source-files.html
You can have the in different folders and use another file to fetch/include both files on file, which you will use as your include. Visit the link below it I show you how to implement your own file organization structure.
http://codednotes.blogspot.com/2014/01/organising-headers-and-source-files.html
Google 的 C++ 风格指南。
例如，我建议查看 Google Chrome 的源代码。它很大，但既然 Google 创造了它，而且我相信他们确实认真对待编码标准，所以探索一下也不错。
Google's C++ style guide.
I'd suggest taking, for example, a look at Google Chrome's source code. It is large, but since Google made it, and I believe they do take coding standards seriously, it can't be bad to explore a bit.
这主要取决于以下几件事：
我刚刚开始了一个简陋的 C++ 项目，带有一个小型平台抽象层，也许可以给你一些提示/建议。源代码可以在这里查看（它现在非常不起作用，使用 qmake 来构建）： http://sourceforge.net/p/ambrosia/git -> 浏览
我做了什么：
- 一个平台抽象标头，提供独立于平台的函数定义，这些定义在（当前）每个平台的一个源文件中实现。
- 一个全局标头，包括多个标头，其中包含几乎所有地方都需要的内容。
- 一些子文件夹按照代码的目标进行逻辑组织。
This is mostly dependent on a couple of things:
I have just started a humble C++ project, with a small platform abstraction layer, maybe that can give you some hints/suggestions. Source code is viewable here (it is quite nonfunctional now and uses qmake to build): http://sourceforge.net/p/ambrosia/git -> browse
What I did:
- One platform abstraction header which provides platform-independent function definitions which are implemented in (currently) one source file per platform.
- One global header including several headers which contain stuff needed virtually everywhere.
- Some subfolders logically organized per goal of the code.
一般来说，开始编码之前要做的第一件事是决定命名约定。
变量名、类名、命名空间、方法名等
然后你必须决定头文件和 cpp 文件中的代码以及它们将驻留的目录（相同目录或不同目录）。
目录名称应该是有意义的（这里有更多约定），即提供许多组件使用的实用方法的类应该放置在子目录 ec /common 或 /util 中。
您应该决定版本控制系统，例如clearcase。
另外一个非常重要的点（恕我直言）是如何完成日志记录。这必须实现并与所有模块保持一致。
这些都是需要重点关注的要点，因为在研究一个现成的项目时，可能会很耗时，因为您必须对其进行大量研究，以注意到代码的所有约定和底层关系。此外，您不会知道为什么一种约定优于另一种约定。
Generally, the first thing to do before you start coding is decide on naming conventions.
Variable names, class names, namespaces, method names etc.
Then you have to decide the separation of the code in header files and cpp files and the directory they will reside (same dir or different).
The directory names should be meaningfull (more conventions here) i.e. a class that offers utility methods used by many components should be placed in the subdirectory e.c. /common or /util.
You should decide on versioning system e.g. clearcase.
Also a very important point (IMHO) is how the logging is done. This must be implemented and consistent to all modules.
These are strong points to focus, as in studying a ready project, may be time consuming, since you have to study it quite a bit, to notice all the convention and underlying relation of code. Additionally you would not know why one convention was preferred over another.