Up User guide

3.7 Standard checks

There are a number of standard checks available within Code Checker for MATLAB. These can be enabled and configured as described in Chapter Configuration Editor↓. The checks are explained in the following sections. For every standard check, an exemption tag is given. For more information about this, see Section 3.9↓. If a check fails, its results hold the following information:
Note: In the HTML report at most one violation of the same type per line of code will be shown for several checks, this is indicated per check in the following sections.

3.7.1 checkArgumentsBlockUsed

Checks whether an arguments block is used for the specified categories of functions among the files selected for checking. The arguments block introduced in MATLAB R2019b is very useful for input argument validation and can also be used for automatic casting. It provides a more readable and more performant alternative to functions such as inputParser, narginchk, nargin and varargin. If your code does not need to support older MATLAB releases, you might want to enable this check. Its parameters facilitate only checking publicly available functions for the presence of an arguments block. This check ignores functions that:

Configurable parameters

Exemption tag: %@ok<CARBU>

3.7.2 checkAssertInputs

This checks if all calls to assert have an ID and a message as second and third inputs. These inputs can improve readability by showing the reader what it means if the assert fails. Additionally, the feedback to the user on a failed assertion will be much more informative.
Exemption tag: %@ok<ASINP>

3.7.3 checkAvoidComments

This checks if undesired phrases like, for example, ’% TODO’ and ’% WRONG’ are present in the comments of your code. Such comments reduce the readalibity of the code and increase the uncertainty of readers and maintainers. This check only searches for the phrases at the start of comments.

Configurable parameter

Exemption tag: %@ok<AVCOM>

3.7.4 checkAvoidFunctions

Checks if the code depends on functions that should be avoided. For example: using eval is often discouraged because it can result in code that is unreliable and difficult to read. Other reasons to discourage use of certain functions and keywords are to prevent system damage or to ensure automation or code generation. You can also specify entire MATLAB folders to avoid using functions from.

Configurable parameters

Exemption tag: %@ok<AVFUN>

3.7.5 checkAvoidNames

Checks if the code uses names not to use for classes, functions and variables etcetera. For example: using myFunc or temp is often discouraged because it is not descriptive and it gives the impression that work is still under construction.

Configurable parameters

Exemption tag: %@ok<AVNAM>

3.7.6 checkAvoidVararginout

Checks if the code uses varargin and varargout as variable length input and output argument list. Avoiding the use of these variable length arguments increases the readability of the code.

Configurable parameters

Exemption tag: %@ok<VARIO>

3.7.7 checkBlockComment

Checks if any comment blocks are used. These may not be recommended because they could comment out more or less than you want. The comment blocks are recognized by ’%{’ and ’%}’ on a line (optionally surrounded by whitespace).
Exemption tag: %@ok<BLCKC>

3.7.8 checkBuiltinFunctionCompatibility

Checks if all MATLAB-installed functions that are used by the checked code were introduced before or at the first supported MATLAB release of the code. For example, if your configuration states that the first supported MATLAB release is R2016b, this check will report all calls to MATLAB-installed functions that were introduced in R2017a and later. It is advised to run this check on the most recent MATLAB release you have available to see the best results (see the limitation).
Configurable parameters
Limitations
Exemption tag: %@ok<BFCNC>

3.7.9 checkCharacterArray

Checks the usage of character arrays. If one intends to use strings instead of character arrays, an overview of where character arrays are used is provided. The maximum number of reported character arrays per line is one. This does not report using outputs of MATLAB-installed functions that return character arrays. For example: mfilename or datestr. In the HTML report at most one violation of the same type per line of code will be shown for this check.
Exemption tag: %@ok<CHARA>

3.7.10 checkCodeLength

Checks the length of the code where only executable lines of code are taken into account. Possible arguments blocks do not count towards the number of lines in a function. Limiting the length of functions increases the readability of the code.

Configurable parameters

Exemption tag: %@ok<COLEN>

3.7.11 checkCoderCompatibilityFunctionCalls

Reports the MATLAB-installed functions used in the code that are (partially) MATLAB Coder-compatible or not. Three levels of support for C/C++ code generation can be reported: Fully supported, supported with limitations, and not supported. The violations in the report contain links to the documentation of the MATLAB-installed functions so that you can easily check the limitations (if any) or find alternatives that are (more) Coder-compatible.

