Когда, если вообще, "число строк кода" является полезной метрикой?

Question

Некоторые люди утверждают, что худшим врагом кода является его размер, и я склонен согласиться. Тем не менее, каждый день вы продолжаете слышать такие вещи, как

• Я пишу бессмысленные строки кода за день.
• У меня есть x строк кода.
• Windows - это миллион строк кода.

Вопрос: Когда «строки кода» полезны?

ps: обратите внимание, что когда делаются такие заявления, звучит «больше, тем лучше».

Answer 1

Я бы сказал, что когда вы удаляете код , чтобы проект работал лучше.

Сказать, что вы удалили "X количество линий", впечатляет. И гораздо полезнее, чем вы добавили строки кода.

Answer 2

Я удивлен, что никто не упомянул знаменитую цитату Дейкстры, так что вот так:

Сегодня я хочу сказать, что, если мы хотим посчитать строки кода, мы должны рассматривать их не как «произведенные строки», а как «потраченные строки»: текущая общепринятая мудрость настолько глупа, что забывать, что они рассчитывают на неправильное сторона бухгалтерской книги.

Цитата из статьи под названием " О жестокости по-настоящему обучения информатике ".

Answer 3

Это ужасный показатель, но, как отметили другие, он дает вам (очень) грубое представление об общей сложности системы. Если вы сравниваете два проекта, A и B, и A - это 10000 строк кода, а B - 20 000, это мало о чем говорит - проект B может быть слишком многословным или A может быть сверхсжатым.

С другой стороны, если один проект содержит 10 000 строк кода, а другой - 1 000 000 строк, второй проект в целом значительно сложнее.

Проблемы с этим показателем возникают, когда он используется для оценки производительности или уровня вклада в какой-либо проект. Если программист «X» записывает в 2 раза больше строк, чем программист «Y», он может или не может вносить больший вклад - возможно, «Y» работает над более сложной проблемой ...

Answer 4

Когда хвастаешься друзьям.

Answer 5

По крайней мере, не для прогресса:

«Измерение прогресса в программировании по строкам кода похоже на измерение прогресса в самолетостроении по весу». - Билл Гейтс

Answer 6

Это полезно при загрузке вашего линейного принтера, чтобы вы знали, сколько страниц будет содержать распечатанный код. ;)

Answer 7

Есть один частный случай, когда я нахожу это бесценным. Когда вы проходите собеседование, и вам говорят, что частью вашей работы будет поддержание существующего C ++ / Perl / Java / и т. Д. унаследованный проект. Спросите интервьюера, сколько KLOC (приблизительно) вовлечено в унаследованный проект, даст вам лучшее представление о том, хотите ли вы их работу или нет.

Answer 8

как и большинство показателей, они очень мало значат без контекста. Итак, короткий ответ: никогда (кроме строчного принтера, это смешно! Кто сегодня печатает программы?)

Пример:

Представьте, что вы юнит-тестирование и рефакторинг старого кода. Он начинается с 50 000 строк кода (50 KLOC) и 1000 видимых ошибок (неудачные модульные тесты). Соотношение 1K / 50KLOC = 1 ошибка на 50 строк кода. Очевидно, это ужасный код!

Теперь, несколько итераций спустя, вы уменьшили известные ошибки наполовину (и неизвестные ошибки более чем вероятно) и основание кода в пять раз с помощью примерного рефакторинга. Соотношение теперь составляет 500/10000 = 1 ошибка на 20 строк кода. Что, видимо, еще хуже!

В зависимости от того, какое впечатление вы хотите произвести, это может быть представлено как одно или несколько из следующего:

• 50% меньше ошибок
• в пять раз меньше кода
• 80% меньше кода
• 60% ухудшение отношения ошибок к коду

все это правда (при условии, что я не облажался с математикой), и все они отстой , подводя итог огромному улучшению, которого, должно быть, достигли такие усилия по рефакторингу.

Answer 9

напоминает мне об этом:

Настоящее письмо очень длинное, просто потому, что у меня не было свободного времени, чтобы его сократить
- Блез Паскаль.

Answer 10

Перефразируя цитату, которую я прочитал около 25 лет назад,

"Проблема использования строк кода в качестве метрики заключается в том, что он измеряет сложность решения , а не сложность проблемы ".

Я полагаю, что цитата дана Дэвидом Парнасом в статье в журнале ACM.