プログラミング引用集

2026年2月11日

Brian W.Kernighan, P. J. Plauger, プログラム書法 第 2 版, 共立出版, 1982

  • わかりやすく書こう – うますぎるプログラムはいけない。

  • いいたいことを単純率直にいおう。
  • ライブラリ関数を使おう。
  • 一時的変数はなるべく使わないこと。
  • わかりやすく書こう—「効率」のためにわかりやすさを犠牲にしてはいけない。
  • よごれ仕事は機械にやらせよう。
  • 同じ表現の繰り返しは共通関数の呼び出しに変えよう。
  • かっこを使って誤解を避けよう。
  • 混同のおそれのない名前を使おう。
  • Fortranの算術IF文は使わないこと。
  • 無用の飛び越しはしないこと。
  • 言語のよい機能を生かし、わるい機能を避けよう。
  • 条件つきの飛び越しを論理式の代わりに使ってはいけない。
  • 「電話テスト」でプログラムがわかりやすいかどうかためそう。
  • DO-ENDと字下げを使って文の群の間の区切りをはっきりさせよう。
  • IF-ELSEを使って、二つのことがらのうちの一方だけが起こることをはっきりさせよう。
  • DOやDO-WHILEを使ってループの存在をはっきりさせよう。
  • プログラムを上から下へと読めるようにしよう。
  • 多方向の枝わかれを作るときにはIF...ELSE IF...ELSE IF...ELSE...を使おう。
  • 基本的な制御構文を使おう。
  • まずわかりやすい擬似言語で書いて、そのあと目的の言語に翻訳しよう。
  • THEN-IFや空のELSEはなるべく使わないようにしよう。
  • ELSE GOTOやELSE RETURNはなるべく使わないようにしよう。
  • 条件判定をしたら、できるだけ対応する動作をくっつけて示そう。
  • データの配列を使うことによって、繰り返し動作をしないですむようにしよう。
  • プログラムが簡単になるようなデータの表現を選ぼう。
  • 第 1 版ができたところでやめてしまってはいけない。

  • 単位分割しよう。サブルーチンを使うこと。
  • 機能単位間の依存関係は目に見えるようにしよう。
  • 各機能単位は一つのことをうまくやるように作ろう。
  • 機能単位はたしかに何かを隠すように作ろう。
  • データの構造に合わせてプログラムの構造をきめよう。
  • だめなプログラムを修正するのはやめて、全部書きなおそう。
  • 大きいプログラムは小部分ごとに書き、テストするようにしよう。
  • 再帰的に定義されたデータ構造を扱うときは再帰手続きを使おう。

  • 入力の妥当性、現実性をテストしよう。
  • 入力がプログラムの限界を決して越えないように注意。
  • 入力の終りはファイルの終わり、または印によって示そう。入力回数の指定によるのはよくない。
  • まちがった入力をみつけ出そう。できれば回復のための処置をとること。
  • ファイルの終りは統一的に扱おう。
  • 入力形式は作りやすいように、出力形式は一目で理解できるようにきめよう。
  • 統一的な入力書式を使おう。
  • 読み合わせのしやすい入力形式を選ぼう。
  • もし可能なら自由欄形式の入力を使おう。
  • 見ただけで意味のわかるような入力形式を使おう。省略時の解釈ができるようにしよう。入力値と標準値を打ち出そう。
  • 入出力はサブルーチンの中に閉じ込めよう。

  • すべての変数を、使う前に忘れずに初期設定しよう。
  • 一つの虫をみつけたところで追求をやめてしまってはいけない。
  • 虫取り向きコンパイラを使おう。
  • 定数はDATA文またはINITIAL属性で、変数は実行文で初期設定しよう。
  • 一つちがいの誤りに注意。
  • 比較の結果が等しいと出たとき、正しい方向への飛び越しが起こるように注意しよう。
  • ループからいろいろな飛び出しかたをするのはやめよう。
  • 「何もしない」はずのとき変なことが起こらないように注意しよう。
  • プログラムを境界値でテストをしよう。
  • 予防的プログラミングをしよう。
  • 0.1の10.0倍はまず決して1.0にはならない。
  • 浮動小数点表示の数を等しいかどうかのみに着目して比較してはならない。

  • 速くする前に正しくしよう。
  • 速くするときは正しくなくならないように注意しよう。
  • 速くする前にわかりやすくしよう。
  • 「効率」がちょっぴりもうかるからといってわかりやすさを犠牲にするのはやめよう。
  • 簡単な最適化はコンパイラにやらせよう。
  • プログラムのどこかとどこかを兼用しようと思ってがんばってはいけない。むしろ組み立てなおしてみよう。
  • 特別の場合がほんとうに特別の場合かどうかたしかめよう。
  • 速くしたかったら単純さを保とう。
  • 速くしようとしてプログラムをひねくりまわすのはやめて、もっとよいアルゴリズムをみつけよう。
  • プログラムには測定手段を含ませよう。「効率化」のための手なおしの前には測定をしよう。

  • 注釈（コメント）とプログラムが一致するように気をつけよう。
  • プログラムに書いてあることを注釈でおうむがえしにするのはよそう。つけ甲斐のある注釈をつけよう。
  • だめなプログラムに注釈をつけるのはよそう。プログラムの方を書き換えよう。
  • 意味のある変数名を使おう。
  • 意味のある名札を使おう。
  • プログラムの割り付けをくふうして、理解しやすくしよう。
  • プログラムの論理構造を反映するような字下げをしよう。
  • データの割り付けかたについての解説をつけよう。
  • 注釈をつけすぎないようにしよう。

ドナルド・C・ゴース, ジェラルド・M・ワインバーグ, ライト、ついてますか, 共立出版, 1987

  • 問題は何なのか？
  • 問題を抱えているのは誰か？
  • あなたの問題の本質は何ですか？
  • 問題とは、望まれた事柄と認識された事柄の間の相違である。
  • ユーモアのセンスのない人のために問題を解こうとするな。
  • 彼らの解決方法を問題の定義と取り違えるな。
  • 彼らの問題をあまりやすやすと解いてやると、彼らは本当の問題を解いてもらったとは決して信じない。
  • 道徳的問題点は、とかくおいしい問題の熱にとろける。
  • 解法を問題の定義と取り違えるな。ことにその解法が自分の解法であるときには注意。
  • 問題の正しい定義が得られたかどうかは決してわからない、問題が解けたあとでも。
  • 結論に飛びついてはいけないが、自分の第一印象を無視するな。
  • 正しい問題の定義が得られたという確信は決して得られない。だがその確信を得ようとする努力は、決してやめてはいけない。
  • 問題によっては、それを認識するところが一番むずかしいということもある。
  • キミの問題理解をおじゃんにする原因を三つ考えられないうちは、キミはまだ問題を把握していない。
  • キミの問題定義を外国人や盲人や子供について試してみよう。またキミ自身が外国人や盲人や子供になってみよう。
  • 新しい視点は必ず新しい不適合を作り出す。
  • 問題文をどう変えたら解答を変えることができるだろうか？
  • 問題が言葉の形になったら、それがみんなの頭に入るまで言葉をもて遊んでみよう。