Configurable parameters

If you would like to see the level of Coder-compatibility for every MATLAB-installed function call, you can configure this check multiple times, but with different settings for the SupportLevel parameter. That way, the report generated after the check contains a separate table for each of the support levels. For more information on configuring the same check multiple times, see Section Multiple configurations per check↑.
This check only reports known MATLAB-installed functions. This means that if you use a MATLAB-installed function that was introduced in a MATLAB release after the one you are using, it is not reported by this check. You can use checkBuiltinFunctionCompatibility for that. For example if you set the Release parameter to R2020b and you are using R2017b. Conversely, if you use a MATLAB-installed function that was introduced in a MATLAB release after the one you have configured under Release, but that is known in the MATLAB release you are using, the function call will be reported. This is because the function is not supported in the configured MATLAB release, so it is also not Coder-compatible. For example, you set the Release parameter to R2017b and you are using R2020b to run the check.
Exemption tag: %@ok<CCFCN>

3.7.12 checkConstantDefinitionAtTop

Checks whether all constants are defined at the top of the function or script. Constant definitions are allowed to come before or after persistent and global declarations. Similar, constant definitions are allowed to come before or after import statements. Starting in MATLAB R2019b, the arguments block is available. Since no code can come before this block, all constant definitions will automatically come after it. For this check, a variable is considered to be a constant if it meets all of the following criteria:
Aside from numbers and the MATLAB-installed functions listed above, several operators and constructs can be used in a variable declaration and it can still be considered a constant:
Here are some examples of what are considered constants by Code Checker for MATLAB: 
a = 100;
b = 1 + 3;
c = 1.3e-9;
d = sqrt(2)/2;
e = pi^2;
f = 3 : 2 : 11;
g = "Test";
h = [3, 5, 10]’;
The following variable declarations are not considered constants by Code Checker for MATLAB: 
k(3) = 5;
l = 100; % The value changes on the next line.
l = 200;
m = v + 1; % Where v is not seen as a constant.
n.field = 10;
p = cumsum([3, 5, 8]);
Exemption tag: %@ok<CNDAT>

3.7.13 checkContiguousStructFieldDefinitions

Checks whether for every struct, the fields are defined in a single, contiguous block of code. For this check, a single, contiguous block of code is defined as a block of code without empty lines in it. For example: 
s.a = 2;
s.b = 3;
​
s.c = 100; % Separate block of code, so will be reported.
Additionally, this reports cases where the struct is used before all fields are added, even when it is a contiguous block of code. This only holds when the struct is used as an input to an assignment or function call in its entirety. The individual fields of the struct are allowed to be used before all fields are added. For example: 
s.a = 2;
s.b = 3;
myCustomFcn(s);
s.c = 100; % The same code block, but the struct has already been used. This will be reported.
Conversely, the following will not result in a violation being reported by this check: 
s.a = 2;
s.b = 3;
myCustomFcn(s.b, s.a);
s.c = 100; % The struct fields are used, but that is fine. No violation to report.
Some remarks about this check:
Exemption tag: %@ok<CSTFD>

3.7.14 checkCopyrightNotice

Checks if a specific copyright notice is found in the checked files. A copyright notice can be used as a deterrent against copyright infringement. There are a few configurable parameters for this check. If a copyright notice is lengthy, it may be split across multiple lines in the checked file(s). This is supported by this check. It is required to have your copyright notice on a separate line, so without any code on it.

Configurable parameters

This check has an auto-fixer. Clicking the Fix all button in the report fixes all violations for this check, clicking the Fix for this file button fixes the violation for one file.
Exemption tag: %@ok<COPYR>

3.7.15 checkDuplicateAttributes

Checks classdef files and reports any methods or properties blocks with duplicate attribute values. Decrease the number of methods and properties blocks by combining blocks that have identical attribute values into one. This check considers setting an attribute to its default value equal to omitting the attribute. See what the default values for all attributes are in the MathWorks documentation. Keep the following in mind for this check:
Exemption tag: %@ok<DUPAT>

3.7.16 checkDynamicFields

