Что такое отрицательный код?

339

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

«Настоящий герой программирования - тот, кто пишет отрицательный код».

Что это обозначает?

terminology code-metrics

15

Одним из моих самых продуктивных дней было выбрасывание 1000 строк кода. - Кен Томпсон

— Раду Потоп

Связанный: quora.com/How-many-lines-of-code-do-professional-program ...

— Pacerier

500

Это означает сокращение строк кода путем устранения избыточности или использования более лаконичных конструкций.

Посмотрите, например, этот известный анекдот от оригинальной команды разработчиков Apple Lisa:

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

— Тило
источник

257

Совершенство достигается не тогда, когда больше нечего добавить, а когда нечего взять - Антуан де Сент-Экзюпери

— systempuntoout

7

Является ли #LOC хорошим показателем качества кода? Я мог бы «минимизировать» любой код на C или C ++ и значительно сократить количество строк, но это было бы кошмаром для обслуживания.

— JBRWilkinson

8

@systempuntout - а потом была идея Эйнстена "(Научная теория) должна быть настолько простой, насколько это возможно, но не проще"

— Джонатан Дэй

32

Ничто не работает быстрее, не более надежно и не требует меньшего обслуживания, чем код, которого там нет. "Если сомневаешься, откажись!"

— TMN

4

@JBRWilkinson: я бы сказал, что есть «сладкое пятно» относительно краткости кода. Как правило, чем короче, тем лучше, но наступает момент, когда код может стать слишком кратким, и его будет нелегко расшифровать другим программистом.

— ГордонМ

131

Есть цитата Билла Гейтса о том, как измерять производительность программиста по строкам кода - это как измерять прогресс в авиастроении по весу.

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

— Kyralessa
источник

30

Да, это проблема с любой метрикой. Как только вы используете их для оценки производительности людей, они начнут разыгрывать цифры.

5

Кто-нибудь когда-либо использовал LOC в качестве показателя производительности? Я только видел, что это используется для таких вещей, как "о какой ошибке проекта мы говорим здесь?"

— Майкл Боргвардт

5

@ Майкл: да. К сожалению, да.

— Майкл Петротта

4

мы говорим о том же Билле Г., у которого есть компания, которая по этой метафоре выпускает 10000 GTON джетов? :)

— Даниэль Мошмондор

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

Эта базовая программа великолепна! Очень расстраивает то, что учитель дисквалифицировал программу. В конце концов, таблицы поиска (с которыми программа чем-то похожа) определенно можно найти в реальном программировании.

— Noctis Skytower

6

Мудрый учитель, возможно, принял эту базовую программу и использовал ее, чтобы подчеркнуть важность правильного получения SRS. Напоминает мне тренера по бейсболу, который так расстроился из-за своей команды, что, чтобы показать им, как играть, он взял биту, получил три удара подряд и, чтобы не отставать, он крикнул своей команде: «Смотрите! ***** играют. А теперь возьми биту и играй правильно! ». Также напоминает мне человека, который написал «творение увидел создателя и покраснел» и выиграл конкурс сочинений на тему «вина».

— 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. Поэтому я написал отрицательный код.

— LucaB
источник

3

Кроме того, написание меньшего количества LOC означает, что вы можете делать меньше ошибок и легко их обнаруживать

— LucaB

3

Это не относится к Haskell и другим языкам, которые могут быть сжаты до случайного шума. :)

— Маке

1

Конечно, моя точка зрения заключалась не в «сжатии кода», а в написании эффективных алгоритмов, которые добиваются меньших результатов за меньшее LOC :) +1 для вашего комментария.

— LucaB

9

Ответ Тило, вероятно, является наиболее точным в историческом плане, но метафора «отрицательный код» может также включать производительность и использование памяти - вознаграждение за попытки отложить выполнение или выделение чего-либо до тех пор, пока это действительно не понадобится.

Этот менталитет «промедление платит» породил такие насмешливые аксиомы, как «Ничего не делать всегда быстрее, чем делать что-то», «Самый быстрый код - это код, который никогда не выполняется» и «Если вы можете отложить его достаточно долго, вам, возможно, никогда не придется делать это "(имеется в виду отсрочка дорогостоящих операций, пока они не потребуются)

Одним из способов реализации отрицательного кода является оспаривание исходных предположений и определений проблемы. Если вы можете переопределить проблемную / входную область таким образом, что «проблема-залипание № 3» категорически невозможна, вам не придется тратить время или код на решение проблемы-залипания № 3. Вы устранили код, оптимизировав дизайн.

— dthorpe
источник