言葉遊び

  1. 強調の置き場所を変えてみる。
  2. 肯定を否定に、否定を肯定に変えてみる。
  3. 「てもよい (may)」を「なければならない (must)」に変えてみる。またその逆をやる。
  4. 「または (or)」を「と……の一方 (either or)」に変えてみる。またその逆をやる。
  5. 「および (and)」を「または (or)」に変えてみる。またその逆をやる。
  6. 積極的に定義が与えられている術語を選んで、文中のそれがあらわれた場所を定義の文句で置き換えてみる。
  7. 「等」、「以下同様」、「ほか」などとあったら、そこにもう一つ実例をつけ加えてみる。
  8. 説得的な言葉——「明らかに (obviously)」、「ゆえに (therefore)」、「明瞭に (clearly)」、「確かに (certainly)」など——を探して、それが代表しているはずの論証でそれらを置き換えてみる。
  9. 文またはパラグラフがあらわしているものを絵に描いてみようとする。
  10. 言葉で書いてあるものを式であらわす。
  11. 式を言葉であらわす。
  12. 図が何をいっているか言葉であらわそうとしてみる。
  13. 「読者 (you)」を「筆者 (me)」で置き換える。
  14. 「筆者 (me)」を「読者 (you)」で置き換える。
  15. 「われわれ (we)」と「読者 (you)」を「双方 (both parties)」で置き換える。
  16. 「一つの (a)」を「その (the)」、「その (the)」を「一つの (a)」で置き換える。
  17. 「一部の (some)」を「全部の (every)」で置き換える。
  18. 「全部の (every)」を「一部の (some)」で置き換える。
  19. 「つねに (always)」を「あるとき (sometime)」で置き換える。
  20. 「あるとき (sometime)」を「決して……ない (never)」で置き換える。
  • それは誰の問題か？
  • 他人が自分の問題を自分で完全に解けるときに、それを解いてやろうとするな。
  • もしそれが彼らの問題なら、それを彼らの問題にしてしまえ。
  • もしある人物が問題に関係があって、しかもその問題を抱えていないなら、何かをやってそれをその人物の問題にしてしまおう。
  • 変化のために自分を責めてみよう、たとえほんの一瞬でも。
  • もし人々の頭の中のライトがついているなら、ちょっと思い出させてやる方がごちゃごちゃいうより有効なのだ。
  • この問題はどこからきたのか？
  • 問題の出所はもっともしばしばわれわれ自身の中にある。
  • 問題解決者の谷では、問題製造者は王か社長か学部長だ。
  • 世界には2種類の人間がいる。仕事をする連中とほかの連中に仕事をさせる連中だ。仕事させ屋から遠ざかっていれば大丈夫。
  • 世界には2種類の人間がいる。仕事をする連中と手柄を立てる連中だ。仕事をする方に入っていたまえ。その方がずっと競争が少ない。
  • ちょっと見たところと違って人々は、くれといったもんを出してやるまでは何がほしかったか知らぬものである。
  • あとから調べてみれば、本当に問題を解いてほしかった人はそんなにいないものだ。
  • 私はそれを本当に解きたいか？

クヌース先生のプログラミング論, 共立出版, 1991

芸術としてのプログラミング

  • アートのないサイエンスは冗長になりがちであり、サイエンスのないアートは不正確になりやすい。
  • 正直に言って、私はコンピュータ・プログラムを書くことが、実際楽しいのです。そして特に、何らかの意味で、たいへんよいプログラムを書くことが楽しいのです。
  • 意味のあるエラー・メッセージを作成したり、誤りを犯しにくい、柔軟性のある入力形式を設計することは、真の芸術であると言えるでしょう。

文芸的プログラミング

  • かなり以前から自分では、本にして発表するプログラムや、授業中に組むプログラムには虫の少ない傾向があることはわかっていたのだが、それは私がプログラミングをするときに、自分自身の想念を明らかにする必要に迫られていたからであった。これと対照的に自分のためだけにプログラムを書くときには、往々にして近道を取っては、それが後になってどうしようもない過ちであったということに気づくのであった。

P.H.ウィンストン, B.K.P.ホーン, LISP 原書第 3 版, 培風館, 1991

手続き抽象化は詳細を抽象化の境界線によって隠す

  • 手続き抽象化は下位レベルで物事がいかになされるかに関する詳細事を取り除くことによって、高次レベルでの思考を補助する。下位レベルの手続きについて考えることをあとの時点まで延期することによりトップダウン的にプログラムすることができる。

データ抽象化

  • データがどのように格納されているかを正確に覚える必要はない。
  • データの配置の詳細を簡単に変えることができる。
  • データへの参照を簡単に探し出せる。
  • データを得る低レベルのプリミティブの複雑な組み合わせを覚える必要はない。アクセス手続きはもっと覚えやすく考えやすい。

良いプログラミングの規則

  • 手続きには自由にコメントをつけるべきである。定義の前に説明文を書き、ポイントを強調せよ。
  • 手続きと変数の名前は記述的でなければいけない。
  • 手続きは短くなくてはいけない。
  • 手続きは二、三の引数だけを持つべきである。
  • 手続きは目標の近くで定義されるべきである。
  • 手続きはどんな状況で呼び出しされるかに関して仮定をすべきではない。
  • 手続き抽象化を用いよ。
  • データ抽象化を用いよ。
  • プログラムをモジュール化せよ。各モジュールには明快なインタフェースを与えよ。

