負のコードとは何ですか?


340

ダグラス・マキロイに関するウィキペディアの記事を読んでいて言及している引用を見つけました

「プログラミングの真のヒーローは、ネガティブなコードを書く人です。」

どういう意味ですか?


15
私の最も生産的な日々の1つは、1000行のコードを捨てることでした。-ケントンプソン
ラドゥポトップ

回答:


501

冗長性を削除するか、より簡潔な構成を使用して、コードの行を減らすことを意味します。

たとえば、元のApple Lisa開発チームからのこの有名な逸話を参照してください。

Lisaチームが1982年にソフトウェアの完成を推し進めていたとき、プロジェクトマネージャーは、プログラマーが書いたコードの行数を報告する毎週のフォームを提出することをプログラマーに要求し始めました。ビル・アトキンソンはそれはばかげていると思った。QuickDrawの領域計算ルーチンを6倍速く、2000行短くなるように書き直した週には、フォームに「-2000」を付けました。さらに数週間後、マネージャーはフォームに記入するよう彼に求めるのをやめ、喜んで応じました。


257
追加するものが何もないときではなく、取るものが何もないとき、完璧が達成されます- アントワーヌドサンテグジュペリ
-systempuntoout

7
#LOCはコード品質の良い尺度ですか?CやC ++のコードを「ミニファイ」して行数を大幅に減らすことはできますが、それを維持するのは悪夢です。
-JBRウィルキンソン

8
@systempuntout-そして、アインステンの「(科学的理論)は可能な限りシンプルであるべきですが、シンプルではないはずです」
ジョナサンデイ

32
そこにないコードよりも速く動作したり、信頼性が高くなったり、メンテナンスの必要性が減ったりすることはありません。「疑わしいときは、それを切り捨ててください!」
TMN

4
@JBRWilkinson:コードの簡潔さに関して「スイートスポット」があると思います。一般に、短いほど良いですが、コードが簡潔になりすぎて、他のプログラマーに解読しにくい場合があります。
GordonM

131

プログラマーの生産性をコードの行で測定するという行に沿ったビル・ゲイツの引用があります。これは、航空機の建物の進捗を重量で測定するようなものです。

LOCメトリックは、過度に長すぎる言語の使用を奨励し、クォータを満たすために意図的にホイールを再発明したことを付け加えます。


30
ええ、それはあらゆる種類のメトリックの問題です。それらを使用して人々のパフォーマンスを判断するとすぐに、彼らは数字を賭け始めます。

5
パフォーマンスメトリックとしてLOCを実際に使用したことがある人はいますか?「プロジェクトのバグはここでどのように話しているのか?」などに使用されるのを見ただけです。
マイケルボルグワード

5
@マイケル:はい。残念ながらそうです。
マイケルペトロッタ

4
私たちは、その比phorによって10000 GTONジェットを生産する会社を持つ同じビルGについて話しているのですか?:)
ダニエルモシュモンドール

37
スペースシャトルの搭載コンピューター用のコードを書いたプログラマーは、ソフトウェアの重量を考慮しなければならないと言った!ソフトウェアは本物でした(お金が支払われました)。シャトルでした。シャトルに搭載されているすべての重量を考慮する必要があります。コードの重みでプログラマの生産性を測定する最初の例。(ゼロは許可されなかったため、彼は0.00001グラムを指定し、すべてが満足のいくものでした。)
マーク・ルートン

118

私が高校にいたとき-はい、私たちは石のナイフを使用して動物の皮からそれらを作らなければならなかったけれども、私たちは70年代にコンピュータを持っていました-数学教師の一人がプログラミングコンテストを行いました。ルールは、勝ったプログラムが正しい出力を生成し、実行時間のコード行の積が最小になるプログラムであるというものでした。つまり、プログラムが100行のコードを取得して5秒間実行すると、スコアは500になります。他の誰かが90行のコードを作成して6秒間実行すると、彼のスコアは540になります。

それは、簡潔さとパフォーマンスの両方に報いる、素晴らしいスコアリングシステムとして私を驚かせました。

しかし、技術的に勝利基準を満たしたエントリーは失格となりました。問題は、100未満のすべての素数のリストを印刷することでした。失格のエントリは次のようになりました(当時の学生のほとんどはBASICを使用していました)。

100 print "2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61,"
110 print "67, 71, 73, 79, 83, 87, 89, 91, 97"

そのエントリを書いた学生は、それが短くて非常に効率的であるだけでなく、プログラミングの最小限の知識さえあれば誰でもアルゴリズムが明白であり、プログラムを非常に保守しやすいものにするべきだと指摘しました。


