codingguidelines

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 DMatrix
• 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 CamelCase
• Function (member functions and other) have lower-case names
• Abreviations "QP", "NLP" etc. are written in upper-case
• Constants are written in UPPER_CASE
• 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