Steve Oualline, Practical C Programming, ソフトバンク, 1992

  • プログラムは明快、簡潔、シンプルに書く。
  • コメントを書く（プログラム名、作者、目的、使い方、参考文献）。
  • 変数名は、短縮形や省略形は避ける。
  • クレバーになってはいけない。明快でわかりやすく書け。
  • ひとつのパラグラフ（処理の小さなまとまり）は、小見出しのようなコメントで始め、別のパラグラフと空行で区切る。
  • １つの関数は、2〜3 ページよりも長くてはいけない。
  • if が多重にネスティングしているような、複雑な論理は避ける。
  • １つの式が 1 〜 2 行より長くなるときは、それを 2 つの式に分割することを考える。
  • プログラムはシンプルでわかりやすく書く。

  • It’s just a simple matter of programming.（そんなものは、簡単にプログラミングできる）——自分ではプログラムを書いたことのない世のすべての上司
  • ソフトウエアのライフサイクル
    1. 仕事の依頼（要件書づくり）
    2. 仕様書（プログラムが仕上がっていくにつれて、仕様書を具体的に仕上げていく）
    3. コード設計（アルゴリズム、モジュール定義、フォーマット、データ構造）
    4. コーディング（プロトタイプから、徐々に仕上げていく）
    5. 試験
    6. デバッグ（アルファテスト、ベータテスト：試用）
    7. 公表（パッケージ化、マニュアル作成）
    8. メンテナンス
    9. 改版
    10. 批判検討
    11. に戻る

  • 構造化プログラミング : 1 つのプログラムを複数の小さな、定義のはっきりした関数に分解して組みあげる方法。
  • トップダウンプログラミング : mainから作っていく方法。
  • ボトムアップ : 低レベル関数を先に書いて、テストして、構築していく。
  • 自分にとって最良の方法を使え。

  • デバッグを始める前に、かならずオリジナルバージョンを別途セーブする。
  • 告白法によるデバッグ（confessional method of debugging）: プログラマが自分のプログラムを誰かに説明することで、ものごとを新鮮な見方で見る。
  • 最適化をしてはいけない。プログラムを速く走らせたかったら、速いコンピュータを使え。

最適化

  • ループの順序は、内側のループがいちばん複雑で、外側のループがいちばんシンプルなようにする。
  • サイズを２のべき乗にする。
  • 配列インデクシングのかわりに、ポインタからの逆参照をつかう。
  • マクロによるインライン展開を使う。
  • 実行コストの低い操作を使う。

  • 金額計算に浮動小数点数を使うな。整数を使え（BCD演算など）。
  • 特別に大きな数や小さな数になると、標準ライブラリ関数も間違った答えを出すことが多い。

  • モジュールは、おたがいの間を行き来する情報の量が最少になるように設計する。
  • １つのモジュール内のpublicな関数の数をできるだけ少なくする。
  • モジュール間で渡される情報量をできるだけ少なくする。
  • １つのモジュール内の関数はすべて、関連性のある仕事をする。

  • 機種依存のコードを１つのモジュールに閉じ込める。

プログラミングの格言集

  • 一にコメント、二にコメント、三にもコメント。プログラムには、大量のコメントを書いてください。他の人がそのプログラムを読んでも、わかるように。後で自分が見ても、わかるように。
  • KISSの原則を守る（Keep It Simple, Stupid; 単純愚直主義）。複雑ですごいコードよりも、明快でシンプルがベター。
  • 副作用を避ける。++と--はそれだけを単独の行で使う。
  • 条件文の中に代入文を書かないこと。他の文の中に、代入文を書かないこと。
  • =と ==の違いに気をつけること。==と書くべきところに=を書くことは、非常によくあるエラーで、しかも見つけにくいエラーです。
  • 「何もしない」場合、だまってそうしてはいけない。
    /* こんな書き方はいけません */
    for( index = 0; data[ index ] < key; index++ );
    /* 行末のセミコロンがあなたには見えましたか？ */

空文には、必ずコメントを付けること。

    for( index = 0; data[ index ] < key; index++ )
        ; /* 何もしない */
  • プログラムを設計するときは、「最小驚愕の法則 The Law of Least Astonishment」に従う。これは、プログラムがユーザを驚かせるような振る舞いを、なるべくしてはいけない、という意味です。
  • ユーザインタフェイスは、できるだけシンプルで一貫性のあるものに。
  • ユーザへの支援（ヘルプ情報など）は、できるだけ多く提供すること。
  • エラーメッセージは”error”という言葉で始めて、エラーメッセージであることがはっきりわかるようにする。また、そのエラーへの対策もなるべくユーザに教えること。（“error” の前に、プログラム名、モジュール名があると、さらに助かる!!）

  • 変数宣言は1行に1つずつ書き、コメントをつける。
  • 変数名は、タイピングが困難にならない範囲内で、意味がわかるほど十分に長くする。2〜3語からなる変数名で、通常は十分です。
  • デフォルトの宣言を使ってはいけない。整数を返す関数は、かならず int型と宣言してください。
  • デフォルトの宣言を使ってはいけない。関数に渡すパラメータはすべて宣言し、コメントをつけてください。

  • switch文にはデフォルトのケース（default:）を必ず書く。何もやることがなくても、必ず書く。
    switch ( expression ) {
        …
        default: /* 何もしない */
    }
  • switchのそれぞれのcaseは、必ず最後にbreak;または/* すぐ下へ続く */を書く。

  • プリプロセッサの#defineディレクティブで定義する定数式は、必ずカッコで囲むこと。
    #define BOX_SIZE (3*10) /* ボックスのサイズ (画素数) */
  • 引数を取るマクロの引数は必ずカッコで囲むこと。
    #define SQUARE(x) ((x) * (x))
  • マクロが複文を定義しているときは、それらの複文をブレースで囲むこと。
    /* 致命的なエラーが起きたので、ユーザに告げてアボートする */
    #define DIE(msg) {printf(msg);exit(0);}
  • 条件つきコンパイルで#ifdef/#endif構文を使うときは、#defineと#undef文をプログラムの頭近くにおき、コメントをつける。

  • 一対の{ }で囲まれた1ブロックのコードは、長さが2ページよりも長くなってはいけない。それより長くなるときは、複数の小さな手続きに分割すべきです。
  • １つの行が画面の右端に達するほど長いときは、これも小さな手続きへの分割を検討すべき。

  • プログラムのコンパイルの仕方が他人にもわかるように、かならずMakefileを作ること。
  • UNIX 上では、lintを使ってプログラムの”ごみ掃除”をすること。

  • C でできることは、すべて理解した、とお考えなら、もっとよーく考えてください。Cはまだまだ、奥の深いプログラミング言語ですぞ。

