Development
Here are some general conventions/styles/process/design developer guidelines that are followed by the gplCAD project:
Design Considerations
- DRY principle : Don't Repeat Yourself
- Open / closed principle : Software entities should be open for extension, but closed for modification
- Layering : Systems should be divided into layers; avoid layering violations
- Abstraction : Remove dependencies between subsystems by employing abstract base classes
- Liskov substitution principle : All classes derived from a base class should be interchangeable when used as a base class
- Law of Demeter : Only use/interact with your immediate objects; avoid reaching through an object to access a subobject
- Single Responsibility Principle : Every object should have a single responsibility and it should be clearly defined.
- Dependency Inversion Principle : Depend on abstractions, not on concretions
Coding Conventions
- All code should follow the GNU coding standards. The default emacs cpp-mode indent works well. Exceptions are as follows:
- Braces { and } should not be indented
- Do not put a space between the name of a function and the opening parenthesis of its parameter list
- All code should fit within 80 columns unless absolutely unavoidable.
- Always use spaces when indenting code. TABs should never show up in the source code.
- All code should be documented using the appropriate doxygen directives.
- Contributing authors are not listed in individual source code files. The contributing authors are listed elsewhere.
- In the end, always follow the existing coding styles. Do not make up your own conventions.
Process
- Be sure to follow test driven development (TDD). All code should have appropriate unit tests (preferably written before the implementation is written).
- Always update the documentation (either code or user) as you are writing code or when you finish with a chunk of functionality.
Language Specific
- Read the C++ FAQ LITE and follow the various bits of advice.
- Read and absorb these books by Scott Meyer: "Effective C++" and "More Effective C++".
- All abstract base classes (with virtual methods) must have virtual destructors.
- Follow these guidelines when using operator overloading. No gratuitous use of operator overloading.
- All code should be const correct from the very beginning.
How to write new code or make a change
- Stub out the class definition (inside a header file)
- Write a test to exercise the code
- Add enough implementation/infrastructure to compile the test
- Run the test (and observe that it fails; it better fail)
- Add actual implementation and run test
- Iterate until the test passes
- Run all tests and make sure they still all pass
- If any test fails, stop and fix the failure before writing any new code
- Write or update existing documentation
- Verify that the code works on all supported platforms
- Commit or submit the patch with all code changes, documentation, and, of course, the unit tests
How to create a release
- Make sure all the unit tests pass
- Update any documentation (should be already done as part of development)
- Update news and change file with changes
- Write release notes
- Create tarballs, zips, and binary distributions using the appropriate mechanisms
- Create cryptographic hashes of the generated files
- Verify builds and check for missing files
- Upload generated files, hashes, and release notes