Wikipedia

プログラム書法

プログラミング・スタイルの要素（邦訳「プログラム書法」）は、プログラム書法の手引き書であり、コンピュータ・プログラムがコンパイラや個人のプログラミング「スタイル」を満足させるに留まらず、人間にとっての「読みやすさ」、特にソフトウェア保守エンジニア、プログラマー、テクニカルライターによる理解を重視すべきだという考え方を提唱した。原著初版は1974年に出版された。

ファイル:The Elements of Programming Style.jpg
Cover of the second edition
著者 Brian W. Kernighan and P. J. Plauger

木村泉（訳）

出版 McGraw-Hill

共立出版（訳本）

出版年
 1978

1982（訳本）

頁数 168 ページ
ISBN 978-0070342071

本書はタイトルと文体に、ストランク＆ホワイト著の『スタイルの要素』へのオマージュを表し、エドガー・ダイクストラの構造化プログラミングの議論の実践的な土台とみなされている。この本は大きな影響力を持ち、The Elements of C Programming Style, The Elements of C# Style, The Elements of Java(TM) Style, The Elements of MATLAB Style (いずれも邦訳なし) など、個々の言語に合わせた同様の教本を生み出している。

本書は、プログラミングの教科書に実際に掲載された短いプログラムを例題として取り上げており、その結果、抽象的で学術的な議論というよりは、実践的な手法となっている。本書の書き方はそつがなく、全般的に同情的な批評でありつつ、遠慮なく切り込んでいる。誤りのいくつかは自身の著書のものである（一つは第1版の誤りを第2版で取り上げた）。

格言 編集

