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 guidelines 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 coding standards described here can be checked using Code Checker for MATLAB by MonkeyProof Solutions. The checkable coding standards are indicated by this logo cc4m_logo_inline at the top. These coding standards are configured in the predefined MonkeyProofSolutions configurations set available with the tool. This set is the default selection after installing. For instructions on how to check your code against coding standards, see the video below. The steps are also described below the video.

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

  1. Install Code Checker for MATLAB. If you have not purchased the tool yet, you can do so here. Alternatively, you could request a free trial license there.
  2. Open Code Checker for MATLAB 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.

The guidelines that require human judgment or are simply not possible to check statically in MATLAB are not part of this coding standard.

Structure of this document

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

  • Naming conventions: Guidelines in this chapter describe how variables, functions etc. can be named in a consistent and insightful manner.
  • Layout & comments: This chapter contains guidelines to help improve readability of your code for yourself and for others. There are guidelines on whitespace, comments and more.
  • Statements & expressions: The guidelines 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 guidelines: This chapter contains (among others) coding standards on higher-level objects such as functions or files.

Guideline template

Every guideline is structured as follows:

Guideline name

IDA unique guideline identifier.
TitleBrief description of the guideline.
PriorityPriority of the guideline can be one of Mandatory, Strongly recommended and Recommended.
Severity levelSeverity level of the guideline 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 guideline. Can include exceptions.
RationaleRationale or justification behind the guideline: why should you apply this guideline and how does your code improve when applying it or deteriorate when violating it?
Exception (Optional)An exception might apply to a guideline, i.e. a case for which the guideline does not hold.


One or more code examples to avoid using.

Instead use:

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

Severity levels

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

  • Level 1 - Programming error (no discussion)
  • Level 2 - Most likely a programming error (there are exceptions but in more than 50% of the cases this is a programming error)
  • Level 3 - Accidents waiting to happen (there is no error at the moment but if somebody makes a change the house of cards might collapse)
  • Level 4 - Important design issues
  • Level 5 - Less important design issues
  • Level 6 - Portability related rules, maintenance related issues
  • Level 7 - Performance related rules
  • Level 8 - Rules that deal with periphery such as comments, harmless preprocessor issues, etc.
  • Level 9 - Naming conventions related rules
  • Level 10 - Style related issue

As it currently stands, these severity levels have no further meaning in the Code Checker for MATLAB. They are however related to the severity levels of Tiobe's TICS tooling.