Reports use of any dynamic struct field names and property names. Aside from personal preferences regarding this construct, this check is especially useful when the code must be MATLAB Coder-compatible (generating C/C++ code from your MATLAB code). This is because dynamic struct field and property names are not supported by the MATLAB Coder. Some examples of what will be reported by this check are (where the variable and name can be a struct and fieldname, or an object and property name): 
s.(theField)     = 12;
s.x.(otherField) = 10;
a                = s.(b + "cd");
c                = s.([’test’, ’cat’])
Exemption tag: %@ok<DYNFI>

3.7.17 checkEditorWarnings

Checks if any warning messages are shown to the user in the MATLAB editor. With this check, the user does not need to open a file to see the editor warnings. Warning messages that are suppressed in the MATLAB editor are ignored by this check.

Configurable parameters

See https://www.mathworks.com/help/matlab/matlab_prog/check-code-for-errors-and-warnings.html for more information about checking MATLAB code for errors and warnings.
Note that this check can be configured multiple times, but the warning messages are obtained once. Which means that only one combination of the parameters ’MlintSettings’ and ’SettingsLocation’ can be used. Therefore it is necessary to configure those two parameter identical for all configuration of this check. If this is not the case when editing a configuration in the Configuration Editor, a dialog will pop up and you will get notified about non-identical parameter values.
Exemption tag: %@ok<EDWRN>

3.7.18 checkExpressionAlignment

Reports code blocks with expressions that are not properly aligned. In order to make your code more readable, consider aligning equals signs of the assignment expressions in a code block. This check reports contiguous blocks of assignments that do not have their equals signs aligned. Any non-assignment line (includes empty lines) indicates the end of a contiguous block of assignments. Some examples that will be reported are: 
a = 12;
foobar = 101;
​
b = 1 ...
    + 3.1415 ^ 2;
eggs = 3;
more = ’test’;
These examples after fixing will look as follows: 
a       = 12;
foobar  = 101;
​
b       = 1 ...
    + 3.1415 ^ 2;
eggs    = 3;
more    = ’test’;
Here are some examples of pieces of code that will not be reported by this check. 
a = 12;
​
foobar = 101;
​
b = 1 ...
    + 3.1415 ^ 2;
someFunctionCall(b);
eggs = 3;
Alignment is checked based on the number of characters before the equals signs. A tab is treated as a single character, which means that equals signs may seem aligned, but a violation is reported anyway because for a different setting of the tab size, they are not aligned. Sets of method declarations, properties blocks and arguments blocks will not be reported by this check.
This check has an auto-fixer. Clicking the Fix all button in the report fixes all violations for this check, clicking the Fix all in this file button fixes all violations for this check for one file. You can use the Fix on this line button to apply the fix to the violations in an individual block of code. The auto-fixer insert spaces, not tabs. For more information, see Section 3.11↓.
Exemption tag: %@ok<EXPAL>

3.7.19 checkFollowedBySpace

Checks if commas, semicolons and keywords are followed by a space. Per default, this does not report commas, semicolons and keywords that are only followed by white space until the end of the line. This check also does not report any violations that are found in strings or comments. Enable this check to help improve readability of the code.
All MATLAB keywords in alphabetical order are: arguments (from R2019b), break, case, catch, classdef, continue, else, elseif, end, for, function, global, if, otherwise, parfor, persistent, return, spmd, switch, try and while.
This check has an auto-fixer as well. Clicking the Fix all button in the report fixes all violations for this check, clicking the Fix all in this file button fixes all violations for this check for one file. The Fix on this line button applies the fix on one indivual line. For more information, see Section 3.11↓. In the HTML report at most one violation of the same type per line of code will be shown for this check.
Exemption tag: %@ok<FOLSP>

3.7.20 checkFunctionIndented

Used to check whether or not functions are indented. Rules may specify that the contents of every function must be indented or that they should not be. The following rules apply to this check:

Configurable parameters

Exemption tag: %@ok<CFIND>

3.7.21 checkFunctionPrefix

Checks if the names of local functions (also referred to as subfunctions) and nested functions are prefixed with specified prefixes. By prefixing these functions, calls to local or nested functions can easily be distinguished from other function calls. This check ensures that the prefixes are actually used as prefixes: at the start of the name and followed by at least one character.
Configurable parameters
Exemption tag: %@ok<FCNPF>