教訓は、各セクションの最後に「汚れ仕事は機械にやらせよう」といった簡潔な格言としてまとめられている。※現代語に一部置き換えたため、訳本の訳とは必ずしも一致しない。尚、functionは「関数」と訳されるが「機能」の意をもち、両義的に使われるため、直訳では原意を十分に伝えきれない。

  1. Write clearly – don't be too clever. わかりやすく書こう - うますぎるプログラムはいけない
  2. Say what you mean, simply and directly. いいたいことを単純素直にいおう
  3. Use library functions whenever feasible. ライブラリ関数を使おう
  4. Avoid too many temporary variables. 一時変数はなるべく使わないこと
  5. Write clearly – don't sacrifice clarity for efficiency. わかりやすく書こう - 効率のためにわかりやすさを犠牲にしてはいけない
  6. Let the machine do the dirty work. 汚れ仕事は機械にやらせよう
  7. Replace repetitive expressions by calls to common functions. 同じ表現の繰り返しは共通関数の呼び出しに変えよう
  8. Parenthesize to avoid ambiguity. 括弧を使って誤解を避けよう
  9. Choose variable names that won't be confused. 混同の恐れのない名前を使おう
  10. Avoid unnecessary branches. 無用な分岐は避けよう
  11. If a logical expression is hard to understand, try transforming it. 論理表現がわかりにくいときは表現を変えよう
  12. Choose a data representation that makes the program simple. プログラムが単純になるようデータ表現を選ぼう
  13. Write first in easy-to-understand pseudo language; then translate into whatever language you have to use. わかりやすい擬似コードで書いてから実際の言語に落とそう
  14. Modularize. Use procedures and functions. モジュール化し、手続きと関数を使おう
  15. Avoid gotos completely if you can keep the program readable. 読みやすさを保てる限り、GOTO文は避けよう
  16. Don't patch bad code – rewrite it. ダメなコードを直すのはやめて、書き直そう
  17. Write and test a big program in small pieces. 大きいプログラムは小さい部分に分けて書き、テストしよう
  18. Use recursive procedures for recursively-defined data structures. 再帰的に定義されたデータ構造には再起手続きを使おう
  19. Test input for plausibility and validity. 入力の妥当性と有効性をテストしよう
  20. Make sure input doesn't violate the limits of the program. 入力がプログラムの限界を超えていないことを確認しよう
  21. Terminate input by end-of-file marker, not by count. 入力はファイル終端で終了するようにし、回数指定に頼らない
  22. Identify bad input; recover if possible. ダメな入力を特定し、できれば回復しよう
  23. Make input easy to prepare and output self-explanatory. 入力データは準備しやすく、出力はわかりやすく
  24. Use uniform input formats. 共通の入力フォーマットを使おう
  25. Make input easy to proofread. 簡単に確認できる入力形式に設計しよう
  26. Use self-identifying input. Allow defaults. Echo both on output. 意味のわかりやすい入力を使おう。デフォルトを許容しよう。出力時に両方とも表示しよう。
  27. Make sure all variables are initialized before use. 全ての変数を使用前に初期化しよう
  28. Don't stop at one bug. バグをひとつ見つけたところで止まってはいけない
  29. Use debugging compilers. デバッグ機能付のコンパイラを使おう
  30. Watch out for off-by-one errors. 桁ずれのエラーに注意
  31. Take care to branch the right way on equality. 条件分岐時の等号を正しく扱おう
  32. Be careful if a loop exits to the same place from the middle and the bottom. ループの真ん中や最後から同じ所に抜けるときは気をつけよう
  33. Make sure your code does "nothing" gracefully. 何もしないはずのコードが余計なことをしないようにしよう
  34. Test programs at their boundary values. 境界値でテストしよう
  35. Check some answers by hand. 出力のいくつかを正解と比べて確認しよう
  36. 10.0 times 0.1 is hardly ever 1.0. 10.0×0.1が1.0になると考えてはいけない
  37. 7/8 is zero while 7.0/8.0 is not zero. 7/8はゼロだが7.0/8.0はゼロではない　※整数演算と小数演算に注意
  38. Don't compare floating point numbers solely for equality. 浮動小数点数が等しいかどうかだけで比較してはならない　※同値に複数の表現があり得る
  39. Make it right before you make it faster. 速くする前に正しくしよう
  40. Make it fail-safe before you make it faster. 速くする前にフェールセーフにしよう
  41. Make it clear before you make it faster. 速くする前にわかりやすくしよう
  42. Don't sacrifice clarity for small gains in efficiency. わずかな効率向上のためにわかりやすさを犠牲にしてはいけない
  43. Let your compiler do the simple optimizations. 簡単な最適化はコンパイラに任せよう
  44. Don't strain to re-use code; reorganize instead. コードを兼用しようとせず、組み直そう
  45. Make sure special cases are truly special. 特例が本当に特例かを確認しよう
  46. Keep it simple to make it faster. 速くする前に単純さを保とう
  47. Don't diddle code to make it faster – find a better algorithm. 速くするためにはコードをこねくり回すのでなく、よりよいアルゴリズムを探そう
  48. Instrument your programs. Measure before making efficiency changes. 効率改善の前にプログラムを計測しよう
  49. Make sure comments and code agree. コメントとコードを一致させよう
  50. Don't just echo the code with comments – make every comment count. コメントはコードのオウム返しではなく、意味あるものにしよう
  51. Don't comment bad code – rewrite it. ダメなコードにコメントするのはやめ、コードを書き直そう
  52. Use variable names that mean something. 意味のわかる変数名をつけよう
  53. Use statement labels that mean something. 意味のわかるステートメントラベルをつけよう
  54. Format a program to help the reader understand it. 読みやすいようにプログラムをレイアウトしよう
  55. Document your data layouts. データのレイアウトをドキュメント化しよう
  56. Don't over-comment. コメントしすぎないようにしよう

現代の読者は、この本の例題が、現在はあまり使われなくなった古い手続き型プログラミング言語（FortranやPL/I）を取り上げていることを欠点と感じるかもしれない。本書が書かれたときには、現在の言語はほとんどなかった。しかし、一般的にスタイルや構造的な問題に関わる本書の指摘の多くは、特定の言語の詳細を超越していると言って良い。

受容 編集

キロボー・マイクロコンピューティングには、「他社が使うプログラムを書くなら、この本を読むべきだ。プロのプログラマーになるつもりなら、この本は必読だ」と述べられている。[1]

参考文献 編集

  1. ^ Reeves, Jack W. (1980年1月). “The Elements of Programming Style”. Kilobaud Microcomputing: pp. 9. https://archive.org/stream/kilobaudmagazine-1980-01/Kilobaud_Microcomputing_1980_January#page/n7/mode/2up 2014年6月23日閲覧。 

External links 編集

「https://ja.wikipedia.org/w/index.php?title=プログラム書法&oldid=96924355」から取得