この記事は,
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:アメリカでは有名な格言らしいですが,正直,言いたい意味がよくわからないですね...