Introduction

The goal of this set of coding standards that can be automatically checked is to help you write MATLAB code that is Coder-compatible. The resulting code will be more suitable for code generation. For more information on MATLAB Coder, see the MathWorks website.

If you are looking for more generic coding standards that are not specifically aimed at Coder-compatibility, see our MonkeyProof Solutions Coding Standards.

Automatic compliance checking

The coding standards described here can be checked using Code Checker for MATLAB by MonkeyProof Solutions. They are configured in the predefined CoderCompatibility configurations set available with the tool. 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 described here.

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. Exactly what each of these means for your case is up to you to decide.
DescriptionA more elaborate description of the guideline. Can include the reasoning behind the guideline: how does your code improve when applying the guideline?
RationaleOne or multiple words describing what the guideline is about. Examples: Compatibility, Stability.

Coder-compatibility function calls

IDCC-1
TitleDo not use built-in functions that are not supported by MATLAB Coder.
PriorityMandatory
DescriptionDo not use built-in functions that are not supported by MATLAB Coder. Calls to functions that have remarks in the documentation about Coder-compatibility need to be manually inspected.
RationaleCompatibility

Editor warnings

IDCC-2
TitlePrevent or suppress Code Analyzer messages.
PriorityStrongly recommended
DescriptionPrevent or suppress Code Analyzer messages shown in the MATLAB editor.
When the messages cannot be prevented, suppress them on an individual basis and add the reason in the comments.
The messages often indicate that improvements can be made to performance or stability of the code.
RationalePerformance, Stability

Error function

IDCC-3
TitleDo not use the built-in error.
PriorityMandatory
DescriptionDo not use the built-in function error.
RationaleCompatibility

Pause function

IDCC-4
TitleDo not use the built-in pause.
PriorityMandatory
DescriptionDo not use the built-in function pause.
RationaleCompatibility

Struct manipulation

IDCC-5
TitleDefine all fields of a struct in a single, contiguous block of code.
PriorityMandatory
DescriptionDo not use built-ins setfield, getfield, rmfield, orderfield and addfield to manipulate a struct after it was created. Define the entire struct in a single, contiguous block of code.
RationaleCompatibility, Readability

Dynamic fields

IDCC-6
TitleDo not use dynamic struct field or property names.
PriorityMandatory
DescriptionDo not use dynamic struct field or property names.
RationaleCompatibility

If else

IDCC-7
TitleEvery if shall have a matching else section.
PriorityMandatory
DescriptionEvery if shall have a matching else section, even if it does not contain executable code.
RationaleCompleteness

Switch otherwise

IDCC-8
TitleEvery switch shall have a matching otherwise section.
PriorityMandatory
DescriptionEvery switch shall have a matching otherwise section, even if it does not contain executable code.
RationaleCompleteness

Short-circuit operators

IDCC-9
TitleUse short-circuit logical operators (&&, ||) only in conditional statements.
PriorityMandatory
DescriptionUse short-circuit logical operators (&&, ||) only in conditional statements. In other statements, you can use & or | instead.
RationaleCompatibility

Functionality shadowing

IDCC-10
TitleDo not shadow built-in MATLAB functionality.
PriorityMandatory
DescriptionDo not define classes, functions, variables, properties etc. that are named the same as built-in MATLAB functionality.
RationaleNaming

Shell escape function

IDCC-11
TitleDo not use the shell escape function.
PriorityMandatory
DescriptionDo not use the shell escape function. It is not supported by the MATLAB Coder.
RationaleCompatibility

Scripts

IDCC-12
TitleDo not use scripts.
PriorityMandatory
DescriptionDo not use scripts because these are not supported by the MATLAB Coder.
RationaleCompatibility

Parentheses for precedence

IDCC-13
TitleUse sufficient parentheses to clarify the order of execution in expressions.
PriorityStrongly recommended
DescriptionUse sufficient parentheses to clarify the order of execution in mathematical and logical expressions. Without them, the generated code may display unexpected behavior.
RationaleReadability, Robustness

Floating-point comparisons

IDCC-14
TitleDo not compare floating-point values using == or ~=.
PriorityStrongly recommended
DescriptionDo not compare floating-point values using == or ~=. Rounding errors due to algorithm design or machine precision can cause unexpected results. Use a tolerance instead. Generated code can produce floating-point results different from the MATLAB results.
RationaleRobustness

Avoid:

out = myFcn(in) == sqrt(3);

Instead use:

out = abs(myFcn(in) - sqrt(3)) < 1e-12;

Binary expressions

IDCC-15
TitleBinary expressions should not make an assumption on the evaluation order of their operands.
PriorityStrongly recommended
DescriptionBinary expressions should not make an assumption on the evaluation order of their operands. Generated code does not enforce the order of evaluation in expressions. It is therefore advised to define variables to enforce a specific evaluation order. For more info, see The Mathworks.
RationaleRobustness