Steve Maguire, ライティング ソリッドコード, アスキー出版局, 1995

  • コンパイラのオプションの警告はすべて有効にしよう。
  • 単体テストが存在する場合には、そのテストを行え。

  • 出荷およびデバッグバージョンの両方を管理せよ。
  • assertを使って、関数の引数をチェックせよ。
  • 自分のコードから未定義の動作を削除せよ。また、アサーションを使って未定義の動作の誤った使用法を検出せよ。
  • 人の時間を無駄にするな。不明解なアサーションにはコメントを加えよ。
  • 暗黙の仮定を取り除くか、アサーションを使用して、その仮定が有効であるかをチェックせよ。
  • アサーションを使って、ありえない状態を発見せよ。
  • 防御的にプログラミングをすることで、バグを覆い隠すな。
  • 結果の有効性を確かめるために、第2のアルゴリズムを使用せよ。
  • バグが起こるのを待ってはならない。起動時のチェックを行おう。

  • 不安定な動作を取り除け。そしてバグを再現せよ。
  • 誤って使用されないようにガベージを壊せ。
  • 何かがまれにしか起こらない場合には、強制的に頻繁に起こるようにせよ。
  • 強力なエラーチェックを行うためにはデバッグ情報を保持せよ。
  • サブシステムのチェックを行うコードを作成し、頻繁にそれを活用せよ。
  • テスト方法は注意深くデザインせよ。思い込みで行ってはならない。
  • 透過的で、完全なチェックを実装するように心掛けよ。
  • 出荷バージョンの制限をデバッグバージョンに適用してはならない。プログラムのサイズやスピードと、エラーの検出のトレードオフを考慮せよ。

  • バグが見つかるまでステップ実行を待ってはいけない。
  • あらゆるコードパスをステップ実行せよ。
  • ステップ実行を行って、データの流れに注目せよ。
  • ソースレベルのデバッガは、実行過程の詳細を隠してしまう可能性がある。重要なコードはインストラクションレベルでステップ実行せよ。

  • エラーの状況を無視するのが困難になるようにしろ。戻り値の中にエラーコードを埋めてはいけない。
  • 常にインターフェイスの傷を探し、それを削減せよ。
  • 多目的の関数を書いてはならない。引数の有効性を厳しくチェックできるように、関数を分けて作成せよ。
  • 中身が間違った内容にならないようにせよ。関数の引数は、はっきりと定義せよ。
  • 有効な入力が与えられれば、エラーを返さない関数を書け。
  • 呼び出し時にコードがわかりやすくなるように努めろ。ブール値の引数は避けろ。
  • 潜在的な危険性を強調するコメントを書いておけ。

  • 適切に定義されたデータ型を使用せよ。
  • デザインをできるだけ正確に実装せよ。核心部分の周辺ではバグが起こりやすいのだ。
  • 1つの”仕事”だけを実装するようにせよ!
  • 余分なif文は取り除け。
  • ネストした?:演算子を使うのを避けよ。
  • 特別な場合は1回だけ処理せよ。
  • 危険な言語イディオムを避けよ。
  • 必要もないのに演算子の型を組合わせて使用するな。もし演算子を組合わせて使う必要があれば、括弧を使用して演算子を切り分けろ。
  • エラーを返す関数を呼び出すのを避けよ。

  • 所有していないメモリは参照してはいけない。
  • 解放したメモリを参照してはいけない。
  • 出力メモリを作業用バッファとして使用してはいけない。
  • 静的な（あるいは大域的な）メモリを使用してデータをやり取りするな。
  • プログラミング言語を乱用するな。
  • 短いCのコードを書いても効率のよいコードになることは保証されない。
  • 平均的なプログラマレベルのコードを作成せよ。

  • バグは自然に”消えてしまう”ことはない。
  • あとからバグを修正するな。バグはいますぐ修正せよ。
  • 症状ではなく、原因を修正せよ。
  • もしクリーンアップすることがその製品の成功に重大にかかわらないなら、コードをクリーンアップしてはいけない。
  • 戦略的でない機能は実装するな。
  • フリーな機能などは存在しない。
  • 不必要に柔軟性を持たせてはいけない。
  • 正常に動作する方法がわかるまでは、“トライ”するという解決策を使用してはならない。時間をかけて正しい解決策を見つけてほしい。
  • 小さな部分ごとにコードを書き、テストせよ。スケジュールがスリップしようとも、常に自分のコードのテストは行え。
  • バグの発見のためにテストグループを頼るな。
  • バグを見つけたことでテスターを非難してはいけない。
  • 自分の優先度を確立し、それに従え。

