isocpp / isocpp/CppCoreGuidelines
header, cpp file and namespace structure / library organisation
Open
@cubbimew is already working on this.
Since Oct 11, 2018.
deferred
- Dominant language
- CSS
- Stars
- 45.3k
- Forks
- 5.6k
- PR merge metrics
- No merged PRs in 30d
Description
This partly overlaps with #497, but imo it's broader, so opening another issue.
I wonder whether it would make sense to make guidelines for structuring the headers and cpp files of libraries. For instance currently
- the stl has toplevel headers (
<vector>), but astd::namespace - opencv uses
<opencv2/core/mat.hpp>and<opencv2/core.hpp>, and acv::namespace - qt uses toplevel
<QString>but alternatively also<QtCore/QString>, and theQprefix (the prefix afaik for historical reasons)
Imo there should be guidelines for:
- Where to put the header files (top directory (stl) vs. library dir (opencv)? That's mainly a packaging and project setup thing, but why not provide guidelines?
- Should there be a general namespace for the company, or the library? Should it be long and descriptive or short (2-3 letters)?
- How to organise functionality?
3.1 Should namespace names follow the directory structure?
3.2 When should i put a group of classes into a subdirectory?
3.3 When should i use namespaces, separate classes or subclasses? - Build systems, specifying that there should be no conflicts when building two .cpp files with the same name but a different path (out of scope?)
Examples for 3.:
- Say, i have an abstract base class and many derived classes. Should the derived classes go into a subdirectory? What about the base class? What about naming? E.g. for shapes, should it be "abstract_shape, circle_shape, triangle_shape, etc.", "shape, circle, triangle", or rather "shape::base, shape::circle, shape::triangle" etc with a namespace and directory shape? There are implications for instance for code completion (when typing I don't remember which shapes exist and which not, I'd like to have suggestions).
- Say i have building blocks, each with certain repetitive classes "shape::object, shape::settings, shape::factory etc.". Should there be a namespace shape as in the example, separate classes "shape, shape_settings, shape_factory etc.", or subclasses of shape "shape, shape::settings, shape::factory etc."?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.