3.7.22 checkGetterAndSetter

Checks if methods such as get.MyProperty() and set.MyProperty() have been declared. The rationale behind this check is that nothing should happen when you set or get a property when it is used directly to make sure that the code stays readable and does not produce any unexpected side effects. If it is necessary that actions are performed when getting or setting a property, make the property private and implement explicit getters and setters (for example getMyProperty() and setMyProperty()).
Exemption tag: %@ok<GETST>

3.7.23 checkGlobalUsed

Checks if the keyword global is used. Use of this keyword is often discouraged (not in MATLAB specifically) because (among many other reasons) it becomes very difficult to determine which functions access these variables. This keyword has its own check because its priority is often higher than that of the keywords and functions listed under checkAvoidFunction.
Exemption tag: %@ok<GLOBU>

3.7.24 checkIfElse

Checks if every if has a matching else section. Defining an else section for every if improves readability by showing more clearly what it means when the if (and possible elseif’s) condition are not satisfied.
Exemption tag: %@ok<IFELS>

Configurable parameters

3.7.25 checkIfTrue

Checks if constructs such as if true are used. Using this type of if-statements reduces readability and can generally be left out. The full list of constructs of this type that is checked is: if true, if false, if 1 and if 0. Note that in some of these cases, MATLAB’s Code Analyzer will display a warning message already.
Exemption tag: %@ok<IFTRU>

3.7.26 checkIndentationLength

Check if all indented lines have an indentation length divisible by parameter indentation length, except for white lines. Consistent indentation increases the readability of the code. This check may not work as expected when tabs do not insert whitespace, but tab characters.

Configurable parameter

Exemption tag: %@ok<CINLE>

3.7.27 checkLineLength

Checks if the length of a line exceeds the maximum line length according to the coding standards, for readability it is advisable to have a maximum on the line length. Check includes comments and whitespaces.
Configurable parameters
Exemption tag: %@ok<LILEN>

3.7.28 checkLogicalOperator

Checks for usage of logical operators && and || in logical expression. The short-circuit operators && and || only work on scalars and are therefore not useful for general logical expressions. Use elementwise logical operators & and | instead. In the HTML report at most one violation of the same type per line of code will be shown for this check.
Exemption tag: %@ok<LOGOP>

3.7.29 checkLoopIteratorNaming

Checks if iterator variables are prefixed with i, j, k etc. Depending on the parameters for variable casing, this can mean that iterator variables can be of the form iRow, jTest (lower/upper Camel casing), i_row, j_test (Snake casing), iROW, jTEST (screaming Snake casing) or or irow, jtest (lower casing). When enabled, this check fails if:

Configurable parameters

By maintaining a convention on iterator variables, these can easily be distinguished within the code.
Exemption tag: %@ok<IDXNA>

3.7.30 checkMagicNumber

Reports use of so-called magic numbers or unnamed numerical constants in your code. These are numbers used directly in the code without being assigned to a variable first. For example, replace
x = 9.81 * t;
with
g = 9.81; % Gravity constant.
x = g * t;
Using magic numbers in your code can degrade readability and the author’s intent for them may not be apparent. There are some situations that will not be reported. For example, comparing the output of nargin or exist to a number that would normally be reported. Aside from these exceptions, this check’s strictness can be configured using the parameters described below. In the HTML report at most one violation of the same type per line of code will be shown for this check.

Configurable parameters

Exemption tag: %@ok<MAGNR>

3.7.31 checkMethodsInClassdef

Check if all methods that are declared in a classdef file are also implemented, and that the declaration is the same as the implementation. Also check that the declaration is the same as the implementation (i.e. do not declare varargin but have a method with "(x,y,x)" input arguments). Check that all methods that have an implementation in a seperate file are also declared.

Configurable parameters

Exemption tag: %@ok<MDAMI>

3.7.32 checkMissingComma

Check if any rows lack properly placed commas to separate the elements. Some examples that will be reported as violations by this check and their accepted equivalents: 
% Violations:
txt 	= [’test ’ var ’ text.’];
values  = [1 1 2 3 5 8 13];
myCells = {obj1 ,obj2};
multi   = [’The multi-’ ...
	’line char array.’];