フレデリック・P・ブルックス Jr., 人月の神話, ピアソンエデュケーション, 1996

  • プログラミングシステム製品は、個人使用目的の別個に書かれたコンポーネントプログラムの約9倍の労力を必要とする。製品化には 3 倍の労力が必要であり、各コンポーネントプログラムをデザイン・統合化・テストして一つのまとまったシステムにすることに3倍の労力がかかる。そしてそのコストは本質的に別々のものである。
  • プログラム作成固有の苦しみ
    • 目的は別の人間に決められ、自分ではコントロールができないものに依存しなければならず、権限と責任とがつりあっていない。
    • プログラム開発プロジェクトは、終りに近づくにつれ、一つに収斂するのが遅くなるのに対して、作業者のほうは終りが近づくと、より速く収斂するようになることを期待するものだ。
  • おいしい料理には時間がかかるのと同じように、結果が惨憺たるものにならないようにするためには、急かすことのできない仕事もある。
  • すべてのプログラマは楽観主義者で、「すべてうまくいくだろう」と思っている。
  • プログラマは純粋な思考からなるもので組み立てるため、現実の困難さをほとんど予想していない。
  • だが、アイデア自体に間違いはつきものであるから、バグが発生することになる。
  • コスト計算をもとにして組み立てられた見積り技術は、労力と進捗とを混同している。人月は、間違った危険な神話である。というのも、人月とは「人」と「月」が相互に交換可能だということを意味しているからだ。
  • 複数の人々の間で仕事を配分することは、コミュニケーションという余計な労力——教育および相互コミュニケーション——をもたらす。
  • 私の目安では、全体のスケジュールに対して、デザインに三分の一、コーディングに六分の一、単体テストに四分の一、そしてシステムテストに四分の一を割り当てる。
  • ブルックスの法則—遅れているソフトウエアプロジェクトへの要員追加は、さらに遅らせるだけである。
  • ソフトウエアプロジェクトに要員を追加することは、以下の三点において、必要となる全体の労力を増大させる。すなわち、再配分作業とそのための中断、新しい要員の訓練、それから新たに必要となる相互コミュニケーションである。
  • 非常に優秀なプロのプログラマは、同じトレーニングを受け経験二年というレベルでの比較では、出来の良くないプログラマの十倍も生産性が高い。
  • 少数精鋭チームが最高である—人数はできるだけ少ないほうがよい。
  • 一方がリーダーである二人編成チームが、頭脳の活用には最高である場合がしばしばある。
  • 少数精鋭チームで非常に大きなシステムに取り組むと、開発が遅れすぎる。
  • 「コンセプトの完全性こそ、システムデザインにおいてもっとも重要な考慮点である」。
  • 「機能対コンセプトの複雑さの比率が、システムデザインの究極の試金石であって」、機能の豊富さだけではないのである。
  • コンセプトの完全性を得るには、デザインが一人ないしは互いに意見が同じ少人数の頭脳グループで考え出さなければならない。
  • 「アーキテクチャの労力をインプリメンテーションから切り離すことは、非常に大規模なプロジェクトでコンセプトの完全性を得るにはとても強力な方法である」（これは、小規模プロジェクトにも当てはまる）。
  • 「システムにコンセプトの完全性を求めるならば、だれかがそのコンセプトをコントロールしなくてはならない。それがまぎれもなく貴族政治なのだ」。
  • 修練は技芸のためになる。アーキテクチャの外部規定は、実現グループの創造性を拘束するのではなく、高めるものだ。
  • コンセプトが統合されているシステムは、より早く開発されテストができる。
  • 二度目のシステムこそデザインするもののうちでもっとも危険なシステムである。一般的に、デザインし過ぎる傾向があるからだ。
  • デザインチームに要員がたくさんいる場合でも、細かな決断にいたるまで一貫性をもたせるために、結果的に一人か二人で書くことになる。
  • 慎重に規定されてはいないところまで含めて、アーキテクチャの部分を明示的に定義することが重要である。
  • 正確さのための形式的定義と、わかりやすさのための散文による定義の両方が必要になる。
  • バベルの塔プロジェクトは、コミュニケーションとそこから生まれる組織がなかったために失敗した。
  • チームは可能な限り多くの方法で互いにコミュニケーションを図るべきだ。つまり、非公式の会話や技術的な概要報告を行う定期的なプロジェクトミーティング、共用の正式なプロジェクト手引き書などを通してだ。
  • 継続する文章を最初から適切に構造化することで、「後から書かれるものはその構成に合った形式で作成され」、製品マニュアルの改良につながる。
  • 組織は、コミュニケーションを不要にするための作業の分担と機能の専門化を具体化したものである。
  • 各サブプロジェクトには、満たさなくてはならないリーダーシップの役割が二つあり、それは製作主任（マネージャー）の役割と技術主任（アーキテクト）の役割である。
  • プログラム開発プロジェクト全体の労力やスケジュールは、単にコーディング時間を見積もって、それに作業のほかの部分の 比率を掛け合わせただけでは、正確に見積もることができない。
  • プログラミングの生産性は、適切な高水準言語が使用された場合、五倍も向上する可能性がある。
  • インプリメンテーション期間中、システムアーキテクトは継続したシステムの完全性を確保するために、不断の警戒を維持しなければならない。
  • トータルシステム的な利用者指向の心構えを養うことが、プログラミングマネージャのもっとも重要な役割といえるかもしれない。
  • スペースと時間をうまい具合にトレードオフするには、特定の言語や機械、とりわけ新しいものの場合は、それ特有のプログラミング技法にチームがよく慣れている必要がある。
  • プログラミングには技術があり、すべてのプロジェクトには標準コンポーネントのライブラリが必要である。
  • 簡潔で余分なところがなくてスピードの速いプログラムは、たいてい決まって戦略的突破（ブレークスルー）の結果であって、巧妙な奇策ではない。
  • しばしば、そうした戦略的突破は新しいアルゴリズムの場合がある。
  • データやテーブルの表現をやり直すことで、戦略的突破が実現されることはさらに多い。表現はプログラミングの本質なのだ。
  • 書くという作業は、何百という細かな判断を必要とするわけで、その判断があるからこそ、ぼんやりしたものではなく、明白で正確な方針ができるのだ。
  • 前作を破棄してデザインをやり直すのは、全部ひとまとめにしてもよいし、一つずつに分けても構わないが、いずれにしてもやらざるをえない。
  • 第一作目のシステム、すなわち廃棄処分すべきものを顧客に配布すれば、時間の節約にはなるだろう。しかし、それは、利用者に苦悩を課したり、再デザイン中の製作者の仕事を混乱に落とし入れたり、デザインを最善にし直したとしても打ち消すのが難しい。悪い製品イメージを作り上げたりする犠牲を伴うものである。
  • だから、一つは捨て石にするつもりでいることである。どうしたってそうせざるをえないのだから。
  • 「プログラマの仕事とは、目に見える具体的な製品より、むしろ利用者のニーズに対する満足を届けることだ」。
  • 目的（および開発戦略）に対する正当な若干の変更は避けられない。変更はないなどと想定するよりも、あると思って準備しておいたほうがよい。
  • 変化に備えたソフトウエア製品のデザイン方法は、とりわけ細かく配慮されたモジュールインターフェース文書作成機能を持つ構造化プログラミングがよく知られているが、一般には実践されていない。適用できるなら、できるだけテーブル駆動の手法を使用することも役に立つ。
  • 高水準言語とコンパイル時操作、参照による宣言の組み込み、それに自己文書技法を使って、変更により誘発されるエラーを抑制することである。
  • 変更内容は、明確な番号の付いたバージョンに量子化しなければならない。
  • プログラマがデザインを文書化したがらない理由には、怠慢というよりも、むしろデザイナーには仮のものだとわかっている決定事項に関して言質をとられたくないという思いからきている (コスグローブ)。
  • 広く使用されているプログラムを、その寿命が尽きるまでメンテナンスするためのトータルコストは、開発コストの四十パーセント以上と考えてまず間違いない。
  • 欠陥の修正は、実質的には別の欠陥を生み出す可能性（二十〜五十パーセント）を秘めている。
  • 修正のつど、気づかないうちに損傷を受けていないことを確認するため、以前システムに対して行われたテストケースを実行しなければならない。
  • 副作用をなくす、または少なくとも解明することができるようなプログラムのデザイン方法をとれば、メンテナンス費用の多大な削減ができる。
  • より少ない人数でより少ないインターフェースを使ったデザインを実現する方法でもメンテナンス費用の削減は可能であり、この場合バグの数も減らせる。
  • おしなべて修正というのは、構造を破壊してシステムのエントロピーと混乱を増加させる傾向がある。修正をどんなに器用に行ったとしても、できることはシステムが混沌とした修正不能な状態へと沈んでいくのを遅らせることだけであり、根底から再デザインをしなければならなくなる。(例えばパフォーマンスのように、プログラムのアップグレードに対する実際のニーズの多くは、特に内部構造の境界に関わるものだ。往々にしてもとの境界は後から発覚する結果の原因となっていることがあった。)
  • プロジェクトマネージャーは、共通のツール政策に関する方針を立て、そのためのリソースを確保しなければならないと同時に、個人的なツールの必要性も認識しなければならない。
  • プログラミングプロジェクトでもっとも手間を省いてくれるツールは、おそらくテキスト編集システムだろう。
  • システム文書の膨大さは、まさに新種の理解のしにくさをもたらすが、非常によく見かけられるひどい文書不足に比べたら、はるかにましだ。
  • 高水準言語は、生産性を向上させるばかりでなく、デバッグも改善する。これは、バグの数が少なくなり、見つけやすくなるからである。
  • 詳細で骨の折れるアーキテクチャ上の努力は、製品を使いやすくするばかりでなく、構築を容易にして発見しなければならないシステムバグの数を減らすものだ。
  • 「数多くの失敗は、まさしくそういう十分に詳述されることのなかった局面に関係している」。
  • コードができあがるずっと前に、仕様書は外部のテストグループへ渡し、完成度と明瞭さについて精細に調べてもらわなければならない。開発者自身がこれを行うことはできない。
  • ヴィルトは、各ステップで可能な限り高レベルな記法を使用することを提唱している。
  • 時には後戻りしてトップレベルを破棄し、まったく最初からやり直さなければならないこともある。
  • 構造化プログラミングは、制御構造が (雑多な分岐に対立するものとして) コードのブロックを管轄するために指定されたセットだけから構成されているプログラムをデザインするためのもので、バグ回避の健全な方法であり、思考には正しい方法である。
  • システムデバッグには、予想しているよりも長い時間がかかる。
  • システムデバッグは困難であるがゆえに、しっかりと系統立てて計画されたアプローチが必要である。
  • 各部分がきちんと動くようになってから始めからシステムデバッグに着手するべきである。
  • デバッグする製品のコードの五十パーセントに達するくらいまで、多くのデバッグ用足場やテストコードを作成するのは十分意味のあることだ。
  • 上司がまずい行動をとれば、隠し事のない現状報告を黙らせること請け合いだ。反対に、上司が状況報告を慎重に切り離し、パニックに陥ったり部下の頭越しの処理をせずに聞くことができれば、正直な報告が促進されるものだ。
  • プログラム製品にとって、利用者に見せるもう一つの顔である文書は機械に見せる顔と同じように、実に重要である。
  • ごく個人的なプログラムでさえ、利用者でもある作成者の記憶力が役に立たないことがある。だから、散文の文書の作成が必要である。
  • ほとんどの文書は概要の説明が十分でない点で落第だ。遠くに立って見てからゆっくり近づくことだ。
  • もっとも重要な利用者のための文書は、プログラムを書き始める前に下書きされるべきである。というのも、それが基本的なプラン決定の具現だからだ。そこには九項目の記述がなければならない。
    1. 目的（主要な機能、プログラムの必要性）
    2. 環境（実行可能な環境）
    3. 領域と範囲（どの入力が有効で、出力範囲はどこか）
    4. 実現される機能としようされるアルゴリズム（要するに何をするものなのか）
    5. 入出力フォーマット
    6. オペレーション指示
    7. オプション
    8. 実行時間
    9. 精度および検査
  • プログラムにはいくつかのテストケースを用意すべきだ。つまり、有効な入力データのためのケース、境界線上の入力データのためのケース、および明らかに無効な入力データのためのケースだ。
  • プログラム内部文書にもまた、プログラムを修正しなければならない人のために散文による概要が必要であり、五種類の内容を網羅している必要がある。
    1. サブプログラム構造図。
    2. 使用されるアルゴリズムの完全な記述。
    3. 使用される全ファイルのレイアウトに関する説明。
    4. 処理フロー。
    5. もとのデザインで意図されている修正に関する説明。どんな修正が可能で、どのように修正すべきかについての説明。
  • フローチャートは、プログラム文書の作成のうちでまったく過大評価されてきたものの一つだ。詳細で逐一記述したフローチャートは厄介者であり、高水準言語での記述によって時代遅れとなった (フローチャートは図式化された高水準言語だ)。
  • フローチャートを必要とするとしても、一ページ以上のものを必要とするプログラムはほとんどない。
  • 文書をきちんと維持、管理するためには、それを別個の文書として維持するのではなく、ソースプログラム中に組み込んでしまうことが重要である。
  • 以下三つの考え方が、文書作成の負担を最小化するための鍵である。
    1. 可能な限り多くの文書をプログラムに入れるため、名前や宣言などのプログラムの一部を使用する。いずれにしてもこれらはなければならないからだ。
    2. 読みやすさを可能な限り改善するため、従属関係やネストを明らかにする空白や書式を工夫する。
    3. 必要な散文による文書を注釈として、特にモジュールのヘッダーとしてプログラムの中に挿入する。
  • プログラムを修正する人が使用する文書では、単にそのプログラムがどうなっているかを示すのではなく、なぜそうなっているのかを伝えることが重要だ。目的こそ理解の鍵になる。
  • 自己文書プログラミング技法は、オンラインシステムで使用される高水準言語で、その偉大な用途と力を見出した。これは使うべきツールだ。
  • ソフトウエアシステムは、人間の作り出したもののうちで、おそらく（異なる部品の種類の数という点で）もっともわかりにくく複雑なものだろう。
  • ソフトウエアエンジニアリングというタールの沼は、これから当分の間ずっと厄介なままだろう。

