Coding guidelines for CasADi
- Keep a clear separation between public classes and internal classes. Public classes should be interfaced to SWIG/Python.
SXElement should be avoided in examples and tutorials in favor of
SX too keep the number of new concepts introduced to users low.
MX should mirror
SX as close as possible
- This is why indexing into
SX returns a 1x1 matrix, rather than
SX. The same holds for
- The mapping from CasADi C++ to a hosted language should be close to 1-to-1
- No external dependencies are allowed in the core
- There is one exception to this rule: OpenCL is now an optional dependency
- CasADi should throw helpful and information-loaded error messages for new/confused users
- E.g. When multiplying matrices of unequal size
RuntimeError: matrix_matrix: dimension mismatch.
Left argument has shape (2 x 2 = 4 | 4), right has shape (5 x 5 = 25 | 25)
- CasADi uses the following naming conventions:
- Non-public data members should have lower-case names and end with underscore "_"
- Public data members should have lower-case names
- Local variables have lower-case names, this includes function arguments
- Classes use
- Function (member functions and other) have lower-case names
- Abreviations "QP", "NLP" etc. are written in upper-case
- Constants are written in
- Options using the
OptionsFunctionality class are written in lower-case
- CasADi is a C++ package, C syntax is not permitted, e.g.
- No "printf" for printing, use input/output streams
- Error handling by exceptions not return flags
- Avoid macros and defines, use typedefs and constants instead
- Use new/delete instead of malloc/free, or better avoid it altogether and use CasADi's reference counting
SharedObject internal classes must have one constructor only, use of the implicit copy constructor (and hence also operator=) is strongly encouraged
- Also have a lock at the following style guidelines