​
% Accepted equivalents:
txt 	= [’test ’, var ’, text.’];
values  = [1, 1, 2, 3, 5, 8, 13];
myCells = {obj1, obj2};
multi   = [’The multi-’, ...
	’line char array.’];
This check has an auto-fixer as well. Clicking the Fix all button in the report fixes all violations for this check, clicking the Fix all in this file button fixes all violations for this check for one file. The Fix on this line button applies the fix on one individual line. For more information, see Section 3.11↓.
When multiple function outputs are not separated by commas, it can reported by checkEditorWarnings↑. In the HTML report at most one violation of the same type per line of code will be shown for this check.
Exemption tag: %@ok<MCOMM>

3.7.33 checkMissingSemicolon

Reports lines of code that could result in output to the command window because they are not terminated with a semicolon. Use this check to determine the part of your code that produces unwanted or unexpected output. In the HTML report at most one violation of the same type per line of code will be shown for this check.

Configurable parameters

This check has an auto-fixer as well. Clicking the Fix all button in the report fixes all violations for this check, clicking the Fix all in this file button fixes all violations for this check for one file. The Fix on this line button applies the fix on one individual line. For more information, see Section 3.11↓.
Exemption tag: %@ok<MSEMC>

3.7.34 checkMixedTypesExpression

Checks expressions and conditions to see if operands or operators of logical and numerical types were mixed. Mixing operand types in an expression or condition decreases code readability and robustness. Some examples of expressions that will be reported by this check are: 
a = 8.9 || 9.1; 		% Numbers and logical operator ||.
b = isempty(a) * 3; 	% MATLAB-installed function ’isempty’ and the multiplication operator.
c = a * b & a > b; 	 % Multiplication and the logical operator &.
d = a / ~c;  	 	  % Division and the ’not’ operator.
Since Code Checker for MATLAB cannot reliably determine a variable’s type, this check does not use such information. Only information known at the expression or condition itself will be used. Aside from the operators themselves, a non-exhaustive list of MATLAB-installed functions (including isempty as shown in the example) is used to determine the operand types.
Exemption tag: %@ok<MIXOT>

3.7.35  checkNameIsShadowing

Checks for all variables and functions in the file(s) whether they shadow any existing functionality. For example: if a variable named pi is defined, you will no longer have access to the actual value of π within that file. This can cause unexpected and undesired behaviour. Variables and functions are reported if they have the same name as one or more of the following:

Configurable parameters

Exemption tag: %@ok<NSHAD>

3.7.36 checkNameLength

Checks if the length of function and/or variable names are within the allowed minimum and maximum length according to the coding standards. Limiting the lenght of function and variable names increases the readability of the code.

Configurable parameters

Exemption tag: %@ok<NALEN>

3.7.37 checkNegatedBoolean

Checks if there are no variables that have negated boolean names such as notValid, is_not_ok. Using such variables in conditional expressions can be confusing and difficult to read and therefore, this check may be enabled. Based on the casing used for variables, this reports variables with names that:
By using these settings instead of just looking for not, names such as notation and myNotifier will not be reported as fails of this check.

Configurable parameters

Exemption tag: %@ok<NEGBO>

3.7.38 checkNestedFunction

Checks if there are any nested functions used. Using nested functions is often discouraged because it can degrade code readability.
Exemption tag: %@ok<CNSTF>

3.7.39 checkNestingDepth

Check on the nesting depth of blocks. Limiting the nesting depth of blocks increases the readability of the code.

Configurable parameter

Exemption tag: %@ok<NSTDP>

3.7.40  checkNoInputArg

Checks if all function calls without input arguments have empty parentheses. Most importantly, using empty parentheses instead of leaving them out helps to distinguish between accessing an object’s properties and using it’s methods. Additionally, it clearly shows where functions are called. In order to prevent copious amounts of fails to this check, a number of MATLAB-installed functions will be ignored when called with no input arguments and with no empty parentheses. These are: false, true, pi, eps, nargin, nargout, mfilename, pwd, cd, Inf, NaN, clc, clear, rand, randn, i, j, filesep, tempname, tempdir, drawnow, NaT, date and now.
This check has an auto-fixer as well. Clicking the Fix all button in the report fixes all violations for this check, clicking the Fix all in this file button fixes all violations for this check for one file. The Fix on this line button applies the fix on one indivual line. For more information, see Section 3.11↓.