Brian W.Kernighan, Rob Pike, プログラミング作法, アスキー, 2000

スタイル

  • グローバルにはわかりやすい名前を、ローカルには短い名前を
  • 統一しよう
  • 関数には能動的な名前を
  • 名前は的確に
  • 構造がわかるようにインデントしよう
  • 自然な形の式を使おう
  • かっこを使ってあいまいさを解消しよう
  • 複雑な式は分割しよう
  • 明快に書こう
  • 副作用に注意
  • インデントとブレースのスタイルを統一しよう
  • 慣用句によって一貫性を確保しよう
  • 多分岐の判定にはelse-ifを使おう
  • 関数マクロはなるべく使うな
  • マクロの本体と引数はかっこに入れよう
  • マジックナンバーには名前をつけよう
  • 数値はマクロではなく定数として定義しよう
  • 整数ではなく文字定数を使おう
  • オブジェクトサイズは言語に計算させよう
  • 当たり前のことはいちいち書くな
  • 関数とグローバルデータにはコメントを
  • 悪いコードにコメントをつけるな、書き直せ
  • コードと矛盾させるな
  • あくまでも明快に、混乱を招くな

インターフェイス

  • 実装の詳細を隠蔽しよう
  • 直交性のある小さなプリミティブセットを選択しよう
  • ユーザーに内緒で何かをするな
  • 同じことはどこでも同じように実行しよう
  • リソースの解放は割り当てと同じレイヤで
  • エラーの検出は低いレベルで、その処理は高いレベルで
  • 例外は例外的な状況のみ使用しよう

デバッグ

  • おなじみのパターンを見つけよう
  • 最新の変更点は要チェック
  • 同じ間違いを繰り返すな
  • デバッグは今すぐに
  • スタックトレースを取得しよう
  • 打つ前に読め
  • 自分のコードを他人に説明してみよう
  • バグを再現できるようにしよう
  • 分割統治しよう
  • 誤動作を「数字占い」で検証しよう
  • 出力表示によってバグ探索範囲を狭めよう
  • 自己検証コードを記述しよう
  • ログファイルを出力しよう
  • 作図しよう
  • ツールを使おう
  • 記録をとろう

