logo资料库

Matlab Style Guidelines 2.0 Richard Johnson.pdf

第1页 / 共43页
第2页 / 共43页
第3页 / 共43页
第4页 / 共43页
第5页 / 共43页
第6页 / 共43页
第7页 / 共43页
第8页 / 共43页
资料共43页,剩余部分请下载后查看
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
分享到:
收藏