Coding style

Coding standards

• All code should be sufficiently documented; use the template for documenting the top of a function.
• Otherwise, only sparse documentation is necessary.
• Max 80 characters per line in all files (except for data). Anything wider makes remote login work difficult.
• User-facing routines should include a reasonable amount of defensive programming, e.g. using assert statements to check input.
• Unless absolutely necessary, calling sequences should not be changed for existing functions.
• Non-user-facing routines should be relegated to class folders (starting with @) or namespace folders (starting with +).
• Any chunkie routines (which are not part of external submodules, like FLAM) should be automatically visible to MATLAB once the chunkie folder is on the MATLAB path (this is accomplished for top-level files, files in the namespace folders, and files in the class folders).
• Do not create a new namespace folder. Subfolders of the existing namespaces should be sufficient.
• Do not create a new class unless that is the issue at hand.
• Code should be pure MATLAB unless there is a specific plan/need for compiled languages. Compiled code will not be considered core chunkie in any case.
• Code should represent the programmer's own original work and be releasable under the chunkie license.

Code preferences

• Tests:
  • should start with clearvars;
  • should feature an assert statement which checks correctness
  • should take a maximum of 1 minute (with exceptions)
• Code should be reasonably well optimized for the given task, employing vectorization when reasonable.
• Great care should be taken when using the implicit expansion features of MATLAB. In particular, most code should not care whether the user gives you a row or column vector for input, but implicit expansion within a function may end up treating these inputs very differently.