テスト

  • 境界をテストしよう
  • 事前と事後の状態をテストしよう
  • アサーションを使おう
  • プログラミングは予防的に
  • エラーの戻り値をチェックしよう
  • テストはインクリメンタルに
  • テストは単純な部品から
  • 期待される出力を把握しておこう
  • 保存される性質を検証しよう
  • 独立した実装同士を比較しよう
  • テストの網羅範囲を測定しよう
  • 回帰テストを自動化しよう
  • 自給自足テストを作成しよう

性能

  • 時間計測を自動化しよう
  • プロファイラを利用しよう
  • ホットスポットに神経を集中しよう
  • 作図しよう
  • より優れたアルゴリズムやデータ構造を利用しよう
  • コンパイラの最適化を有効に
  • コードをチューニングしよう
  • 関係ない部分を最適化するな
  • 共通する式をまとめよう
  • 高価な処理を安価な処理に置き換えよう
  • ループは展開するか除去しよう
  • 頻繁に使われる値をキャッシュしよう
  • 専用のアロケータを書こう
  • 入力と出力をバッファリングしよう
  • 特殊なケースは個別に処理しよう
  • 結果を事前に計算しておこう
  • 近似値を使おう
  • より低級な言語で書き直そう
  • できる限り小さなデータ型を使って領域を節約しよう
  • 簡単に再計算できるものを記憶するな

移植性

  • 標準に固執しよう
  • 王道のプログラミングをしよう
  • 言語のトラブルスポットに気をつけよう
  • 複数のコンパイラで試してみよう
  • 標準ライブラリを使おう
  • どこでも利用できる機能だけを使おう
  • 条件コンパイルは避けよう
  • システム依存のコードは別個のファイルに
  • システム依存部分はインターフェイスの裏に隠蔽しよう
  • データ交換にはテキストを
  • データ交換には固定のバイト順を使おう
  • 仕様を変えるなら名前を変えよう
  • 既存のプログラムやデータとの互換性を維持しよう
  • ASCII を前提にするな
  • 英語を前提にするな

エリック・レイモンド, 伽藍とバザール, 1999

  • よいソフトはすべて、開発者の個人的な悩み解決から始まる。
  • 何を書けばいいかわかってるのがよいプログラマ。なにを書き直せば（そして使いまわせば）いいかわかってるのが、すごいプログラマ。
  • めちゃくちゃになったものを救うよりは、正しいアイデアで一からやり直すほうが、有効な場合が多い。
  • １回とりあえず解決策を実装してみるまでは、問題を完全には理解しきれない。２回目くらいになってやっと、正しい解決法がわかるくらいの理解が得られるかもしれない。だからちゃんとした問題解決をしたいなら、少なくとも１回くらいはやり直す覚悟はしておくこと。
  • はやめのリリース、ひんぱんなリリース。そして顧客の話をきくこと。
  • 賢いデータ構造と間抜けなコードのほうが、その逆よりずっとまし。
  • いいアイデアを思いつく次善の策は、ユーザからのいいアイデアを認識することである。時にはどっちが次善かわからなかったりする。
  • おもしろいことに、もし自分が他人に負うところがいかに大きいかについて、完全かつ謙虚なくらいに正直でいたら、世の中はその発明が全部あなた自身のもので、単に自分の天才ぶりについて謙遜しているだけだと見なしてくれる。
  • 自分の問題のとらえかたがそもそも間違っていたと認識することで、もっとも衝撃的で革新的な解決策が生まれることはよくある。
  • 開発で壁にぶちあたったときというのは、自分が最終的な回答にたどりついたのかな、と考えるべきときではなく、むしろ自分が正しい質問をしているのかな、と考え直して見るべきときであることが多い。ひょっとして、問題をとらえなおしてみる必要があるのかもしれない。
  • 古びてきた機能は迷わず捨てること。
  • ソフトの設計で、小利口で独創的になることの問題点は、それが習慣になってしまうことだ。ソフトは堅牢でシンプルにしておかなきゃダメなのに、反射的にそれを媚びた複雑なものにしてしまいがちになる。このまちがいのおかげでつぶれたプロジェクトもいくつかある。
  • 人間は仕事をするとき、それが最適な挑戦ゾーンになっていると、いちばん嬉しい。簡単すぎて退屈でもいけないし、達成不可能なほどむずかしくてもダメだ。シアワセなプログラマは、使いこなされていないこともなく、どうしようもない目標や、ストレスだらけのプロセスの摩擦でげんなりしていない。楽しみが能率をあげる。
  • 自分の仕事のプロセスにびくびくゲロゲロ状態で関わり合うというのは、それ自体が、そのプロセスの失敗を告げるものととらえるべきだ。楽しさ、ユーモア、遊び心は、まさに財産だ。

エリック・レイモンド, ハッカーになろう, 2001

  • ハッカーになるためには自分の技術をみがき、知性を働かす訓練して、問題を解決することにゾクゾクするような喜びを感じるようでなければいけません。
  • 自分の学習能力に対する信頼も育てましょう。たとえ今の段階では大きな問題を解決するのに必要なすべてを知らなくても、その問題のほんの一部から取りかかって、そこから新しい事を学び取れば、次の部分の解決に十分なだけ学べて、そして次へ次へと進めば、いずれ大きな問題全体が解決できると信じましょう。
  • 他のハッカーたちが考える時間は貴重であると信じなければなりません。それをとことん信じて、情報を共有するのがほとんど道徳的な義務であると思えるようになりましょう。
  • 退屈と単純作業はつまらないだけでなく、本当に悪いことなのです。ハッカーらしくふるまうには、これを徹底的に信じ込んで、自分自身のためばかりでなく他のみんな（とりわけ他のハッカーたち）のためにも、退屈な部分はできるだけたくさん自動化してしまいたくなるようにしましょう。
  • 言語を一つしか知らないなら、ハッカーではないし、プログラマですらないのです。あなたはプログラミングの問題について考えるのに、ひとつの言語に依存しない一般的な方法を身につけなくてはならないからです。
  • プログラムを学ぶということは、自然言語でよい文章の書きかたを学ぶようなものです。いちばんいいのは、その分野の熟練者が書いたものを読んで、自分で何か書いてみて、もっとたくさん読んでも、もうちょっと書いて、もっとたくさん読んでも、もうちょっと書いて……そして自分の書くものが、お手本のもつ力強さと簡潔さをもつようになるまでこれを繰り返すことです。
  • ハッカーになるには、自分を教育する意欲と自主性と能力が必要です。

