これは、冗長性を削除するか、より簡潔な構成を使用することにより、コード行を減らすことを意味します。
たとえば、この 有名な逸話 を参照してくださいApple Lisa開発者チーム：
Lisaチームが1982年にソフトウェアの完成を推し進めていたとき、プロジェクトマネージャーはプログラマーに、作成したコードの行数を報告するフォームを毎週提出するように要求し始めました。ビル・アトキンソンはそれをばかげていると思った。彼がQuickDrawの領域計算ルーチンを6倍速く、2000行短くした週は、フォームに「-2000」と入力しました。さらに数週間後、マネージャーは彼にフォームへの記入を求めるのをやめ、彼は喜んで応じました。
コード行ごとにプログラマの生産性を測定する行に沿って、ビルゲイツの引用があります。これは、重量で航空機の建物の進行状況を測定するようなものです。
LOCメトリックが過度に時間のかかる言語の使用を奨励し、割り当てを満たすためにホイールを意図的に再発明したことを付け加えたいと思います。
私が高校生だったとき、そうです。70年代にはコンピューターがありましたが、石のナイフを使用して動物の皮からコンピューターを作る必要がありました。数学の先生の1人がプログラミングコンテストを実施しました。ルールは、優勝したプログラムは正しい出力を生成するプログラムであり、コード行と実行時間の積が最小であるというものでした。つまり、プログラムが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"
そのエントリーを書いた学生は、それが短くて非常に効率的だっただけでなく、アルゴリズムはプログラミングの最小限の知識さえあれば誰にでも明白であり、プログラムを高度に保守可能にすべきだと指摘しました。
ほほえみです。平均的なコード化された行ごとに$ Nのコストがかかる場合、「負の行」をコード化することは確かに勝者です。
これは、実用的なアドバイスとして、仕事を達成する小さなコードは、同じことを行う大きなコードよりもはるかに優れていることを意味します。
少ないコードで同じプログラムを書くことは誰にとっても目標です。
プログラムのコード化に200 LOCを使用し、それを150で記述した場合、-50 LOCを記述しました。だから私は否定的なコードを書いた。
Thiloの回答 はおそらく歴史的に最も正確ですが、「否定的なコード」のメタファーには、パフォーマンスとメモリの使用も含まれます。これは、実際に必要になるまで、実行または何かの割り当てを延期する努力に報います。
この「乱用給与」の考え方は、「何もしないことは常に何かをするよりも速い」、「最速のコードは決して実行されないコードである」、「十分に長く延ばすことができる場合、実行する必要がない場合もあります」（実際に必要になるまでのコストの高い操作の延期を指す）
否定的なコードを実現する1つの手法は、問題の初期の仮定と定義に挑戦することです。 「粘着性のある問題＃3」が絶対に不可能であるように問題/入力ドメインを再定義できる場合、粘着性の問題＃3を処理するために時間やコードを費やす必要はありません。デザインを最適化することでコードを排除しました。