Я читав статтю Вікіпедії про Дугласа Макілроя і знайшов цитату, в якій згадується
"Справжній герой програмування - це той, хто пише негативний код".
Що це означає?
Я читав статтю Вікіпедії про Дугласа Макілроя і знайшов цитату, в якій згадується
"Справжній герой програмування - це той, хто пише негативний код".
Що це означає?
Відповіді:
Це означає скорочення рядків коду, шляхом видалення надмірностей або використання більш стислих конструкцій.
Дивіться, наприклад, цей відомий анекдот від оригінальної команди розробників Apple Lisa:
Коли команда Lisa наполягала на доопрацюванні свого програмного забезпечення в 1982 році, керівники проектів почали вимагати від програмістів подавати щотижневі форми звітів про кількість написаних рядків коду. Білл Аткінсон вважав це дурним. За тиждень, протягом якого він переписав підрахунок регіону QuickDraw, щоб було шість разів швидше, а на 2000 рядків коротше, він поставив форму "-2000". Ще через кілька тижнів менеджери перестали просити його заповнити форму, і він із задоволенням виконав це.
Існує цитата Білла Гейтса за принципом вимірювання продуктивності програміста за кодовими рядками - це як вимірювання прогресу будівництва літака за вагою.
Я хотів би додати, що метрика LOC заохочує використання надмірно довгих мов та навмисне винаходити колесо для задоволення квоти.
Коли я був у середній школі - і так, у нас були комп’ютери ще в 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"
Студент, який написав цей запис, зазначив, що не тільки він був короткий і дуже ефективний, але алгоритм повинен бути очевидним для всіх, хто має навіть мінімальні знання з програмування, що робить програму високорентабельною.
Це язик у щоку. Якщо це коштує вам $ N за середньо закодований рядок, то кодування "негативних рядків", безумовно, є переможцем.
Це означає, що як практична порада, той маленький код, який виконує завдання, набагато краще, ніж великий код, який робить те саме, що всі інші речі рівні.
Написання тієї самої програми з меншим кодом - мета для всіх.
Якщо програма взяла до коду 200 LOC, а я записую її в 150, я написав -50 LOC. Тому я написав негативний код.
Відповідь Тіло, мабуть, найбільш точна історично, але метафора «негативного коду» також може включати продуктивність та використання пам’яті - винагороджуючи зусилля, щоб відкласти виконання чи розподіл чогось, поки це фактично не потрібно.
Ця ментальність "зволікання з оплатою" спричинила такі аксіоми "що робити щось", наприклад, "Робити нічого не завжди швидше, ніж щось робити", "Найшвидший код - це код, який ніколи не виконується", і "Якщо ви можете відкласти це досить довго, вам, можливо, ніколи не доведеться цього робити "(мається на увазі відстрочка дорогих операцій, поки фактично не потрібно)
Однією з методів реалізації негативного коду є оскарження початкових припущень та визначень проблеми. Якщо ви можете переосмислити проблемний / вхідний домен таким чином, що "липкий випуск №3" категорично неможливий, то вам не доведеться витрачати час або код на вирішення липкої проблеми №3. Ви усунули код, оптимізувавши дизайн.