A physical organization of the code. Is there a established practice (in the scope of all projects or within a single project) regarding the following:
- project source tree;
- consistent file naming;
- rules for putting classes and functions into one file (a file pair (hpp/cpp) to be more precise);
- rules for naming and formatting (style guide, clang-format);
- parameter ordering (e.g. input, then output);
- code documentation requirements.
What about the following:
- unit tests;
- practice for manual testing in cases where automatic testing is not applicable (is there a separate QA engineer?);
- integration test to test the whole project (if applies);
- external tools like static analyzers and sanitizers (aka dynamic analyzers);
- fuzzing;
What the process of code review looks like?
- What are the compilers and C++NN versions?
- What build systems are used and what is the CI infrastructure?
- what are supported OS?
What VCS is used? What is the "branching" strategy or what is instead of it?
- How dependencies between own libraries (if reuse is possible) are handled?
- How dependencies on 3rd-party libraries are handled?
- The procedure for introducing a new 3rd-party library to a pool of used 3rd-party packages?
- Rules for how to keep dependencies physically (wherein a source tree or using package managers like Vcpk or Conan), and how to build them and how to introduce dependencies to a project?
- What is the approach for releases?
Is all the software a matter of internal usage? Or it might be considered for delivery to an external party (in binaries in sources)?
What does the management process look like?