プログラム書法
『プログラム書法（The Elements of Programming Style）』は、1974年に出版されたプログラミングスタイルに関する手引書であり、ソフトウェアの保守性、プログラマー、テクニカルライターにとっての理解のしやすさを重視すべきという考え方を提唱しました。この書籍は、ストランク＆ホワイト著の『スタイルの要素』に敬意を表し、エドガー・ダイクストラの構造化プログラミングの議論を実践的に示すものとして位置づけられています。
本書は、プログラミングの教科書に掲載された短いプログラムを例題として取り上げ、具体的な改善点を示しています。抽象的な議論に終始せず、実践的な手法に焦点を当てた点が特徴です。著者たちは、例題に対する批評を、時に優しく、時に厳しく行い、誤りのいくつかは自身の著書から引用しています。
この本の影響力は大きく、『The Elements of C Programming Style』、『The Elements of C# Style』、『The Elements of Java(TM) Style』、『The Elements of MATLAB Style』など、特定のプログラミング言語に合わせた多くの派生書籍を生み出しました。これらの書籍は、本書の原則をそれぞれの言語の文脈で具体化し、より実践的な指針を提供しています。
本書の各セクションの最後には、「汚れ仕事は機械にやらせよう」といった簡潔な格言がまとめられています。以下に、本書に掲載されている格言をいくつか紹介します。
わかりやすく書こう - うますぎるプログラムはいけない: コードは読みやすく、理解しやすいように書くべきです。
いいたいことを単純素直にいおう: 複雑な表現は避け、意図を明確に伝えましょう。
ライブラリ関数を使おう: 既存の機能は積極的に活用し、コードの重複を避けましょう。
一時変数はなるべく使わないこと: 不必要な変数の使用は、コードの可読性を低下させます。
効率のためにわかりやすさを犠牲にしてはいけない: 効率だけを追求せず、可読性を優先しましょう。
汚れ仕事は機械にやらせよう: 手動でできることは、できる限り自動化しましょう。
同じ表現の繰り返しは共通関数の呼び出しに変えよう: コードの重複は保守性を低下させます。関数化して再利用しましょう。
括弧を使って誤解を避けよう: 曖昧さを排除し、コードの意図を明確にしましょう。
混同の恐れのない名前を使おう: 変数名や関数名は、役割を明確に示すものにしましょう。
無用な分岐は避けよう: 不要な分岐はコードを複雑にします。
論理表現がわかりにくいときは表現を変えよう: 複雑な論理式は、より単純な形式に書き換えましょう。
プログラムが単純になるようデータ表現を選ぼう: 適切なデータ構造は、コードを簡潔にします。
わかりやすい擬似コードで書いてから実際の言語に落とそう: 実装前に、アルゴリズムを明確化しましょう。
モジュール化し、手続きと関数を使おう: コードを機能ごとに分割し、再利用性を高めましょう。
読みやすさを保てる限り、GOTO文は避けよう: GOTO文は、コードの流れを複雑にします。
ダメなコードを直すのはやめて、書き直そう: 修正が難しいコードは、最初から書き直した方が良いでしょう。
大きいプログラムは小さい部分に分けて書き、テストしよう: 分割統治法で、開発効率を高めましょう。
再帰的に定義されたデータ構造には再帰手続きを使おう: 再帰は、適切な箇所で効果を発揮します。
入力の妥当性と有効性をテストしよう: 不正な入力は、プログラムの異常終了を引き起こします。
入力がプログラムの限界を超えていないことを確認しよう: 適切なエラー処理を行いましょう。
入力はファイル終端で終了するようにし、回数指定に頼らない: より柔軟な入力を実現しましょう。
ダメな入力を特定し、できれば回復しよう: ユーザーフレンドリーなプログラムを心がけましょう。
入力データは準備しやすく、出力はわかりやすく: ユーザビリティを考慮しましょう。
共通の入力フォーマットを使おう: 統一された形式は、扱いやすいデータになります。
簡単に確認できる入力形式に設計しよう: エラーの早期発見に繋がります。
意味のわかりやすい入力を使おう。デフォルトを許容しよう。出力時に両方とも表示しよう: ユーザーが意図した通りの操作ができるようにしましょう。
全ての変数を使用前に初期化しよう: 未初期化の変数は、予期しない動作を引き起こします。
バグをひとつ見つけたところで止まってはいけない: バグは、複数存在する可能性があります。
デバッグ機能付のコンパイラを使おう: デバッグツールは、効率的な開発を支援します。
桁ずれのエラーに注意: 境界値のエラーは、見つけにくいことがあります。
条件分岐時の等号を正しく扱おう: 等号の使い分けは、正確な処理に不可欠です。
ループの真ん中や最後から同じ所に抜けるときは気をつけよう: コードの流れが複雑になる場合は、簡略化を検討しましょう。
何もしないはずのコードが余計なことをしないようにしよう: 意図しない副作用は、バグの原因になります。
境界値でテストしよう: 境界値は、バグが見つかりやすい箇所です。
出力のいくつかを正解と比べて確認しよう: 計算結果が正しいか、確認しましょう。
10.0×0.1が1.0になると考えてはいけない: 浮動小数点演算には、誤差が発生します。
7/8はゼロだが7.0/8.0はゼロではない: 整数演算と浮動小数点演算の違いに注意しましょう。
浮動小数点数が等しいかどうかだけで比較してはならない: 誤差を考慮し、一定の範囲内で比較しましょう。
速くする前に正しくしよう: 正確なプログラムが最優先です。
速くする前にフェールセーフにしよう: エラーが発生した場合の処理も考慮しましょう。
速くする前にわかりやすくしよう: 可読性は、保守性に影響します。
わずかな効率向上のためにわかりやすさを犠牲にしてはいけない: 可読性とのバランスを考えましょう。
簡単な最適化はコンパイラに任せよう: コンパイラは、最適化の専門家です。
コードを兼用しようとせず、組み直そう: 不必要な再利用は、コードを複雑にします。
特例が本当に特例かを確認しよう: 特例は、コードを複雑にする要因になります。
速くする前に単純さを保とう: シンプルなコードは、理解しやすく、保守しやすいです。
速くするためにはコードをこねくり回すのでなく、よりよいアルゴリズムを探そう: アルゴリズムの改善は、大きな効果を生みます。
効率改善の前にプログラムを計測しよう: 計測結果に基づき、ボトルネックを特定しましょう。
コメントとコードを一致させよう: コメントは、コードの理解を助けるために書くものです。
コメントはコードのオウム返しではなく、意味あるものにしよう: コメントは、コードの意図を説明するものです。
ダメなコードにコメントするのはやめ、コードを書き直そう: 悪いコードをコメントでごまかしてはいけません。
意味のわかる変数名をつけよう: 変数名は、コードの意図を明確に示すものにしましょう。
意味のわかるステートメントラベルをつけよう: ラベルは、コードの可読性を向上させるものです。
読みやすいようにプログラムをレイアウトしよう: 整形されたコードは、読みやすいです。
データのレイアウトをドキュメント化しよう: データ構造は、プログラムの理解を深めます。
コメントしすぎないようにしよう: 不要なコメントは、コードの可読性を低下させます。
本書で取り上げられている例題は、古い手続き型プログラミング言語（FortranやPL/I）を対象としているため、現代の読者には古く感じるかもしれません。しかし、本書で示されている原則は、特定の言語に依存しない普遍的なものであり、現代のプログラミングにおいても非常に重要です。
キロボー・マイクロコンピューティングは、「他社が使うプログラムを書くなら、この本を読むべきだ。プロのプログラマーになるつもりなら、この本は必読だ」と述べています。これは、本書がプログラマーにとって非常に価値のあるものであることを示しています。
B. W. Kernighan and P. J. Plauger, The Elements of Programming Style, McGraw-Hill, New York, 1974. ISBN 0-07-034199-0
B. W. Kernighan and P. J. Plauger, The Elements of Programming Style 2nd Edition, McGraw Hill, New York, 1978. ISBN 0-07-034207-5
J. Plauger selected quotes from The Elements of Programming Style
Elements of Programming Style – 2009 Brian Kernighan talk at Princeton - YouTube
本書は、プログラミングの教科書に掲載された短いプログラムを例題として取り上げ、具体的な改善点を示しています。抽象的な議論に終始せず、実践的な手法に焦点を当てた点が特徴です。著者たちは、例題に対する批評を、時に優しく、時に厳しく行い、誤りのいくつかは自身の著書から引用しています。
この本の影響力は大きく、『The Elements of C Programming Style』、『The Elements of C# Style』、『The Elements of Java(TM) Style』、『The Elements of MATLAB Style』など、特定のプログラミング言語に合わせた多くの派生書籍を生み出しました。これらの書籍は、本書の原則をそれぞれの言語の文脈で具体化し、より実践的な指針を提供しています。
本書の各セクションの最後には、「汚れ仕事は機械にやらせよう」といった簡潔な格言がまとめられています。以下に、本書に掲載されている格言をいくつか紹介します。
わかりやすく書こう - うますぎるプログラムはいけない: コードは読みやすく、理解しやすいように書くべきです。
いいたいことを単純素直にいおう: 複雑な表現は避け、意図を明確に伝えましょう。
ライブラリ関数を使おう: 既存の機能は積極的に活用し、コードの重複を避けましょう。
一時変数はなるべく使わないこと: 不必要な変数の使用は、コードの可読性を低下させます。
効率のためにわかりやすさを犠牲にしてはいけない: 効率だけを追求せず、可読性を優先しましょう。
汚れ仕事は機械にやらせよう: 手動でできることは、できる限り自動化しましょう。
同じ表現の繰り返しは共通関数の呼び出しに変えよう: コードの重複は保守性を低下させます。関数化して再利用しましょう。
括弧を使って誤解を避けよう: 曖昧さを排除し、コードの意図を明確にしましょう。
混同の恐れのない名前を使おう: 変数名や関数名は、役割を明確に示すものにしましょう。
無用な分岐は避けよう: 不要な分岐はコードを複雑にします。
論理表現がわかりにくいときは表現を変えよう: 複雑な論理式は、より単純な形式に書き換えましょう。
プログラムが単純になるようデータ表現を選ぼう: 適切なデータ構造は、コードを簡潔にします。
わかりやすい擬似コードで書いてから実際の言語に落とそう: 実装前に、アルゴリズムを明確化しましょう。
モジュール化し、手続きと関数を使おう: コードを機能ごとに分割し、再利用性を高めましょう。
読みやすさを保てる限り、GOTO文は避けよう: GOTO文は、コードの流れを複雑にします。
ダメなコードを直すのはやめて、書き直そう: 修正が難しいコードは、最初から書き直した方が良いでしょう。
大きいプログラムは小さい部分に分けて書き、テストしよう: 分割統治法で、開発効率を高めましょう。
再帰的に定義されたデータ構造には再帰手続きを使おう: 再帰は、適切な箇所で効果を発揮します。
入力の妥当性と有効性をテストしよう: 不正な入力は、プログラムの異常終了を引き起こします。
入力がプログラムの限界を超えていないことを確認しよう: 適切なエラー処理を行いましょう。
入力はファイル終端で終了するようにし、回数指定に頼らない: より柔軟な入力を実現しましょう。
ダメな入力を特定し、できれば回復しよう: ユーザーフレンドリーなプログラムを心がけましょう。
入力データは準備しやすく、出力はわかりやすく: ユーザビリティを考慮しましょう。
共通の入力フォーマットを使おう: 統一された形式は、扱いやすいデータになります。
簡単に確認できる入力形式に設計しよう: エラーの早期発見に繋がります。
意味のわかりやすい入力を使おう。デフォルトを許容しよう。出力時に両方とも表示しよう: ユーザーが意図した通りの操作ができるようにしましょう。
全ての変数を使用前に初期化しよう: 未初期化の変数は、予期しない動作を引き起こします。
バグをひとつ見つけたところで止まってはいけない: バグは、複数存在する可能性があります。
デバッグ機能付のコンパイラを使おう: デバッグツールは、効率的な開発を支援します。
桁ずれのエラーに注意: 境界値のエラーは、見つけにくいことがあります。
条件分岐時の等号を正しく扱おう: 等号の使い分けは、正確な処理に不可欠です。
ループの真ん中や最後から同じ所に抜けるときは気をつけよう: コードの流れが複雑になる場合は、簡略化を検討しましょう。
何もしないはずのコードが余計なことをしないようにしよう: 意図しない副作用は、バグの原因になります。
境界値でテストしよう: 境界値は、バグが見つかりやすい箇所です。
出力のいくつかを正解と比べて確認しよう: 計算結果が正しいか、確認しましょう。
10.0×0.1が1.0になると考えてはいけない: 浮動小数点演算には、誤差が発生します。
7/8はゼロだが7.0/8.0はゼロではない: 整数演算と浮動小数点演算の違いに注意しましょう。
浮動小数点数が等しいかどうかだけで比較してはならない: 誤差を考慮し、一定の範囲内で比較しましょう。
速くする前に正しくしよう: 正確なプログラムが最優先です。
速くする前にフェールセーフにしよう: エラーが発生した場合の処理も考慮しましょう。
速くする前にわかりやすくしよう: 可読性は、保守性に影響します。
わずかな効率向上のためにわかりやすさを犠牲にしてはいけない: 可読性とのバランスを考えましょう。
簡単な最適化はコンパイラに任せよう: コンパイラは、最適化の専門家です。
コードを兼用しようとせず、組み直そう: 不必要な再利用は、コードを複雑にします。
特例が本当に特例かを確認しよう: 特例は、コードを複雑にする要因になります。
速くする前に単純さを保とう: シンプルなコードは、理解しやすく、保守しやすいです。
速くするためにはコードをこねくり回すのでなく、よりよいアルゴリズムを探そう: アルゴリズムの改善は、大きな効果を生みます。
効率改善の前にプログラムを計測しよう: 計測結果に基づき、ボトルネックを特定しましょう。
コメントとコードを一致させよう: コメントは、コードの理解を助けるために書くものです。
コメントはコードのオウム返しではなく、意味あるものにしよう: コメントは、コードの意図を説明するものです。
ダメなコードにコメントするのはやめ、コードを書き直そう: 悪いコードをコメントでごまかしてはいけません。
意味のわかる変数名をつけよう: 変数名は、コードの意図を明確に示すものにしましょう。
意味のわかるステートメントラベルをつけよう: ラベルは、コードの可読性を向上させるものです。
読みやすいようにプログラムをレイアウトしよう: 整形されたコードは、読みやすいです。
データのレイアウトをドキュメント化しよう: データ構造は、プログラムの理解を深めます。
コメントしすぎないようにしよう: 不要なコメントは、コードの可読性を低下させます。
本書で取り上げられている例題は、古い手続き型プログラミング言語（FortranやPL/I）を対象としているため、現代の読者には古く感じるかもしれません。しかし、本書で示されている原則は、特定の言語に依存しない普遍的なものであり、現代のプログラミングにおいても非常に重要です。
キロボー・マイクロコンピューティングは、「他社が使うプログラムを書くなら、この本を読むべきだ。プロのプログラマーになるつもりなら、この本は必読だ」と述べています。これは、本書がプログラマーにとって非常に価値のあるものであることを示しています。
参考文献
B. W. Kernighan and P. J. Plauger, The Elements of Programming Style, McGraw-Hill, New York, 1974. ISBN 0-07-034199-0
B. W. Kernighan and P. J. Plauger, The Elements of Programming Style 2nd Edition, McGraw Hill, New York, 1978. ISBN 0-07-034207-5
外部リンク
J. Plauger selected quotes from The Elements of Programming Style
Elements of Programming Style – 2009 Brian Kernighan talk at Princeton - YouTube
もう一度検索
【記事の利用について】
タイトルと記事文章は、記事のあるページにリンクを張っていただければ、無料で利用できます。
※画像は、利用できませんのでご注意ください。
【リンクついて】
リンクフリーです。