MATLAB
Guidelines 2.0
Richard Johnson
MATLAB Style Guidelines
Version 2, March 2014
Copyright © 2002 - 2014 Datatool
All rights reserved.
ISBN
Library of Congress Control Number
2
Contents
Introduction 5
Naming Conventions 7
Variables 7
Constants 13
Structures 14
Functions 15
General 19
Statements 21
Variables and constants 21
Globals 21
Loops 22
Conditionals 23
General 24
Layout, Comments and Documentation 29
Layout 29
White Space 30
Comments 32
Files and Organization 37
M Files 37
Input and Output 39
Toolboxes 40
Style quotes 41
References 43
3
MATLAB Style Guidelines
4
Introduction
Advice on writing MATLAB code usually addresses efficiency
concerns, with recommendations such as “Don’t use loops.” This
document is different. Its concerns are correctness, clarity and
generality. The goal of these guidelines is to help produce code
that is more likely to be correct, understandable, sharable and
maintainable.
Some ways of coding are better than others. It’s as simple as that.
Coding conventions add value by helping to make mistakes
obvious. As Brian Kernighan writes, “Well-written programs are
better than badly-written ones -- they have fewer errors and are
easier to debug and to modify -- so it is important to think about
style from the beginning.”
When people look at your code, will they see what you are
doing? The spirit of this book can be pithily expressed as “Avoid
write-only code.”
This document lists MATLAB coding recommendations
consistent with best practices in the software development
community. These guidelines are generally the same as those for
C, C++ and Java, with modifications for MATLAB features and
history. The recommendations are based on guidelines for other
languages collected from a number of sources and on personal
experience. These guidelines are written with MATLAB in mind,
and they should also be useful for related languages such as
Octave, Scilab and O-Matrix.
Issues of style are becoming increasingly important as the
MATLAB language changes and its use becomes more
widespread. In the early versions, all variables were double
precision matrices; now many data types are available. Usage
has grown from small scale prototype code to large and complex
5
MATLAB Style Guidelines
production code developed by groups. Integration with Java is
standard and Java classes can appear in MATLAB code. All of
these changes have made clear code writing more important and
more challenging.
Guidelines are not commandments. Their goal is simply to help
programmers write well. Many organizations will have reasons
to deviate from some of these guidelines, but most organizations
will benefit from adopting some style guidelines.
For broader and deeper coverage of MATLAB style and best
development practices, check out the book:
The Elements of MATLAB Style
available at
http://datatool.com/resources.html
or Amazon.
MATLAB is a registered trademark of The MathWorks, Inc. In
this document, MathWorks refers to The MathWorks, Inc.
If you have corrections or comments, please contact
richj@datatool.com
6
Naming Conventions
The purpose of a software naming convention is to help the
reader and the programmer. Establishing a naming convention
for a group of developers is very important, but the process can
become ridiculously contentious. There is no naming convention
that will please everyone.
Following a convention is more important than what the details
of the convention are. This section describes a commonly used
convention that will be familiar to many programmers of
MATLAB and other languages.
Variables
The names of variables should document their meaning or use.
MATLAB can cope with
z = x * y
but the reader will do better with
wage = hourlyRate * nHours
Write variable names in mixed case starting with
lower case.
This is common practice in other languages. Names that start
with upper case are commonly reserved for types or structures
in other languages.
linearity, credibleThreat, qualityOfLife
Very short variable names can be in upper case if they are
upper case in conventional usage and unlikely to become parts
of compound variable names. Examples are typically domain
MATLAB Style Guidelines
specific, such as E for Young’s modulus, which would be
misleading as e.
Some programmers prefer to use underscore to separate parts
of a compound variable name. This technique, although
readable, is not commonly used for variable names in other
languages. Another consideration for using underscore in
variable names in graph titles, labels and legends is that the Tex
interpreter in MATLAB will read underscore as a switch to
subscript, so you will need to apply the parameter/value pair
‘interpreter’, ‘none’ for each text string.
Variables with a large scope should have
meaningful names. Variables with a small scope
can have short names.
In practice most variables should have meaningful names. The
use of short names should be reserved for conditions where they
clarify the structure of the statements or are consistent with
intended generality. For example in a general purpose function it
may be appropriate to use variable names such as x, y, z, t.
Scratch variables used for temporary storage or indices can be
kept short. A programmer reading such variables should be able
to assume that its value is not used outside a few lines of code.
Common names for scratch variables used as integers are k,m,n
and for doubles s, t, x,y, and z.
Programmers who work with complex numbers may choose to
reserve i or j or both for the square root of minus one.
However, The MathWorks recommends using 1i or 1j for the
imaginary number. These execute more quickly and cannot be
overwritten.
Use the prefix n for variables representing the
number of objects.
8