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

Question

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

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

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

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

Answer 1

Профиль зрелости процесса Института разработки программного обеспечения сообщества разработчиков программного обеспечения: обновление на конец 1998 года (к которому я, к сожалению, не смог найти ссылку) обсуждает опрос около 800 групп разработчиков программного обеспечения (или, возможно, это были магазины). Средняя плотность дефектов составляла 12 дефектов на 1000 LOC.

Если у вас было приложение с 0 дефектами (оно на самом деле не существует, но предположим) и вы написали в среднем 1000 LOC, вы можете предположить, что вы только что ввели 12 дефектов в систему. Если QA обнаружит 1 или 2 дефекта, и это все, то им нужно провести больше тестов, так как, вероятно, имеется более 10 дефектов.

Answer 2

Указывая, почему изменение займет так много времени.

"Windows - это 7 миллионов строк кода, и для проверки всех зависимостей требуется некоторое время ..."

Answer 3

Когда вы реорганизуете кодовую базу и можете показать, что вы удалили строк кода, и все регрессионные тесты все еще пройдены.

Answer 4

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

Answer 5

В соревнованиях.

Answer 6

Когда кодировщик не знает, что вы подсчитываете строки кода, и у него нет оснований специально добавлять избыточный код в игровую систему. И когда у всех в команде одинаковый стиль кодирования (поэтому есть известное среднее «значение» на строку.) И только если у вас нет лучшего измерения.

Answer 7

Проверьте определение Википедии: http://en.wikipedia.org/wiki/Source_lines_of_code

SLOC = 'исходные строки кода'

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

Из статьи в Википедии:

Существует два основных типа SLOC меры: физический SLOC и логический SLOC.

Еще один хороший ресурс: http://www.dwheeler.com/sloc/

Answer 8

Это очень полезная идея, когда она связана с количеством дефектов. «Дефекты» дают вам меру качества кода. Чем меньше «дефектов», тем лучше программное обеспечение; Почти невозможно удалить все дефекты. Во многих случаях один дефект может быть вредным и смертельным.

Однако не похоже, что существует неисправное программное обеспечение.

Answer 9

При определении уровня усилия (LOE). Если вы составляете предложение и у вас будет примерно столько же инженеров, работающих над новым проектом, то вы сможете определить, сколько инженеров понадобится на какой срок.

Answer 10

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

5000 строк Lisp! = 5000 строк C