この記事は，
Datatool社のRichard Johnson氏が書いた
"MATLAB Programming Style Guideline"
を自分なりに翻訳したものです．
この文書は
MATLABのコードをより素晴らしいものにするための
多数のコーディング作法について書かれています．
翻訳結果は以下の各リンクから読むことができます．
0. MATLAB Programming Style Guidelines : About This Document - MY ENIGMA
1. MATLAB Programming Style Guidelines : Introduction - MY ENIGMA
2. MATLAB Programming Style Guidelines : Naming Conventions - MY ENIGMA
3. MATLAB Programming Style Guidelines : Constants and Structures - MY ENIGMA
4. MATLAB Programming Style Guidelines : Functions - MY ENIGMA
5. MATLAB Programming Style Guidelines : General - MY ENIGMA
6. MATLAB Programming Style Guidelines : Files and Organization - MY ENIGMA
7. MATLAB Programming Style Guidelines : Statements - MY ENIGMA
8. MATLAB Programming Style Guidelines : Layout, Comments and Documentation - MY ENIGMA
もし，これらの文章に意見や質問,誤謬などがあれば，
それぞれの記事にコメントしてもらえると幸いです．
また，今回の一連の文章は
リンクフリーです．
また，出典を明確にして頂ければ，
内容の転載も可能です．
その際は，コメント欄を利用して一言お願いします．
この"MATLAB Programming Style Guideline"の英語の原本は
以下のリンクからダウンロードできます．
・MATLAB Programming Style Guidelines - File Exchange - MATLAB Central
また，Richard Johnson氏は，
より詳細なMATLAB Programming Style Guidelineを広めるために，
以下の本を出版しています．
もし，より深くMATLABのプログラミング作法を学びたい方は，
こちらも参考にすると良いと思います．
最後に，
今回の翻訳は，Richard Johnson氏に直接許可を頂いています．
Richard Johnson氏の寛大な心と素晴らしい仕事に，
深く感謝します．
Files and Organization
コードを構造化するためには，
ファイル間とファイル内の両方を理解可能にする必要があります．
よく考えられた，ファイル分割と順序付けは，
コードの価値を向上させるのです．
M Files
ルール1：M-Fileはモジュール化しましょう．
大きなブログラムを書く際の最も良い方法は，
よく設計された小さなコード(大抵は関数)
を組み合わせて構築することです．
この方法は
そのコードがどのような振る舞いをするのかを知るために，
読まなければならないコード量を減らすことができるため，
コードの可読性を向上させ，
理解しやすく，テストしやすいコードにすることができます．
エディタのスクリーン二枚分以上のコードの場合，
そのコードは分割したほうがいいでしょう．
小さく，よく設計された関数は，
他のアプリケーションでも使用しやすいものになるでしょう．
ルール2：他の関数との相互作用を明確にしましょう．
関数は，その関数の入力，出力，そしてグローバル変数によって，
他のコードに相互作用をもたらします．
グローバル変数を多用するよりは，
入出力を使用するほうが，より関数の相互作用が明確になるでしょう．
また関数の入出力に構造体を使うことは，
入力と出力のリストが膨大になるのを防いでくれるので，
オススメです．
ルール3：ファイルを分割する．
すべてのサブ関数と多くの関数は，
たった一つの機能のみを持つべきです．
ルール4：既存の関数を利用する
必要な関数を一から開発することは重要ですが，
読みやすく，品質が良く，改変しやすい関数を
一から作ることは
非常に大変な仕事になりがちです．
したがって，
要求のすべて，または一部でも満たしている
既存の関数を探したほうが，
早かったり，確実だったりすることの方が多いようです．
ルール5：複数の部分で使用されるコードは，必ず関数化する．
もし，コードを改変しなければならない時に，
その部分が一つのファイルにまとめられていれば，
こんなに楽なことはありません．
“Change is inevitable, except from a vending machine.
変化は必ず発生するものです。自動販売機以外は*1
ルール6：サブ関数を利用する．
ある関数を，他のたった一つの関数のみで使用する場合，
その関数は，同じファイル内で，
その関数のサブ関数として，記述するようにしましょう．
そうすることにより，その関数の可読性とメンテナンス性を
向上させることができます．
ルール7：テストスクリプトを作成する．
すべての関数に対して，テストスクリプトを作成しましょう．
このようにすることによって，その関数の初期バージョンの
品質を向上させることができますし，
バージョンを上げた時にも，コードの可読性が向上します．
どんな関数でも，
コーディングができたのであれば，
テストを書くことも可能であるはずです．
Boris Beizerは以下のように言っています．
"テストをすること以上に，
テストそのものを設計することの方が，
よりバグを減らすことができる．"
入出力
ルール1：入出力もモジュール化しましょう．
ある関数の出力というのは，
特に知らせもなく，変更されるものです．
同様に，入力のフォーマットや内容も
変更されやすく，しばしば混乱をもたらします．
従って，入出力に関するコードは
一箇所にまとめ，メンテナンス性を向上させるべきでしょう．
入出力に関するコードと，実際の計算の部分のコードを
明確に分けるべきだということです．
様々な目的が混在した関数は，
再利用性が低下しがちです．
ルール2：出力のフォーマットを使用しやすいものにしましょう．
もし，ある関数の出力が，
人間にとって読みやすいものであったなら，
それは，そのコードにそのコード自身を語らせることができますし，
何より，読みやすくなります．
一方，
もし，ある関数の出力が，
人間よりもソフトウェアにとって読みやすいものであったら，
それは，よりソフトウェアに組み込みやすくなるでしょう．
これは，両方とも重要なことです．
人間が読みやすく，
かつ，ソフトウェアに組み込みやすい
出力値のフォーマットにすべきです．
参考文献
myenigma.hatenablog.com
myenigma.hatenablog.com
myenigma.hatenablog.com
myenigma.hatenablog.com
myenigma.hatenablog.com
*1:アメリカでは有名な格言らしいですが，正直，言いたい意味がよくわからないですね．．．