Mike Gancarz, UNIXという考え方, オーム社, 2001

  • 偉大なプログラムは、追いつめられた人間が書く。あるアプリケーションを書かなければいけないとして、「それが実用的でなくてはならず」「どうやればできるか知っているエキスパートがまわりにおらず」、「それを『正しく』やる時間がない」とき、一片のすばらしいソフトウェアが書かれる可能性が非常に高くなる。

ジェラルド・M・ワインバーグ, プログラミングの心理学, 毎日コミュニケーションズ, 2005

  • たいていの場合われわれは、目をつぶって「えいや」とプログラミングをはじめてみるまでは、自分たちが何を欲しているのか知らないのだ。
  • 仕様はプログラムおよびプログラマとともに進化する。プログラム書きは、プログラマにとっても、またプログラム発注者にとっても、一つの学習プロセスである。
  • すぐれた開発者ほどウォークスルーやインスペクションに価値を見出し、そうでない開発者は価値を見出さないものだ。
  • 恐らく完全なプログラムが書かれたことは一度もない。
  • たった一人の利用者のために書かれたプログラムと「ソフトウェア」は、違ったものなのだ。
  • 一つのプログラムに効率と適応力を求めるのは、見栄えがよくてしかも気だてのよい配偶者を求めるようなものだ。
  • 品質とは誰かにとっての価値である。
  • 発見しようとしなければ発見に成功することはあり得ない。
  • 内観がなかったら、彼らはただひたすらに「虫」を出し続け、やがて虫に呑み込まれてしまうだろう。
  • 人々に注意を向ける管理者はよい結果を得る。
  • プロが作るソフトウエアは、開発者がコンピュータサイエンスの概念を把握しているということを示すだけでは済まない。
  • チームを単なるグループから区別しているのは、彼らの学習方法なのだ。……チームのメンバーは、製品のいかんに関わらず、つねに一つの目標を共有している——技量を高めるための学習において仲間を助ける、という目標を。
  • 公式の構造のみが組織における唯一の構造である、という思い込みのために起こった重大な失敗は少なくない……非公式的機構は必ず存在する。それを理解せずに物事を変更するのは危険だ。
  • 人の目は、見たくないものを見ないようにすることにかけては、ほとんど無限の容量を持っている。
  • こそこそと隠しだてをして、おれのプログラム、お前のプログラムなどということを考えるのは誤り、開放的で共有的なやり方が正しい。
  • メンバーの一人以上がグループの目標を自分のものとして共有していない場合、グループの達成度が落ちる……グループの目標に関する真のコンセサスを達成するには、グループ自身に目標を設定させる以上によい方法はない。
  • プログラマは単に何をするかではなく、なぜそうするかを知りたいと思うものだ。
  • クビを覚悟のリーダーだけが、成功への真のチャンスを握っている。
  • 「何もかもうまくいく」ことなど決してない。
  • 技量は得がたいが、折り合いと比べればどんな場合にもずっと得やすい。
  • 人々は自分の能力から見て役不足だ、と感じる仕事に飽きてしまう。
  • もしあるプログラマがかけがえのない人物だというなら、彼をできるだけ早く追い出せ。
  • 上司からの圧力は仕事を成し遂げるための方法でもあるとともに、報告システムを破壊する方法でもある。
  • たった一人「同盟者」がいることが、多くの人々に物事をありのままに見る勇気を与えるのだ……それは同調を強いる社会的圧力を和らげるための安全弁になる。
  • 否定的な見方をすることは必ずしも否定的な活動ではない。
  • 親しい友人が同時にもっとも厳格な批判者でもあることは不可能だ、などという理由は別段存在しない。
  • アマチュアが書くプログラムでは、予定されている利用者はほぼ例外なく彼自身だけである。それに対してプロは、他人が使うプログラムを書く。
  • プロは問題を決してアマチュアほど真に受けない。
  • どんなプログラムにも、払う注意、かける手間に関して適切なレベルというものがある。 -「よいプログラマになるためには」と「よい友情を打ち建てるには」とは似ている……その答えは、お互いに認め合うこと、個性を大切にすることにある。
  • 性格とは、個人が絶えず変化する環境に適合しようとして行う試みを決定し、またその試みによって修正されるところの、その個人の諸特性全体から成る固有の統合体である。
  • 性格に起因する問題は、その真の原因を明らかにすることなしには、解決したり緩和したりするための効果的な手段を講じることはできない。
  • 批判精神抜きの性格の強さは、安全弁抜きの蒸気ボイラーのようなもので……性格の強さに欠けた批判精神は、蒸気ボイラーなしの安全弁のようなものだ。
  • 目は見ることを予期しているものを見る傾向がある。
  • 問題回避行動は、高度な意味では確かに問題解決行動だが、訓練の足りない上司の目を惹くことが目的なら、あまり頭のよいやり方とはいえない。
  • 問題はプログラマを選ぶことよりはむしろ育てることにある……よいプログラマは作り出されるものであって、おのずと生まれてくるものではない。
  • 問題解決スタイルは個人ごとに独自である。
  • 虫は、プログラマがあきらめて、せかせかするのをやめたあと、はじめて絶滅することが多い。
  • 真の強さを持った真のプロフェッショナルは弱みを自認したとしても何も失いはしない。
  • 新しいものに対する恐怖、失敗への予感、および弱点を認めたくないという気持ちは、学習に対する直接的阻害要因になる。
  • 経験は、何も教えてくれないこともある。
  • 学習にとって、学習の必要性がもっとも強く感じられる瞬間ほど、つまりわれわれが誤りを発見した瞬間ほど神々しい時はない。
  • 道具を忌み嫌う職人は駄目な職人だ。
  • 自分のプログラムを審美的対象として眺めていみる、ということをたまにはしてみないプログラマは、真のプログラマとはいえないだろう。
  • たいていの人は、一定の相手との慣れ親しんだ関係を放棄して未知のものに乗り換えるくらいなら、ほとんどいくらでも、といっていいほどの苦痛を甘受する。
  • プログラミングとは、高々異なる種族の間の情報交換でしかあり得ない。
  • もとのプログラムに流れ図を添えたものが、もとのプログラム自身より理解しやすいという証拠は、読む人が原作者である場合を除けば見出されなかった。
  • プロのプログラマならばプロのドキュメント開発者としての資格がある、という保証はない。

エゴレス方式：他人にプログラムを読んでもらうプログラミング方式

  • 本人では気づきにくい誤りの検出
  • 他人が読みやすいようにプログラムを書くようになる
  • プログラムを知っている人が二人以上いるので、仕事の進み具合の現実的評価が得やすい
  • 判断が偏らない
  • 他人のプログラムを読むことで、よりよいプログラマになる

プログラマに必要な素質

  • 一週間以上の緊張状態に耐えられる能力
  • ある程度急速な変化に適応する能力
  • きれい好きな性格
  • 謙虚さ
  • ユーモアのセンス