10
コードの行を数えることが非常にゲーム性の高い指標であることのさらなる証拠:-)

44
そのBASICプログラムは素晴らしいです!教師がプログラムを失格させたのはかなり怒っています。結局のところ、ルックアップテーブル(プログラムはやや似ています)は、実際のプログラミングで間違いなく見つけることができます。
ノクティススカイタワー

6
賢明な教師は、このBASICプログラムを受け入れ、SRSを正しくすることの重要性を強調するためにそれを使用したかもしれません。野球のコーチがチームに非常に不満を抱いていたので、プレーの仕方を示すために、バットを取り、3回連続でストライキをし、負けないように、彼はチームに叫びました。 *****プレイ中です。今すぐバットを取り、適切にプレイしてください!」また、「クリエーションはクリエーターを見て顔を赤らめた」と書き、「ワイン」に関するエッセイコンテストで優勝した人物を思い出させます。
ナビゲーション

3
@Nav:同じように始まる似たような話を思い出します。その後、コーチは空中にボールを投げ、スイングしてミスします。彼はそれを再び空中に投げ、振り回し、逃します。彼はそれを3回目に空中に投げ、スイングしてミスします。それから彼はチームに言った、「それがあなたの投球の仕方だ!」(このストーリーがソフトウェア開発にどのような影響を与えるかはわかりません。)
ジェイ

13
私はこれに失格した場合、私はかなり怒っています。決定論的問題は決定論的解決策に値しますか?「Hello World」アプリを作成するとき、「Hello」のスペルが正しいかどうかを確認するためにコーディングしません。
カークブロードハースト

34

ほっそりしています。平均コード行あたり$ Nの費用がかかる場合、「負の行」のコーディングが確実に勝者となります。

これは、実用的なアドバイスとして、仕事を達成する小さなコードは、同じことをする大きなコードよりもはるかに優れていることを意味します。


2
どこから来たのかはわかりますが、簡潔で理解しやすい小さなフットプリントのコードが一度に達成されることはほとんどありません。通常は、動作するように(多くの行)、速度を最適化(少し少ない行)、保守/読みやすさを最適化(まだ少ない行)するように記述します。投資の長期リターンに伴う実際のコストは2番目と3番目のステップであるため、多くの場合、完全にスキップされます。「安く、速く、良いものがある-あなたは2つを選択するようになる」のようなものです。

2
実際、メンテナンスや読みやすさを最適化するIMEは、LOC を実際に増加させる可能性があります。コードを書き換えて自己文書化を強化すると、冗長になる傾向があるためです。

1
@Visage:「...他のすべてのものが等しい」。
アイラバクスター

重要なのは、簡潔なコードと冗長なコードでは、他のすべてのことを同じにすることはできないと思うことです。
トマスナロス

コードの平均行のコストが$ Nである理由は、最初にX行を書くことに時間を費やしているためです。次に、数回の繰り返しを経て、最終製品をYラインごとに減らします。その(X-Y)ため、リファクタリングの大虐殺によってすべての問題が取り除かれたため、残りの行は非常にコストがかかるようです。

27

より少ないコードで同じプログラムを書くことは、誰にとっても目標です。

プログラムのコーディングに200 LOCを要し、150で記述した場合、-50 LOCを記述しました。だから私は負のコードを書きました。


3
また、LOCの記述が少ないということは、エラーを減らして簡単に見つけることができることを意味します。
LucaB

3
Haskellおよびランダムノイズに圧縮できる他の言語には当てはまりません。:)
マッケ

1
確かに、私のポイントは「コードを圧縮する」ことではなく、より少ないLOCでシンニングを行う効率的なアルゴリズムを書くことです:) +1してください。
LucaB

9

Thiloの答えはおそらく歴史的に最も正確ですが、「ネガティブコード」のメタファーには、パフォーマンスとメモリの使用も含まれます。

この「原告が支払う」メンタリティは、「何もしないことは常に何かをするよりも速い」、「最速のコードは決して実行されないコードである」、「十分に長く延期できるなら、あなたはそれをする必要がないかもしれません」(実際に必要になるまで高価な操作を延期することを指す)

ネガティブコードを実現する1つの手法は、問題の初期の仮定と定義に挑戦することです。「スティッキーな問題#3」が明確に不可能になるように問題/入力ドメインを再定義できれば、スティッキーな問題#3を扱う時間やコードを費やす必要はありません。デザインを最適化することでコードを削除しました。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.