Configurable parameters

Limitations

Exemption tag: %@ok<INPAR>

3.7.41 checkNumberOfInputsOutputsFunction

Checks if there are any functions with too many inputs or outputs. For readability of the code it is advisable to limit the number of input and output parameters of a function. It is recommended to group related parameters into structures.

Configurable parameters

Exemption tag: %@ok<NINOF>

3.7.42 checkNumberOfOutputsConstructor

Checks the number of outputs of a constructor, it is often desired to have only one output: an object of the class.
Exemption tag: %@ok<NOOCS>

3.7.43 checkOneStatementPerLine

Checks if there is at most one statement per line. For readability, it is advisable to have at most one statement per line.

Configurable parameters

Exemption tag: %@ok<OSTPL>

3.7.44 checkOperatorsLineContinuation

Checks if multi-line statements are split before or after binary operators. For example, consider the difference between the following two statements: 
isValid = testsPass ...
	&& validationPassed;
​
isValid = testsPass && ...
	validationPassed;
This check has an auto-fixer as well. Clicking the Fix all button in the report fixes all violations for this check, clicking the Fix all in this file button fixes all violations for this check for one file. The Fix on this line button applies the fix on one individual line. For more information, see Section 3.11↓.

Configurable parameters

Exemption tag: %@ok<OPLCO>

3.7.45 checkParenthesesLogicalOperators

This check reports any statements in which insufficient parentheses are used to clarify the precendence of logical operators. Any statement where the operator precedence affects the outcome must use sufficient parentheses. For example:
x = a && b || c; shall become x = (a && b) || c; or x = a && (b || c);
When only one type of logical operator is used, operator precedence is irrelevant and no parentheses are required for this check. For example: x = a && b && c;

Configurable parameters

Exemption tag: %@ok<PARLO>

3.7.46 checkParenthesesMathematicalOperators

Checks if all statements with mixed mathematical operators use sufficient parentheses to clarify operator precedence. The mathematical operators that are checked are: +, -, /, *, and .*. As an exception, + and - are allowed to be used successively without requiring parentheses for clarifying operator precedence because the order in which the operators are treated does not matter. In the HTML report at most one violation of the same type per line of code will be shown for this check. Some examples of code that will be reported by this check are: 
x = 6 * 2 + 1;
y = 1 / 2 * 3;
z = 2 * pi + 2;
Some examples of code that will not be reported by this check are: 
a = 6 * 2 * 1;
y = 1 + 2 - 3 + 5;
z = (2 * 3) + (5 * 2);
Exemption tag: %@ok<PARMO>

3.7.47 checkPersistentUsed

Checks if the keyword persistent is used. Use of this keyword is often discouraged (not in MATLAB specifically) because (among many other reasons) it becomes very difficult to determine which functions access these variables. This keyword has its own check because its priority is often higher than that of the keywords and functions listed under checkAvoidFunction.
Exemption tag: %@ok<PERSU>

3.7.48 checkPropertiesBeforeMethods

Checks if all properties blocks are before all method blocks in classdef files. For readability, it is advisable to have all properties blocks before the method blocks in classdef files.
Exemption tag: %@ok<PBBMB>

3.7.49 checkPropertyClassRedundancy

Checks if there are properties that contain the name of the class. For readability, it is advisable to not have redundancy in a property name.
Exemption tag: %@ok<PRCLR>

3.7.50 checkReuseIteratorVariableName

Checks if iterator variable names are reused as iterator variable within a function. Not reusing iterator variable names prevents renaming all iterators when only the one for a specific loop must be renamed. Not reusing iterator variable names also improves readability.
If both this check and 3.7.29↑ are enabled, possible violation messages contain a note that the user should be aware of it.
Exemption tag: %@ok<RUIVN>

3.7.51 checkScriptFileUsed

Checks if there is a script file used. Scripts are not always desired, use functions and classes instead.
Exemption tag: %@ok<SCRFU>

