Що таке негативний код?


340

Я читав статтю Вікіпедії про Дугласа Макілроя і знайшов цитату, в якій згадується

"Справжній герой програмування - це той, хто пише негативний код".

Що це означає?


15
Одним з моїх найпродуктивніших днів було викидання 1000 рядків коду. - Кен Томпсон
Раду Потоп

Відповіді:


501

Це означає скорочення рядків коду, шляхом видалення надмірностей або використання більш стислих конструкцій.

Дивіться, наприклад, цей відомий анекдот від оригінальної команди розробників Apple Lisa:

Коли команда Lisa наполягала на доопрацюванні свого програмного забезпечення в 1982 році, керівники проектів почали вимагати від програмістів подавати щотижневі форми звітів про кількість написаних рядків коду. Білл Аткінсон вважав це дурним. За тиждень, протягом якого він переписав підрахунок регіону QuickDraw, щоб було шість разів швидше, а на 2000 рядків коротше, він поставив форму "-2000". Ще через кілька тижнів менеджери перестали просити його заповнити форму, і він із задоволенням виконав це.


257
Досконалість досягається не тоді, коли більше нічого не можна додати, але коли не залишається нічого брати - Антуан де Сент-Екзюпері
systempuntoout

7
Чи #LOC є хорошим показником якості коду? Я міг би «мінімізувати» будь-який код C або C ++ і значно зменшити кількість рядків, але це було б кошмаром для підтримки.
JBRWilkinson

8
@systempuntout - і тоді з'явився Ейнстен "(Наукова теорія) повинна бути максимально простою, але не простішою"
День Джонатана,

32
Ніщо не працює швидше, або є більш надійним, або вимагає меншого обслуговування, ніж код, якого там немає. "Коли ви сумніваєтеся, зануріть це!"
TMN

4
@JBRWilkinson: Я б сказав, що існує "солодке місце" щодо короткості коду. Як правило, коротше краще, але настає момент, коли код може стати занадто стислим і не легко розшифрувати іншого програміста.
GordonM

131

Існує цитата Білла Гейтса за принципом вимірювання продуктивності програміста за кодовими рядками - це як вимірювання прогресу будівництва літака за вагою.

Я хотів би додати, що метрика LOC заохочує використання надмірно довгих мов та навмисне винаходити колесо для задоволення квоти.


30
Так, це проблема з будь-якими показниками. Як тільки ви використовуєте їх для оцінки ефективності людей, вони почнуть грати в номери.

5
Хтось насправді коли-небудь використовував LOC як показник продуктивності? Я бачив, що він використовується лише для таких речей, як "про помилку проекту, про який ми говоримо тут?"
Майкл Боргвардт

5
@Michael: так. На жаль, так.
Майкл Петротта

4
ми говоримо про того самого Білла Г., який має компанію, яка за цією метафорою виробляє 10000 реактивних струменів GTON? :)
Даніель Мошмодор

37
Програміст, який написав код на бортові комп'ютери Space Shuttle, сказав мені, що він повинен враховувати вагу програмного забезпечення! Програмне забезпечення було реальним (гроші за це платили); це було на човника; вагу всього, що завантажується в човник, потрібно враховувати. Перший приклад вимірювання продуктивності програміста за вагою коду. (Нуль не було дозволено, тому він вказав 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 геніальна! Це досить засмучує те, що вчитель дискваліфікував програму. Зрештою, таблиці пошуку (на які програма чимось схожа) безумовно можна знайти в реальному програмуванні.
Noctis Skytower

6
Мудрий учитель, можливо, прийняв цю БАЗОВУ програму і використав її, щоб підкреслити важливість отримання права СРС. Нагадує мені тренера з бейсболу, який так розчарувався зі своєю командою, що, щоб показати їм, як грати, він взяв биту, отримав три удари поспіль і, щоб не переборщити, він кричав своїй команді: "Бач! Ось як ти ***** грають. Тепер візьміть биту і грайте належним чином! ". Також нагадує мені людину, яка написала "творіння побачила творця і почервоніла" і виграла конкурс есе на "вино".
Nav

3
@Nav: Нагадує мені подібну історію, яка починається так само. Тоді тренер кидає м'яч у повітря, гойдається та промахується. Він знову кидає його в повітря, гойдається і промахується. Він кидає його в повітря втретє, хитається і сумує. Потім він каже команді: "Дивіться, ТАК, як ви повинні пітчінг!" (Я поняття не маю, що ця історія може мати відношення до розробки програмного забезпечення.)
Jay,

13
Я був би дуже засмучений, якби мене дискваліфікували за це. Детермінована проблема заслуговує детермінованого рішення, правда? Коли я пишу програму "Hello World", я не кодую її, щоб перевірити, чи правильно написано "Hello".
Кірк Бродхерст

34

Це язик у щоку. Якщо це коштує вам $ N за середньо закодований рядок, то кодування "негативних рядків", безумовно, є переможцем.

Це означає, що як практична порада, той маленький код, який виконує завдання, набагато краще, ніж великий код, який робить те саме, що всі інші речі рівні.


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 для вашого коментаря.
ЛукаB

9

Відповідь Тіло, мабуть, найбільш точна історично, але метафора «негативного коду» також може включати продуктивність та використання пам’яті - винагороджуючи зусилля, щоб відкласти виконання чи розподіл чогось, поки це фактично не потрібно.

Ця ментальність "зволікання з оплатою" спричинила такі аксіоми "що робити щось", наприклад, "Робити нічого не завжди швидше, ніж щось робити", "Найшвидший код - це код, який ніколи не виконується", і "Якщо ви можете відкласти це досить довго, вам, можливо, ніколи не доведеться цього робити "(мається на увазі відстрочка дорогих операцій, поки фактично не потрібно)

Однією з методів реалізації негативного коду є оскарження початкових припущень та визначень проблеми. Якщо ви можете переосмислити проблемний / вхідний домен таким чином, що "липкий випуск №3" категорично неможливий, то вам не доведеться витрачати час або код на вирішення липкої проблеми №3. Ви усунули код, оптимізувавши дизайн.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.