11

1989 年 2 月 2 日付けのページ (ページ 1) があり、以前の上司から提示された、プログラミングに関する Niman の 13 の最小限の十分な戒めの概要が説明されています。(彼はそれらが時代遅れであることを認識していたため、これは現代の一連のガイドラインというよりも考古学の作品になっています。) それらを見たことがない場合は、次のとおりです。

  1. 何を意図しているかを説明するために、コードに適切なコメントを付けなければなりません。人間は記憶術だけでは考えません。
  2. 数値定数を意味のあるシンボル名と同一視しなければなりません。はっきりと話し、異教徒のアイコンを避けてください。
  3. モジュール内のすべての入力と出力を記述する必要があります。あなたのモジュールを保守しなければならないかもしれないあなたのソフトウェアの兄弟姉妹に親切にしてください。
  4. あなたはあなたの改訂を適切に説明しなければなりません。あなたの仲間が心を読む人であることを期待するのは罪です. とにかく読心は罪です。
  5. アセンブリ コードの疑似コードの説明を提供する必要があります。確かに、アセンブリは COBOL ではありません。
  6. モジュールごとに 1 つの入口点と 1 つの出口点しか持たない必要があります。多くの入り口と出口を持っている人は、自分の体が同じように発達することを期待するでしょう.
  7. コードを開発する前に、コードを設計する必要があります。本当に、本当に。
  8. あなたは仲間と一緒にあなたのコードのレビューを行うべきです。彼らはオブジェクトコードを継承するからです。
  9. 設計を文書化し、コードを保守するすべての人が文書を利用できるようにする必要があります。確かに、それを拒む者はオペレーティングシステムのデバッグを永遠に地獄で行うことになるだろう。
  10. 彼らのコードに対する有意義な批判を受け入れることができなければなりません。もし自分のルールを恥じるなら、プロのボウラーになるべきだ。
  11. コードをライブラリ管理に配置する前に、コードを徹底的に (sic) テストする必要があります。聖書から除外された部分の 1 つは、ディーゼル エンジン コントローラーの一部である大規模な 8096 アセンブリ言語プログラムをデバッグすることによって、ヨブが神によってテストされた箇所です。リリース前に全体がテストされていません。さらに悪いことに、ジョブは Intel ツールを使用しなければなりませんでした。
  12. 可能な限り、グローバル データ構造の使用を避ける必要があります。タワーには Babel という名前を付ける必要がありますが、プログラムには名前を付けないでください。
  13. アセンブリ プログラマが、最適にコンパイルされた 20 世紀後半のコードの効率に匹敵しない場合は、高級言語を使用する必要があります。アセンブリは常に (速度とサイズの点で) 優れたコンパイラが生成できるものよりも効率的であると考える偽りの神々に注意してください。アセンブリ言語を実際に活用するには、コーディングだけでなく設計にも優れている必要があります。

私はインターネットを精査しましたが、これらの戒めやニマンの戒めの出所について何も明らかにしていません。これについて、また彼が言わなければならなかったかもしれない他のビットについてもっと調べようとして、私を殺していました. 私が持っている他の唯一の手がかりは、左下にイニシャル「DEN」があることです.NはNimanのNだと思いますが、テキストを特定するものは他にありません. そう、

A. ニマンとは誰ですか? (プログラマー? 教師? コンサルタント? 会社のランダムな男?)

B. このページは何でしたか? (古いプログラミングガイド? 会社のマニュアル? 昔の BBS? )

C. 残りはどこですか? (もっとありますか?他に何がありますか?これは独立したものでしたか?)

コメントに応えて、私の上司はその後亡くなりましたが、それ以前は、彼は長い間、白ひげを生やしてビジネスに携わっていました. 紙の色から、日付 (1989 年) が印刷されたおおよその日付であることがかなり確信で​​きます。

4

3 に答える 3

19

その男がドナルド・E・ナイマンだった可能性は十分にあります。

  • Donald E. Niman を検索すると、いくつかの結果が得られます。

    • 彼は、カリフォルニア州ランチョ クカモンガにある Safetran Systems Corporation のソフトウェア エンジニアでした。
    • 彼は 1999 年頃、SETI@Home を行う BOINC で活動していました。
    • 彼はいくつかの数学フォーラムでいくつかのアクティブな投稿をしました
    • 彼は、ソビエトの電卓を収集するサイトのゲストブックに 1 つの投稿をしていました(私には読み込まれないので、Google にキャッシュする必要があるかもしれません)。

  • 「ドナルド・ナイマン」を検索すると、次のように表示されます。

この研究は確かにひどく「ストーカー」のように見えますが、男性に関するこれらのいくつかの詳細を考えると、彼は確かに「プログラミングの戒め」を書く誰かのペルソナと一致します.

彼には、オンラインで入手できる連絡先がいくつかあります。彼に連絡を取って、彼が本当の作者かどうかを調べることができるかもしれません. また、元上司が 1989 年に働いていた都市に彼が住んでいたかどうかは、彼の Google プロフィール ページからわかるかもしれません。

于 2009-10-01T11:37:29.373 に答える
11

私は Nosredna に同意します - あなたの上司がそれを書いたか、複数の情報源からまとめたものだと思います。

しかし、私はそれらのいくつかを書き直すことに触発されたと感じました:

  1. コメントなしで読めるコードを書くべきです。
  2. 合理的な範囲内で、数値定数を意味のあるシンボル名と同一視する必要があります。x > ZERO は妥当ではありません。
  3. （そのまま）
  4. ソース管理を使用し、ソースにリビジョン コメントを配置しないでください。
  5. あなたの名前がSteve Gibsonでない限り、あなたは Assembly と書かないでください。
  6. 必要に応じて、ガード句と例外を使用する必要があります。
  7. あなたはあなたのコードを設計しなければなりませんが、TDD は設計です。
  8. （そのまま）
  9. 理由なく文書を作成したり、文書が古くなったりすることを許してはなりません。
  10. （そのまま）
  11. ソース管理に配置する前に、コードがコンパイルされ、単体テストが存在し、合格することを保証する必要があります。ビルドを壊した人には、おできが発生する可能性があります。
  12. 可能な限り、グローバル データ構造の使用を避ける必要があります。これにはシングルトンが含まれます。
  13. プロファイリング、告白、自己鞭打ちなしに最適化を避けるべきです。
于 2009-09-26T01:22:28.803 に答える
4

Mark が見つけた Donald E. Niman は正しいものです。私だからわかるはずです。これは、インディアナ州コロンバスの Cummins Electronics, Inc. に勤務していた 22 年前に書いたものです。それは少し時代遅れであり、それ以来私は物事を学んだので、それはことわざの塩の粒と見なされるべきです. ドナルド E. ナイマン、アリゾナ州フェニックス。

于 2010-09-06T13:36:43.830 に答える