3.7.52 checkShellEscape

Checks if the shell escape function is used in the code. An exclamation point (!) indicates that the rest of the line is a command to the operating system. This is called a shell escape. As an alternative, you can use the MATLAB-installed function system. If your coding standards dictate that no system calls should be used, configure checkAvoidFunctions such that use of the system function is reported in addition to the shell escape function.
Exemption tag: %@ok<SHESC>

3.7.53 checkStringDataType

Checks if the string data type is used in the code. The string data type was introduced in MATLAB R2016b and the double quote notation was introduced in MATLAB R2017a. For backwards compatibility purposes, it can therefore be desired not to use this data type. It may also be for consistency reasons that you want to check if this data type is used. This check reports a violation when the double quote notation is used to indicate a string or when the MATLAB-installed string() or strings() function is used. When multiple strings are defined on a single line using double quotes, only the first violation is reported. In the HTML report at most one violation of the same type per line of code will be shown for this check.
Note that this check only reports the cases described above. This mostly means that MATLAB-installed functions that can output a string are not reported as violations. For example: data = readtable(’test.csv’, ’TextType’, ’string’); will output a table containing strings, but no violation is reported.
Exemption tag: %@ok<STRDT>

3.7.54 checkStructFieldNames

Checks whether any structure field names contain the name of the struct. For example: sensor.SensorWeight. This is a case insensitive check. This check checks fields that are defined in the following manner: test.TestLength = 10;. Additionally, field names defined using the struct() function like test = struct(’TestLength’, 10); are also checked.

Limitations

Dynamically assigned field names are not checked by this check because the field names cannot be collected. Therefore, structures defined as follows will not result in violating this check: 
fieldNames     = {’my_field’, ’my_2nd_field’};
myStruct       = struct(fieldNames{1}, [], fieldNames{2}, []);
​
str            = ’TEST’;
myStruct.(str) = [];
An additional limitation related to this check is given in Chapter 9↓.
Exemption tag: %@ok<SFNAM>

3.7.55 checkSubFunction

Checks if there are any sub functions used. Using sub functions is often discouraged because it can degrade code readability, testability and re-use. Use seperate function files instead of sub functions.
Exemption tag: %@ok<CSUBF>

3.7.56 checkSuppressAll

Checks if there are any MATLAB Code Analyzer messages being suppressed throughout the file. Code Analyzer messages should generally be prevented. If they are not prevented, they should be suppressed and have an accompanying comment stating the reason for suppression (not checked by checkSuppressAll). It is advisable not to do this throughout an entire file because the same warning may be helpful elsewhere.
Exemption tag: %@ok<SUPAL>

3.7.57 checkSurrBySpaces

Checks if certain operators are surrounded by spaces. Surrounding for example ’=’ by spaces makes the code more readable. This check excludes strings and comments.
This check has an auto-fixer as well. Clicking the Fix all button in the report fixes all violations for this check, clicking the Fix all in this file button fixes all violations for this check for one file. The Fix on this line button applies the fix on one indivual line. For more information, see Section 3.11↓. In the HTML report at most one violation of the same type per line of code will be shown for this check.

Configurable parameters

Exemption tag: %@ok<SURSP>

3.7.58 checkSwitchOtherwise

Checks if every switch statement has a matching otherwise section. Defining an otherwise section improves readability by clearly showing what happens when none of the case’s are triggered. It also allows for defining error messages if required.
Exemption tag: %@ok<SWOTH>

3.7.59 checkTabCharacterUsed

Checks if tab characters are used, since the length of a tab can vary it is therefore advised to use spaces instead. Using "\t" or char(9) is not reported instead. In case of multiple violations per line of code, only one violation per line is shown in the report. This check has an auto-fixer. Clicking the Fix all button in the report fixes all violations for this check, clicking the Fix all in this file button fixes all violations for this check for one file. The Fix on this line button applies the fix on one individual line. The auto-fixer inserts spaces. For more information, see Section 3.11↓. In the HTML report at most one violation of the same type per line of code will be shown for this check.
Exemption tag: %@ok<TABCU>

3.7.60 checkTestSuffix

