![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
|
Counter: 14689,
today: 1,
yesterday: 1
Caml Programming Guideline 和訳
Japanese translation by M.Ukai (ukai at sansu dot org). Caml プログラミングガイドラインこれはCamlプログラムの体裁を整えるための、 ベテランのCamlプログラマのコンセンサスを反映したガイドライン集です。 が、誤りや漏れの指摘は喜んで受け入れます。 コメントはここに送ってください: webmaster @ caml.inria.fr オリジナルの英訳者: Ruchira Datta このページに批評を加えてくれた人たちに感謝します： Daniel de Rauglaudre, Luc Maranget, Jacques Garrigue, Damien Doligez, Xavier Leroy, Bruno Verlyck, Bruno Petazzoni, Francois Maltey, Basile Starynkevitch, Toby Moth, Pierre Lescanne. プログラムを書くときの一般的なガイドライン単純に、読みやすくプログラムをタイプする時間は、それを読む時間と比較すると無視できるので、 可読性を最適にするよう努める程時間を節約できる。 今日プログラムをシンプルにするための時間を無駄にすると、その100倍の時間が 将来の非可算ともいえる多くの修正やプログラムの解読 (最初のデバッグも含めて)となって跳ね返ってくるだろう。
プログラムの書式に関するガイドライン文法の慣習
デリミタスペースは常に識別子のデリミタとして使うべきだ。 またスペースは演算子記号を囲うべきだ。 活版印刷でテキストを読むのを簡単にするためにスペースで単語を分離する(分かち書き)のはすばらしい進化だった。 プログラムの可読性を上げるためにこれと同じようにしよう。 組の書き方タプルは括弧で括り、中のコンマ(デリミタ)にはスペースを後置する: (1, 2) let triplet = (x, y, z) ...
リストの書き方x :: 1 のように :: の両側にスペースを書く(:: は中置演算子なのでスペースで囲うべき)。 また [1; 2; 3] と書く(; はデリミタなのでスペースを後置すべき)。 演算子の書き方演算子シンボルはスペースできちんと区切るよう注意しよう。 数式が読みやすくなるだけでなく、 複数文字から構成される演算子との混同を避けられる。 (この規則の自明な例外: !と.演算子は引数との間を区切らない) 例: x + 1 や x + !y と書く。
長い文字列の書き方1行に収まりきらない文字列は、慣用として各行の終端に文字列継続の識別子をおいてインデントする(行の終端の文字 \ により次の行の先頭の空白列が無視される)。 (訳注: これは良くないと思う。\ の後ろに見えない空白を付けてしまったら何が起こるんだっけ。という話はC言語でもあった気がする。かわりに ^演算でくっつけるのが推奨。) プログラムのインデント
この法則に付け足し：注意深くインデントを付けよ。本当にプログラムの意味を決めることがある。 プログラムのインデントとは、多くの強固な考え方を想起させるアートである。 ここで経験上得られた、がまだ厳しい批評にはさらされていない インデントスタイルを幾つか示す。 スタイルが妥当だとわたしが明白に思えたとき、その妥当性を示した。 一方で批判も記した。 なので、いつも提案したスタイルの中から選ぶこと。 まず絶対の規則を記した。 インデントの一貫性インデントは一般に受け入れられているスタイルを選んで、 アプリケーション全体を通して統一的に使いなさい。 ページの幅ページは80カラム幅です。
ページの高さ関数は1画面(およそ70行)に納めること。例外ケースは2つ、せいぜい3つ以内にする。それ以上は無茶。
インデントの量一般的に、プログラムの上下の行のインデント変化量はスペース1〜2個である。 インデント量を決めたらプログラム中でそれを変えないこと。 タブタブキャラクタ(ASCII文字9)を使用するのは、まるで推奨しない。
大域 let ... ;; 定義のインデントの仕方一般に、モジュール内でグローバル定義された関数本体は普通にインデントする。 しかし、このケースでは特に、定義をより強調するのも良い。
let f x = function | C -> | D -> ...;; let g x = let tmp = match x with | C -> | x -> 0 in tmp + 1;; 他の慣習も許容されている。例えば :
let f x = function | C -> | D -> ...;;
let f x =
let tmp = ... in
try g x with
| Not_found ->
...;;
let ... in のインデントlet での定義に続く式は、キーワードletと同じ位置にインデントし、 その定義に出てくるキーワード in は行末に書く。 let expr1 = ... in expr1 + expr1 let 定義が続くときも、このルール、つまり 同じインデントレベルで定義を書くようにする。 let expr1 = ... in let n = ... in ...
変化: キーワード in は計算の最後の式のあとに別個に一行で単独で書くことがある。 let e1 = ... in let e2 = ... in let new_expr = let e1' = derive_expression e1 and e2' = derive_expression e2 in Add_expression e1' e2' in Mult_expression (new_expr, new_expr);;
if then else のインデント複数の条件分岐複数の条件分岐の条件が同じインデントレベルになるように書く。 if cond1 ...
if cond2 ...
if cond3 ...
もし条件文の長さや式が短ければ例えば以下のように書く: if cond1 then e1 else
if cond2 then e2 else
if cond3 then e3 else
e4
もし複数の条件分岐の中の式が囲いを必要とする場合(例えば複文を含むとき) はこう書く: if cond then begin
e1
end else
if cond2 then begin
e2
end else
if cond3 then ...
複数の条件分岐について他の方法も提案されている。 キーワード else から行を始める方法: if cond1 ...
else if cond2 ...
else if cond3 ...
繰り返すが、どれかスタイルを選んだら一貫して使うように。 * 単独の条件分岐条件分岐が単独である場合については、条件式の長さや、 特に式に begin-end デリミタがあるかどうかにに応じて、 スタイルがいくつかある。 条件分岐にデリミタがある場合はいくつかのスタイルがある：
if cond then begin
e1
end else begin
e2
end
if cond then
begin
e1
end else begin
e2
end
実際には、条件節のインデントは構成する式の長さに依存する。
if cond then e1 else e2
5. e1 には begin .. end があるのに e2 が短い場合 if cond then begin
e1
end else begin
e2
end
あるいは if cond then begin
e1
end else e2
パターンマッチングのインデント* 大原則パターンマッチの各節は、最初のも含め縦棒で始める。
全てのパターンマッチング節は、 最初の節も含め、縦棒で始め、その縦棒で揃える。 節の中の式が1行に収まらない場合は、節のなかにある矢印の直後で改行する。そして普通にその節のパターン部分の先頭に揃えてインデントする。 パターンマッチング節の矢印は並べない。 * match あるいは trymatch や try はその構文の最初と節を揃える: match lam with
| Abs (x, body) -> 1 + size_lambda body
| App (lam1, lam2) -> size_lambda lam1 + size_lambda lam2
| Var v -> 1
try f x with
| Not_found -> ...
| Failure "not yet implemented" -> ...
キーワード with は行末に置く。with の前の式が1行に収まらないときには 1 行に with だけを置く: try
let y = f x in
if ...
with
| Not_found -> ...
| Failure "not yet implemented" -> ...
* 節の中の式のインデントパターンマッチの矢印の右の式が長い時は矢印の後ろで切る。 match lam with
| Abs (x, body) ->
1 + size_lambda body
| App (lam1, lam2) ->
size_lambda lam1 + size_lambda lam2
| Var v -> 1
プログラマによっては式のうち1つでも溢れたら ルールを一般化して全ての節に適用する。すると最後の節はこうなる。 | Var v ->
1
他には、これをもっと押し進めて、 このルールをどのパターンマッチの節に対しても統一的に適用する。 let rec fib = function
| 0 ->
1
| 1 ->
1
| n ->
fib (n - 1) + fib ( n - 2);;
* 匿名関数の中のパターン・マッチングfunction で始まる無名関数のマッチはmatch や try と同様、 function キーワードに揃えてインデントする。 map
(function
| Abs (x, body) -> 1 + size_lambda 0 body
| App (lam1, lam2) -> size_lambda (size_lambda 0 lam1) lam2
| Var v -> 1)
lambda_list
* 名前つき関数のパターンマッチングlet や let rec で定義される関数中のパターンマッチングでは、 さきほどのパターンマッチングのルール(匿名関数でのもの) に従うような 妥当なスタイルが幾つかある。 インデントスタイルは大域定義の項で説明している。 どれかよいものを選べば良いが、いつも同じスタイルを使うように！ let rec size_lambda accu = function
| Abs (x, body) -> size_lambda (succ accu) body
| App (lam1, lam2) -> size_lambda (size_lambda accu lam1) lam2
| Var v -> succ accu
let rec size_lambda accu = function | Abs (x, body) -> size_lambda (succ accu) body | App (lam1, lam2) -> size_lambda (size_lambda accu lam1) lam2 | Var v -> succ accu パターンマッチングでの悪いインデント* 関数と場合分けのインデントを悲惨にをしない。これは前述指導した通り、 match や function キーワード揃えるようなインデントを含む。 こんな風に書いてはいけない: let rec f x = function
| [] -> ...
...
そうではなく、let キーワードに揃えたインデントをする: let rec f x = function
| [] -> ...
...
* パターンマッチングの各節での -> 識別子で揃えるような悲惨なことをしない以下のコードで例示するような パターンマッチングの矢印でいちいち揃えるのは悪い習慣だと思う: let f = function
| C1 -> 1
| Long_name _ -> 2
| _ -> 3;;
関数呼び出しのインデント* 関数名でインデント:大量の引数または複雑な引数(1行に収まらない)を伴う関数を除き、問題は起きない。 式は関数名のところ(慣習によりスペース1個か2個付け足しても良い) にインデントする。小さい引数は同一行に書いて、引数の頭で改行する。 複雑な式で構成される引数はなるべく避けること: そういう場合はでかい引数は let 構文で定義する。
追加の妥当性: 引数の評価時に副作用が発生する場合は、評価順序をわかりやすく定めるために実際 let 束縛が必要だ。* 複雑な引数には名前を付ける以下のかわりに、 let temp =
f x y z
``large
expression''
``other large''
expression'' in
...
こう書く let t =
``large
expression''
and u =
``other large''
expression'' in
let temp =
f x y z t u in
...
* 匿名関数に名前を付ける複雑な関数を引数に取るイテレータの場合、 let 束縛で関数を定義するほうが賢明だ。 以下のかわりに List.map
(function x ->
blabla
blabla
blabla)
l
こう書く let f x =
blabla
blabla
blabla in
List.map f l
演算子のインデント演算子が複雑な引数を取るとき、または同じ演算子を何度も呼び出すときは、 演算子が行末にくるようにし、残りの演算はインデントしない。 例えば (末尾に付いている垂直線 | で示したところが行の右端であるとする)、 x + y + z + | t + u |
このような演算列において「長い式」がある場合は、 そこでインデントするよりも、その「長い式」を let...in 構文で定義するほうが望ましい。 以下のかわりに x + y + z + | ``large | expression'' | こう書く let t =
``large |
expression'' in |
x + y + z + t |
演算を組み合わせる場合、 一つの演算に書き下せない程長い式になってしまうときは 確実に束縛すること。 こんな読みにくい式ではなく (x + y + z * t) / | (``large | expression'') | こう書く let u = ``large | expression'' in | (x + y + z * t) / u | この指針は全部の演算子に拡張される。例えば let u = ``large | expression'' in | x :: y :: | z + 1 :: t :: u | プログラミングガイドラインプログラミングの方法Always put your handiwork back on the bench, and then polish it and re-polish it. 手作りの作品は常に作業台の後ろにおいておき、 磨いて磨いてまた磨くのだ。 簡潔明瞭なプログラムを書く書いたら読み返して、もっとシンプルに明解にする。 創造するどの段階でも頭を使え！ プログラムは小さな関数に細分化する小さい関数のほうがより把握しやすい。 別々の関数で繰り返し定義されているコードを括り出すコードの共有化は、 コード修正や改良すればそれがプログラム全体にに勝手にひろがるわけなので、 メンテナンスの容易性を獲得する。 さらに、 コード部分を分離して命名する、そんな単純なことで、 気づかなかった特徴を特定できるようになる。 コードをコピペしないコードを貼り付ける行為は、ほぼ確実に、 コード共有化の不履行あるいは、 役に立つ補助関数を書いたり確認したりするのを放棄する ことを示している... 従ってこの行為は、プログラムのコード共有が失われていることを意味する。 コード共有をサボることはその後に控えるメンテナンスでより多くの問題を 抱えることを暗示している。 ペーストしたコードにバグがあれば、 バグが出るたびにコピーしたコード全部をそれぞれ修正しないといけない！ そのうえ10行で構成されたコードがプログラム中で20回も繰り返されていたら、 特定するのも難しい。 それとは対照的に、 その10行を補助関数として定義すれば、それらがどこで使われるのかを見つけるのは いともたやすい。単純な関数呼び出しになってるから。 もしいたるところでコードをコピペしようものなら、 プログラムの理解はさらに難しい。 結論としては、コピペしたコードは、 プログラムを読むのもメンテナンスするのも難しくするから、 追放しないとけない。 プログラムのコメントの付け方難しい箇所があるときにはコメントを遠慮なく付ける全然難しくないならコメントする意味はない。関数の本体内でのコメントは避ける関数の最初に一つコメントを付けるのが好ましい。その関数で使われているアルゴリズムがどう動くのか説明する。 繰り替え図が、全然難しくないのならコメントする意味はない。 有毒なコメントを避ける有毒なコメントとは、なんの付加価値もないコメント、つまり トリビアな情報しかない状態だ。 有毒なコメントには明らかに利子がない。 無駄に読者の興味を逸らすから迷惑だ。 ソフトウェアメソトロジーと呼ばれる類の奇妙な評価基準、 で計ることがしばしばある。 例えば コメントの量/コードの行数 の比は完璧に計測できるが、 私はこれの理論的、実用的な解釈を知らない。 有毒なコメントを絶対に避けること。 避けるべき例: 以下のコメントは、専門用語を使い、 関心を示す追加情報もなく、結果として本当のコメントのふりをしている。 (*
function print_lambda:
prints a lambda-expression passed as an argument.
Arguments: lam, a lambda expression of any kind.
Results: none.
Note: print_lambda can only be used for its side effect.
*)
let rec print_lambda lam =
match lam with
| Var s -> printf "%s" s
| Abs l -> printf "\\ %a" print_lambda l
| App (l1, l2) ->
printf "(%a %a)" print_lambda l1 print_lambda l2;;
モジュールインタフェースの使いかた関数の使いかたは、プログラムのなかの実装に表れるのではなく、 外部とやりとりするモジュールインタフェースに表れなければならない。 Caml システムのインタフェースモジュールのようなコメントをつけること。 そうすると後でモジュールインタフェースの文書化の際に、 必要に応じて自動的に展開してくれるかもしれない。 assert を使うできる限り assert を使う: 実行時に有益な検証をしてくれる上に冗長なコメントをしなくて済む。 例えば関数の引数の条件の有効性は assert により有効に検証される。 let f x = assert (x >= 0); ... また assert はコメントよりも信頼できることが多いのに注意。 assert は実行時にその度に検証するので、適切であることを強制されるが、 コメントはすぐに時代おくれになり、その後のプログラムの読解に 有害になってしまう。 命令型コードには1行ずつコメントを付ける難しいコード、特に 大量にメモリの破壊型変更(配列などのデータ構造のような物理的変更)をする 命令型のコードを書くときは、 コーディングしたアルゴリズムの実装の説明 をその関数本体内にコメントすべきだ。 さもなくばその関数のメンテナンスのために不変式の連続した変更を 余儀なくされる。 繰り返すが難しいところがあるなら、 コメントを必要に応じてプログラムの各行に書くべきだ。 識別子の付け方プログラムの該当部分の意味を喚起するような 識別子の名前を付けるのは大変だ。 用語の明解さと規則性を強調することを特に注意しないといけない。 グローバル名に略語を使わないグローバルな識別子(特に関数名)は長くて良い。 関数定義されたところから遠くはなれたところで使うときに、 その関数の目的を理解するために重要だ。 単語の区切りはアンダースコア (intOfString ではなく int_of_string)Camlでは大文字小文字の変更は意味がある。 大文字で始まる単語は OCaml では コンストラクタとモジュール名に予約されており、反対に 普通の変数(関数や識別子)は小文字で始まらないといけない。 これらの規則により、識別子における単語の区切りに大文字を使えない (最初の単語は識別子の始まりだ)。 ゆえに小文字であるべきであり、関数名に IntOfString を選択するのは禁止。 同じ意味の関数引数には同じ名前を常に付ける必要に応じ、用語体系をファイルの先頭でコメントに明示する。 同じ意味の複数の引数があるなら、それらに数字でサフィックスをつける。 ローカルの識別子は短くてよく、別の関数に使いまわせるように。これはスタイルの規則性を推進する。 l や O のような、1 や 0 と見間違えやすい識別子は避ける。 例: let add_expression expr1 expr2 = ... let print_expression expr = ... 識別子における単語の大文字区切り非推奨の例外として、 この命名規則を使う既存のライブラリとのインタフェースを取る場合には 許容される。 そのライブラリを使う Caml ユーザーは、 オリジナルのライブラリのドキュメントから容易に順応できる。 式中の括弧の使いかた括弧は重要だ:普通ではない優先順位を用いる必要があることを示している。 だから賢く使うべきであり、 プログラム中に手当たり次第にまき散らすべきではない。 そのためには、普通の優先順位、すなわち、 括弧が不要な演算の組み合わせを知る必要がある。 とても幸いなことに、 ちょっと数学を知っているか、以下の規則に従うよう努力すれば、 これは複雑なことではない。 算術演算子: 数学での規則と同じ例: 1 + 2 * x は 1 + (2 * x) の意味。 関数の適用: 数学で三角関数を使うときと同じ数学で sin x と書けば sin (x) のことだ。 同様に sin x + cos x は (sin x) + (cos x) であって sin (x+(cos x)) ではない。 Caml でもこれと同じ約束事が使える: f x + g x は (f x) + (g x) のことだ。 この約束事は、全ての中置記法の演算子に一般化できる: f x :: g x は (f x) :: (g x) のこと、 f x @ g x は (f x) @ (g x) のこと、 failwith s ^ s' は (failwith s) ^ s' であって failwith (s ^ s') じゃない。 比較と論理演算子:比較は中置演算子なのでさっきの規則が適用されるから、 f x < g x は (f x) < (g x) だ。 同じ形式で(他の解釈は存在しない)、 式 f x < x + 2 は (f x) < (x + 2) の意味になる。 同様に f x < x + 2 && x > 3 は ( (f x) < (x + 2) ) && (x > 3)だ。 論理演算子の優先順位は数学のそれと同じ数学者はこの場合括弧を酷使する傾向があるが、 論理演算子の "or" は加算と同じようなもので、 "and"は乗算と同じようなものだ。 だから、1 + 2 * x が 1 + (2 * x) であるのとまさに同様に、 true || false && x は true || (false && x) のことだ。 デリミタ(終端子)のつけかたプログラム中でデリミタ構文が必要であるときには、 括弧よりも begin ... end キーワードをデリミタに使う。 だが、一貫して、つまり統一的な方法で使うのであれば、括弧を使うのも許容される。 この構文の明示的な区切りは、本質的にはパターンマッチ構文、 あるいはif-then-else 構文に埋め込まれるシーケンス に関連する。 match 構文内のmatch 構文パターンマッチング節のなかに match...with や try...with が現れるときは、 この埋め込まれた構文のデリミタが必須である (さもなくば、外側のパターンマッチング構文の従属節が自動的に 内側パターンマッチ構文に関連づけられてしまう) 。例えば: match x with | 1 -> begin match y with | ... end | 2 -> ... if の分岐内のシーケンス同様に、条件文の then または else 節の中のシーケンスにも デリミタが必須。 if cond then begin e1; e2 end else begin e3; e4 end モジュールの使いかたモジュールの分割プログラムは筋の良いモジュールに分割しなければならない。 モジュールのぞれぞれに、インタフェースを明示しなければならない。 インタフェースのそれぞれに、モジュールで定義された諸々 (関数、型、例外など)をドキュメント化しなければならない モジュールのオープンopen ディレクティブは使わない。代わりに、識別子修飾記法を使う。 ゆえに、短いが意味の通ったモジュール名を好むことになるだろう。
let lim = String.length name - 1 in ... let lim = Array.length v - 1 in ... ... List.map succ ... ... Array.map succ ... モジュールを閉じたままにするか open するか環境を変更したり重要な関数群の別のバージョンを持ちこむ モジュールを open するのが普通かどうかを考えてみる。 例えば、Format モジュールは自動のインデント表示を供給する。 このモジュールは print_string, print_int, print_float などの 標準の表示関数を再定義する。 したがって、Format を用いるときはファイルの先頭で組織的に open する。 もし Format を open しない場合、 Format 内の多くの関数はデフォルトの環境(Pervasives)に相当のものがあるので、 表示関数の修飾を忘れてしまっても完全に平穏に見えてしまいます。 Format と Pervasives の表示関数の混在は微妙な表示バグの元となり、 追うのも大変です。 例えば、 let f () = Format.print_string "Hello World!"; print_newline ();; は、いんちきである。というのも、プリティプリンタの キューを空にして "Hello World!" と表示するために Format.print_newline を呼び出していないから。 かわりに "Hello World!" はプリティプリンタのキューに積まれ、 Pervasis.print_newline が復改を標準出力に出力する...。 もし Format がファイルに出力し、かつ標準出力が端末である場合、 ユーザーはファイルに復改がない (そしてファイルの中身を表示させると奇妙なことになり Format.print_newline によって閉じられるべきものはオープンされたまま) ことに気づき、かわりに画面にニセの復改が出現してひどい目にあうだろう！ 同じ理由から、 任意精度整数などのプログラム中で負担になる大きなライブラリは open する。 open Num;; let rec fib n = if n <= 2 then Int 1 else fib (n - 1) +/ fib (n - 2);;
型定義が共有されるプログラムでは、 実装部を含めない(型定義のみを含む) 一つ以上のモジュール定義を集めるのは良いことだ。 この場合、型定義の共有されるモジュール間で統一的に open するのは許容される。 パターン・マッチングパターン・マッチングの過剰使用を決して恐れるな!* 一方、不完全なパターン・マッチング構文を避けるよう注意せよ| _ -> ... や | x -> ... のような「全てを捕まえる」節を使わずに済む (例えばプログラム中で定義された具体型のマッチングの場合) なら使わずにおいて、慎重に完全な形にせよ。 次節のコンパイラの警告も見よ。 コンパイラの警告コンパイラの警告は潜在的誤りを防いでくれるはずだ。 ゆえにコンパイル時にそのような警告が出たら、 絶対にそれらに注意しつつプログラムを修正しなければならない。 その上、コンパイル時に警告が出るプログラムは、あなたの仕事にまるで 似合わないアマチュア臭がする。 パターン・マッチングの警告パターンマッチングに関する警告は、慎重に慎重を重ねて扱うこと:
let束縛の構造分解[英訳者註:「let束縛の構造分解」とは、同時に複数の式を複数の名前に束縛するものだ。タプルやリストのようなものに集めて束縛して名前をパックする。let 束縛が評価されるときにその集めたものが全部アンパックされて、式それぞれに対応する名前が束縛される。例えば let x, y = 1, 2 は let 束縛の構造分解によって let x=1 と let y=2 が同時に起きて束縛される。 let 束縛は単純な識別子の定義に限っていない。もっと複雑な。単純なパターンに使える。例えば
let の構造分解は完全であることパターンマッチングが完全である(パターンマッチが失敗しない)ような場合だけ、 let 束縛の構造分解を用いる。 したがって典型的には、 生成型(タプル又はレコード)の定義 単一ケースのバリアント型の定義に限られる。 他はいかなる場合でも、match...with構文を明示する必要がある。
シーケンスの警告と let _ = ...シーケンス中の式の型に関する警告をコンパイラが出すときは、 式の結果を無視することを明示すること。 以下の通り:
どの場合でも、警告を抑える最善の方法は、何故コンパイラが警告したのかを理解することだ。コンパイラは、あなたの書いたコードは役に立たない結果を求めさせている(計算した直後に結果を消している)から警告しているわけだから、それが役に立っているということは、その副作用のためだけ実行されているわけだから、unit を返すべきだ。 たいてい、警告は関数を間違って使っていることを示しており、大抵は結果に意味のある関数と副作用だけを持つバージョンの(結果が無関係の手続的な)関数と混同している。前記の例のように、最初のものはうまくいっているが、 map の代わりに iter を呼ぶべきであり、こう簡単に書ける: List.iter f l; print_newline () 実際のプログラムでは適切な(副作用だけの)関数が存在しないかも知れず、書かざるを得ないこともよくある。関数の手続き部分を関数的部分から注意深く手で分離すれば問題をエレガントに解決でき、できあがったプログラムの方が良く見える！例えば、この問題だらけの定義を: let add x y = if x > 1 then print_int x; print_newline (); x + y;; より明確な別々の定義に直せて: (この部分消失) let print_adder x = if x > 1 then print_int x; print_newline ();; let add x y = x + y;; それに応じて古い呼び出しは add に変わる。 どの場合でも let _ = ... 構文はまさに結果を無視したい場合に使う。 この構文で画一的にシーケンスを置き換えてはならない。
(List.) hd と tl 関数hdとtl関数は使わない。リストの引数のパターンマッチのほうが明解だ。
ループfor ループ配列もしくは文字列を単純になめる場合は for ループを使う。 for i = 0 to Array.length v - 1 do ... done ループが複雑かもしくは結果を返す場合は、再帰関数を使う。 let find_index e v = let rec loop i = if i >= Array.length v then raise Not_found else if v.(i) = e then i else loop (i + 1) in loop 0;;
while ループ
while ループの主な使い道は、無限ループ while true do ... である。(大抵はプログラムの中断による)例外により脱出する。 証明されたアルゴリズムを詰め込んだプログラムを持ち込むのでない限り、 他に while ループを使うのは困難である。
例外自前の例外を定義するのを恐れないこと。 ただし、一方で、可能な限りシステムであらかじめ定義されている例外を使うこと。 例えば、探索関数で失敗したときには定義済である Not_found 例外を上げるべきだ。 関数呼び出しによって上がった例外の処理は try...with を用いて慎重にすること。 全ての例外を try ... with _ -> で処理するのは、通常、 プログラムのメインの関数に予約されている。 アルゴリズムの不変式を扱うために全ての例外を捕捉する必要があるときは 不変式をリセットした後に、注意深く例外に名前を付けて再度例外を上げる。 典型的には、 let ic = open_in ... and oc = open_out ... in try treatment ic oc; close_in ic; close_out oc with x -> close_in ic; close_out oc; raise x
データ構造Caml の強力なところの一つに、定義可能なデータ構造のパワーと操る簡単さがある。 ゆえにこの利点を最大限利用しなければならない： 独自のデータ構造を遠慮せず定義すること。特に、 画一的に整数値で列挙したりブール値で２つの場合分けを列挙したりしないこと。 例: type figure = | Triangle | Square | Circle | Parallelogram;; type convexity = | Convex | Concave | Other;; type type_of_definition = | Recursive | Non_recursive;;
列挙型を整数でエンコードする場合、 受け付け可能な整数の範囲制限がとても困難である。 コンストラクタ関数を定義してプログラムの不変性を保証せねばならない(訳注：？) (直接構築している値がないことを後で検証する必要もある)。 あるいはプログラム中に assert を入れ、パターンマッチでガードするか。 これは良い習慣ではない。 この問題は要約型(和型)を定義すればエレガントに解決でき、 さらに特典として、 パターンマッチングとコンパイラによる徹底検証の力をまるごと享受できる。
| Let (_, v, e) as def -> if recursivep def then ``code for recursive case'' else ``code for non recursive case'' あるいは recursivep がブール値を適用可能なら | Let (b, v, e) -> if recursivep def then``code for recursive case'' else ``code for non recursive case'' 明示的コーディングと対照的だ: | Let (Recursive, v, e) -> ``code for recursive case'' | Let (Non_recursive, v, e) -> ``code for non recursive case'' 二つのプログラムの違いは微妙で、単なる好みの問題と思うかもしれない。 だが、明示的なコーディングは変更に対してより強く、 言語に良くフィットしているのは決定的である。 反対に、true/false が構造的に明確にわかるようなブール値のフラグとして 新しい型を画一的に定義する必要はない。以下の型定義の有用性は疑問だ: type switch = | On | Off;; type bit = | One | Zero;; 同様の異論として整数で代用する列挙型も、 その整数がデータ表現を明確に表しているときは許容できる。 破壊可能変数の使いどころ破壊可能変数(値) は有益で、ときどきは単純で明確なプログラムに不可欠となる。 にもかかわらず、Caml の普通のデータ構造は不変値であることを認識しつつ 使わねばならない。 このことは、明解で安全なプログラムのための許容範囲として好まれる。 イテレータCamlのイテレータは強力で役に立つ特徴だ。 しかし過剰に使ったり、逆に無視したりしてはならない。 イテレータはライブラリとして供給されており、 正確でありライブラリ作者が良く考え抜いているだろう。 だから再発明は無駄だ。 ゆえに、こう書く: let square_elements elements = map square elements;; これよりも let rec square_elements = function | [] -> [] | elem :: elements -> square elem :: square_elements elements;; いっぽう、こう書いてはいけない let iter f x l = List.fold_right (List.fold_left f) [List.map x l] l;; こちらの方が良い val iter : ('a list -> 'a -> 'a list) -> ('a -> 'a) -> 'a list -> 'a list =
<fun>
# iter (fun l x -> x :: l) (fun l ->5; List.rev l) [[1; 2; 3]] ;;
- : int list list = [[1; 2; 3]; [3; 2; 1]]
必要に応じて慎重に説明のためのコメントを付けること: 絶対必要！というのが私の意見だ。 プログラムの最適化方法
何より単純明解なプログラムであること。 ボトルネック(一般には2、3のルーチン)が特定されるまで最適化を始めないこと。 そして最適化は何よりも使っているアルゴリズムの複雑度の変更からだ。 これはしばしば操作するデータ構造の再定義をすることになり、 プログラムの困難な該当部分を完全に書き直すことになる。
クラスとモジュールの選択方法継承、つまりデータや機能をインクリメンタルに洗練していくことが必要なら、 OCaml のクラスを使うべき。 パターンマッチングが必要なら、従来のデータ構造(特にバリアント型)を 使うべき。 データ構造が固定されており、その機能も同様に固定されているかもしくは 新しい関数を使うところで追加するので十分ならば、モジュールを使うべき。 Caml コードの透明さCaml言語には単純明解なプログラミングのための強力な構文がある。 極めて明瞭なプログラムを得るための問題はおもに、その構文を適切に使うことだ。 言語は多数のプログラミングスタイル(またはプログラミングパラダイム) によって特徴づけられる: 命令型プログラミング(状態と割り当ての概念に基づく)、 関数型プログラミング(関数、関数の結果、(λ)計算の概念に基づく)、 オブジェクト指向プログラミング( 状態と、状態を変更する手続きやメソッドをまとめたオブジェクトの概念に基づく)。 プログラマの最初の仕事は、当面の問題にもっとも当てはまるプログラミング パラダイムを選択することだ。 プログラミングパラダイムの中から一つを用いるときに難しいのは、 アルゴリズムを実装した計算するための自然で単純な式表現を、 その言語で構築することだ。 スタイルの危険性プログラミングスタイルについて、普通２つの対照的な問題行動があり得る。 片方は「全部命令型」の手段(画一的にループと変数割り当てを使う)で、 もう片方が「純粋な関数型」の手段(ループも変数割り当ても一切無し)だ。 100%オブジェクト指向スタイルは将来現れるに違いないが、 (幸い)ここで論議するにはまだ新しすぎる。
let list_length l = let l = ref l in let res = ref 0 in while !l <> [] do incr res; l := List.tl !l done; !res;; かわりに以下の再帰関数で書けば単純明快だ。 let rec list_length = function | [] -> 0 | _ :: l -> 1 + list_length l;; (この二つのバージョンが等価かどうかについては脚注を見よ)
一般に読めないと思われる Caml コードCaml言語は簡潔明瞭なプログラミングのための強力な構文を備える。 しかし、これらの強力な構文はまた、無駄に複雑なコードを書いてしまい、 全く読めないプログラムにさえ行き着く。 幾つかこの手段が知られている：
let flush_ps () =
if not !psused then psused := true;;
または(まだ微妙) let sync b =
if !last_is_dvi <> b then begin last_is_dvi := b end;;
(fun x y -> x + y)
e1 e2
これは以下のことだ。 let x = e1 and y = e2 in x + y
あなたが print_string "Hello world!" をこのような方法で自然に書き下せるのなら、 作品を Obfuscated Caml Contest に提出できるのは疑うべくもない。 プログラム開発の管理小さいチームで大きく複雑なプログラムを開発する好例である コンパイラ開発に従事するベテランの Caml プログラマから秘訣をもらった。 プログラムの編集方法多くの開発者はプログラムを書くのに使っている Emacs エディタ(GNU-Emacs) をある種の尊敬を抱いている。 Caml のソースコードを文法的に色分けしてくれる (違うカテゴリの単語、例えばキーワードをカラーでレンダリングする)ので、 エディタは言語にとても直結している。 以下の2つのコマンドが不可欠だと思われる:
この機能の使いかたを説明する: CTRL-c CTRL-c の組み合わせでアプリケーション全体をリコンパイルする。 エラーがあったら続けて CTRL-x-` コマンドによって 出力されたエラーを全部訂正できる。 そしたらまた CTRL-c CTRL-c でリコンパイルを起動して繰り返せば良い。 他のEmacsトリックESC-/ (dynamic-abbrev-expand) コマンドは、 編集中のファイル内に登場する単語のうちカーソルの直前に出てきた 単語を自動補完する。 これにより、プログラム中の長い名前をタイプするという退屈作業なしに、 いつも重要な識別子を選んで付けることができる: 最初の文字の後で ESC-/ とすれば簡単に識別子を補完できる。違う補完をしたときも、 続けて ESC-/ とすれば別の補完をしてくれる。 Unix 配下では、 CTRL-c CTRL-c か Meta-x compile の組み合わせに続けて CTRL-x -` がさらに Caml プログラムのなかにある特定文字列を見つけるのに使える。 make を起動してリコンパイルするかわりに grep を起動させれば、 grep の「エラーメッセージ」相当のものということで、 CTRL-x-' で自動的に見つけた文字列のところに飛んでくれる。 対話システムによる編集方法Unix 配下の場合: ラインエディタ ledit は素晴らしい編集能力を持つ Emacs 風のエディタだ (ESC-/もある！)。以前にタイプしたコマンドを復元するヒストリ機能もあり、 別のセッションのコマンドも復元できる。 ledit は Caml で書かれており、ここからフリーでダウンロードできる。 コンパイル方法make ユーティリティはプログラムのコンパイル、再コンパイルの管理に不可欠だ。 Makefile のサンプルは The Hump にあるし、Caml コンパイラの Makefile も 参考になるだろう。 チームでの開発方法: バージョン管理CVSというソフトウェアバージョン管理システムは、 決して生産性の向上させるために走らるのではない。 このシステムはプログラマチームによる開発管理をサポートする。 チームの一貫性を強制し、ソフトウェア作製に関する多くの変更を管理する。 CVS はまた複数のチームによる同時開発もサポートしており、 インターネットでリンクされたサイト間で分散共有できる。 Caml コンパイラは全て CVS 配下である。 anonymous CVS サーバ (camlcvs.inria.fr)はCamlコンパイラの 開発コードや他の Caml 関連ソフトウェアのソフトを抱えている。 CVSサーバを利用するとコンパイラを手元にコピーできたり、 更新も簡単にできる(手元の Caml ソースディレクトリで cvs update と打てばよい) 脚注命令型と関数型それぞれのバージョンの list_length二つの list_length は複雑さの点では完全には一致しない。 命令型のバージョンは定数サイズのスタックを実行時に使うが、 関数型バージョンは中断した再帰呼び出し (最大値が引数のリストの長さに等しい)の戻りアドレスを格納する必要がある。 関数プログラムの実行時に定数サイズのスペースだけ消費してほしいのなら、 末尾再帰(tail-rec) で関数を書けば良い。 すなわち、関数が再帰呼び出しで終わるようなものだ (呼び出された再帰関数が戻る処理が要らない)。 中間結果としてアキュムレータ(積算変数)を用いるとこのように書ける let list_length l = let rec loop accu = function | [] -> accu | _ :: l -> loop (accu + 1) l in loop 0 l;; この方法によって、 命令型プログラムと同様の特性を持つプログラムになった。 さらに パターンマッチングと再帰によって再帰の sum データ型に属する 引数をハンドリングしているというように、 アルゴリズムが、明快で自然に見えるようになった。 |
|
|
Modified by ukai.
Powered by PukiWiki Plus! 1.4.7plus-u2-i18n/PHP 5.4.16. HTML convert time to 1.571 sec. |
|
