Introduction

The goal of this set of coding standards that can be automatically checked is to help you write consistent, clean, understandable and maintainable m-code. The resulting code will be more readable for both yourself and others. These rules are no strict rules that must be followed at all cost. They are simply there to help you write m-code well and you can deviate from them as you please.

Automatic compliance checking

Most of the rules described here can be checked using CC4M by MonkeyProof Solutions. The checkable rules are indicated by this logo cc4m_logo_inline at the top. These rules are configured in the predefined MonkeyProofSolutions configurations set available with the tool. For instructions on how to check your code against a coding standard, see the video below. The steps are also described below the video.

You can check your code for compliance with the rules described here as follows:

  1. Install CC4M. If you have not purchased the tool yet, you can do so here. Alternatively, you could request a free trial license there.
  2. Open CC4M in one of two ways:
    • Click the shortcut created at the top of the screen next to the documentation search bar: .
    • Run monkeyproof.cc4m.start() from the command window.
  3. Select whether you want to check one or more files, all files in a folder, or all files in a MATLAB Project.
  4. Select what files/folder/project to check.
  5. Further customization is available, for example checking a folder including or excluding all subfolders.
  6. Click the Run button at the bottom to start checking your code.

Structure of this document

The coding standards and rules are grouped under specific categories to help keep things organized:

  • Naming conventions: Rules in this chapter describe how variables, functions etc. can be named in a consistent and insightful manner.
  • Layout & comments: This chapter contains rules to help improve readability of your code for yourself and for others. There are rules on whitespace, comments and more.
  • Statements & expressions: The rules and coding standards in this chapter are about how to use constructs such as if/else blocks, what built-in functions or keywords to avoid, how to best structure your statements etc.
  • Higher level rules: This chapter contains (among others) coding standards on higher-level objects such as functions or files.
  • Security: This chapter contains rules on potential security risks.

Rule template

Every rule is structured as follows:

Rule name

IDA unique rule identifier.
TitleBrief description of the rule.
PriorityPriority of the rule can be one of Mandatory, Strongly recommended and Recommended. Exactly what each of these means for your case is up to you to decide.
Severity levelSeverity level of the rule can be in the range from 1 to 10. The most important ones are of severity level 1 and next levels are reserved for more pedantic issues. Each of the levels is described below.
DescriptionA more elaborate description of the rule. Can include the reasoning behind the rule: how does your code improve when applying the rule?
RationaleOne or multiple words describing what the rule is about. Examples: Readability, Stability.

Avoid:

One or more code examples to avoid using.

Instead use:

The example(s) above improved by complying with the rule.

Severity levels

The following definition of the severity levels is used as a guide to make it easier to group the different rules and coding standards.

  • Level 1 - Certainly a programming error
  • Level 2 - Very likely a programming error
  • Level 3 - Programming pitfall/undesired programming construct/accident waiting to happen
  • Level 4 - Design issue with high impact on reliability or maintainability
  • Level 5 - Design issue with low impact on reliability or maintainability
  • Level 6 - Portability or performance issue or high impact other issue
  • Level 7 - Comment related issue or medium impact other issue
  • Level 8 - Naming convention or low impact other issue
  • Level 9 - Style related issue
  • Level 10 - Controversial issue or issue with a relatively high false positive rate

Each rule in this coding standard has a severity level attached to it. These severity levels are set in the CC4M and one can configure for which severity levels to check. The severity levels are related to the severity levels of Tiobe's TICS tooling.

Expansion of the MonkeyProof MATLAB Coding Standard

This standard includes the rules of the MonkeyProof MATLAB Coding Standard which can be found here and mainly adds naming conventions to it amongst some other rules. Each unique rule has its own unique rule identifier.

The following rules are different:

  • NAMING-1 in this standard replaces NAMING-20 from the MonkeyProof MATLAB Coding Standard. This rule is about the length of variable names.

The following rules are an addition:

  • NAMING-5 a rule on variable casing.
  • NAMING-6 a rule on function casing.
  • NAMING-7 a rule on class casing.
  • NAMING-8 a rule on property casing.
  • NAMING-9 a rule on package casing.
  • NAMING-10 a rule on event casing.
  • NAMING-11 a rule on struct field casing.
  • NAMING-12 a rule on enumeration member casing.
  • NAMING-13 a rule on enumeration member casing.
  • STAT-15 a rule on minimizing the use of return.
  • STAT-20 a rule on avoiding the use of cell arrays.
  • LAYOUT-10 a rule on binary operators in multi-line statements.
  • FCNS-27 a rule on writing interpretable code.