Checks if the configured suffix is reserved for unit test files. Unit test files can be classdefs, functions or scripts. What is considered to be a unit test file by Code Checker for MATLAB is defined as follows:
This check reports files in two situations:
  1. If the file is considered a test file but it is not suffixed with the configured suffix.
  2. If the file is not considered a test file but it is suffixed with the configured suffix.

Configurable parameters

Exemption tag: %@ok<TSTSF>

3.7.61 checkTryExceptionHandling

Run this check to check if all try blocks are only used for exception handling. Although not recommended, try statements could also be used to suppress errors or to express a simple condition. checkTryExceptionHandling checks the following for every try:
  1. Is there a catch block with at least one line of executable code?
  2. Is an exception object assigned or created in the catch?
    1. Assigned: catch ME
    2. Created: ME = MException(errorID, msg);
  3. Is at least one of the list of exception handling MATLAB-installed functions or keywords used in the catch?
This does not check if points 2 and 3 hold for all execution paths within the catch, so if you use an if-else within the catch and only call an exception handling function in one of the two, it is not reported by this check.

Configurable parameters

Exemption tag: %@ok<TRYEH>

3.7.62 checkTryUsed

Checks if MATLAB’s try - catch construct is used. Using this construct is often discouraged because it can degrade code readability. It can be unclear what is expected to go wrong within the try and it is therefore generally advised to write code around what could go wrong.
Exemption tag: %@ok<TRYUS>

3.7.63 checkWarningUsed

Checks if warnings are used. Do not throw warnings, if necessary throw errors instead. Using errors instead of warnings improves the robustness of the code. Warnings cannot reliably be caught and handled and therefore often accomplish little. The check ignores calling warning for disabling, enabling, or querying a warning. This means that using for example warning(’off’, ’matlab:my:identifier’); is not reported by this check.
Limitations
This check also reports cases where a warning state is set using a variable. Consider the following example: 
warningState = ’off’;
warning(warningState, ’matlab:my:identifier’);
The statements do not issue a warning when run, but this check reports the second statement.
This check also reports calls to warning when you have shadowed the MATLAB-installed function with a local one..
Exemption tag: %@ok<WARNU>

3.7.64 checkWhiteSpaceEndOfLine

Checks if white space is used at the end of a line. For readability purposes do not use white space at the end of a line, comments are not taken into account, empty lines are ignored.
This check has an auto-fixer as well. Clicking the Fix all button in the report fixes all violations for this check, clicking the Fix all in this file button fixes all violations for this check for one file. The Fix on this line button applies the fix on one indivual line. For more information, see Section 3.11↓.
Exemption tag: %@ok<WSEOL>

3.7.65 Casing checks

Code Checker for MATLAB has several checks on the casing of names of certain aspects in the code. The casing of names can be checked for the following:
1checkUserDefinedFunctionCasing: This only checks the names of user-defined functions that are not methods. The names of methods are checked elsewhere. Furthermore, when this check is used in combination with checkFunctionPrefix, prefixes are subtracted before checking if the functions are cased according to the configured values.
2checkStructFieldCasing: this check suffers from the same limitation as checkStructFieldNaming: casing of dynamically assigned field names will not be checked.
3checkMethodCasing: does not report declarations of methods that are incorrectly cased if their functionality is specified in a separate function file. Additionally, getter and setter methods are ignored in this check, because their names are derived from property names that have a separate check. Constructor names are ignored during this check because they are named after the class. Finally, methods that overload a method of a superclass, are not checked here because those method names are not defined by the checked classdef file. Note, if a superclass has its own superclass(es), this is not taken into account.
There is a separate check for each of these, which means that every casing check can have their own parameter values. The parameters each of the casing checks has, are:
These parameters combined are used to check the casing of names as follows:
Upon a rule violation, the casing checks provide the same information as the other checks do: A path to the checked file, the part of the code violating the coding standards, the scope (if appliccable), and a feedback message.
Constant properties casing
Constant properties may be subject to different casing rules. This is made available with checkNamedConstantCasing. This casing check behaves different from the other casing checks:

3.7.66 Missing checks

If the checks available within Code Checker for MATLAB do not cover something you want to have checked, please contact us at info@monkeyproofsolutions.nl.
Up User guide