Некоторые люди утверждают, что код худшего врага - его размер, и я склонен согласиться. Но каждый день вы продолжаете слышать такие вещи, как
Вопрос: Когда полезно использовать "# строк кода"?
ps: Обратите внимание, что когда такие утверждения сделаны, тон "больше лучше".
Я бы сказал, когда вы удаляете код, чтобы проект работал лучше.
Говорить, что вы удалили "X количество строк", впечатляет. И гораздо более полезно, чем вы добавили строки кода.
Я удивлен, что никто не упомянул знаменитую цитату Дейкстры, поэтому здесь идет:
Сегодня моя точка зрения заключается в том, что, если мы хотим подсчитать строки кода, мы не должны рассматривать их как "линии, созданные", а как "потраченные строки": существующая общепринятая мудрость настолько глупа, что книга рассчитана на неправильные стороне книги.
Цитата из статьи под названием " О жестокости действительно преподавания вычислительной науки".
Это ужасная метрика, но, как отметили другие люди, она дает вам (очень) грубую идею общей сложности системы. Если вы сравниваете два проекта: A и B и A - 10 000 строк кода, а B - 20 000, это не говорит вам о многом - проект B может быть чрезмерно подробным, или может быть суперсжато.
С другой стороны, если один проект составляет 10 000 строк кода, а другой - 1 000 000 строк, второй проект значительно более сложный.
Проблемы с этой метрикой возникают, когда они используются для оценки производительности или уровня вклада в какой-либо проект. Если программист "X" записывает 2x количество строк в качестве программиста "Y", он может или не может внести больше - возможно, "Y" работает над более сложной проблемой...
Когда хвастается за друзей.
Это полезно при загрузке линейного принтера, чтобы вы знали, сколько страниц будет печататься в списке кода, которое вы собираетесь распечатать.;)
Есть один частный случай, когда я считаю его неоценимым. Когда вы находитесь в интервью, и они говорят вам, что часть вашей работы будет заключаться в том, чтобы поддерживать существующий С++/Perl/Java/etc. старый проект. Задавая интервьюеру, сколько KLOC (приблизительно) вовлечено в унаследованный проект, даст вам более полное представление о том, хотите ли вы их работу или нет.
По крайней мере, не для прогресса:
"Измерение прогресса программирования по линиям кода подобно измерению прогресса самолета по массе". --Bill Gates
как и большинство показателей, они означают очень мало без контекста. Итак, короткий ответ: никогда (за исключением линейного принтера, это смешно! Кто печатает программы в эти дни?)
Пример:
Представьте, что вы тестируете единицы измерения и рефакторинг устаревшего кода. Он начинается с 50 000 строк кода (50 KLOC) и 1000 доказанных ошибок (неудачные модульные тесты). Соотношение 1K/50KLOC = 1 ошибка на 50 строк кода. Очевидно, это ужасный код!
Теперь, несколько итераций позже, вы уменьшили известные ошибки на половину (и неизвестные ошибки более чем на то, что наиболее вероятно) и базу кода в пять раз с помощью образцового рефакторинга. Теперь отношение составляет 500/10000 = 1 баг на 20 строк кода. Это, по-видимому, еще хуже!
В зависимости от того, какое впечатление вы хотите сделать, это может быть представлено как одно или несколько из следующих:
все они верны (предполагая, что я не испортил математику), и все они сосать, чтобы обобщить огромное улучшение, которое должно было выполнить такие усилия рефакторинга.
Ответ: когда вы можете говорить о отрицательных строках кода. Как и в: "Сегодня я удалил 40 посторонних строк кода, и программа все еще функционирует так же, как и раньше".
Существует много разных Software Metrics. Строки кода наиболее часто используются и легче всего понять.
Я удивляюсь, как часто строки кодовой метрики коррелируют с другими метриками. Вместо покупки инструмента, который может вычислять циклическую сложность для обнаружения запахов кода, я просто ищу методы со многими строками, и они также имеют высокую сложность.
Хорошим примером использования строк кода является метрика: Ошибки на строки кода. Это может дать вам понять, сколько ошибок вы должны найти в своем проекте. В моей организации обычно около 20 ошибок на 1000 строк кода. Это означает, что если мы готовы отправить продукт с 100 000 строк кода, а наша база данных ошибок показывает, что мы обнаружили 50 ошибок, то нам, вероятно, следует провести еще несколько тестов. Если у нас есть 20 ошибок на 1000 строк кода, мы, вероятно, приближаемся к качеству, в котором мы обычно находимся.
Плохой пример использования - это измерение производительности разработчика. Если вы измеряете производительность разработчика по линиям кода, тогда люди склонны использовать больше строк для доставки меньше.
Напоминает мне об этом:
Настоящее письмо очень длинное, просто потому, что у меня не было досуга, чтобы сделать его короче.
--Blaise Pascal.
Я согласен с тем, что общее число строк кода в проекте является одним из способов измерения сложности.
Это, конечно, не единственная мера сложности. Например, отладка 100 строк, запутанных Perl script, сильно отличается от отладки проекта на 5000 строк Java с шаблонами комментариев.
Но, не глядя на источник, вы, как правило, думаете, что более сложные строки кода сложнее, так же, как вы думаете, что исходный архив размером 10 МБ сложнее, чем исходный tarball на 15 КБ.
Это полезно во многих отношениях.
Я не помню точного #, но у Microsoft была веб-трансляция, о которой говорилось для каждых X строк кода, в среднем есть количество ошибок. Вы можете принять это утверждение и использовать его, чтобы дать базовый уровень для нескольких вещей.
Еще одна вещь, на которую мы смотрим, - почему так много строк? Часто, когда новый программист помещается в пробку, они просто копируют и вставляют куски кода вместо создания функций и инкапсуляции.
Я думаю, что я написал x строк кода за день, это ужасная мера. Он не учитывает трудности проблемы, язык, на котором вы пишете, и т.д.
Мне кажется, что существует конечный предел того, сколько строк кода я могу отнести к верхней части головы из любого данного проекта. Предел, вероятно, очень похож на среднего программиста. Поэтому, если вы знаете, что ваш проект имеет 2 миллиона строк кода, и ваши программисты могут быть уверены, что смогут понять, связана ли ошибка с 5K строками кода, которые они хорошо знают, тогда вы знаете, что вам нужно нанять 400 программисты для вашей базы кода хорошо защищены от памяти кого-то.
Это также заставит вас дважды подумать о том, как быстро увеличить свою базу кода, и может заставить вас подумать об их рефакторинге, чтобы сделать его более понятным.
Примечание. Я составил эти числа.
Перефразируя цитату, которую я прочитал около 25 лет назад,
"Проблема с использованием строк кода как метрики заключается в том, что он измеряет сложность решения, а не сложность проблемы".
Я считаю, что цитата из Дэвида Парнаса в статье в Журнале ACM.
Это показатель производительности, а также сложность. Как и все показатели, его нужно оценивать с осторожностью. Единственного показателя обычно недостаточно для полного ответа.
IE, 500-линейная программа не так сложна, как линия 5000. Теперь вам нужно задать другие вопросы, чтобы лучше просмотреть программу... но теперь у вас есть метрика.
Это отличный показатель для пугающих/впечатляющих людей. Об этом, и определенно о контексте, который я вижу во всех трех этих примерах.
Строки кода полезны для понимания, когда вам интересно, слишком ли большой файл кода. Hmmm... Этот файл теперь 5000 строк кода. Может быть, мне следует реорганизовать это.
Когда вам нужно запланировать количество перфокарт, вам нужно заказать.
Я написал 2 сообщения в блоге, посвященные про и минусам подсчета строк кода (LoC):
Как вы рассчитываете количество строк кода (LOC)?: Идея состоит в том, чтобы объяснить, что вам нужно подсчитать логическое число строк кода вместо физического счета. Для этого вы можете использовать такие инструменты, как NDepend.
Почему полезно подсчитывать количество строк кода (LOC)?: Идея заключается в том, что LoC никогда не следует использовать для измерения производительности, но еще больше для оценки охвата тестированием и оценки срока действия программного обеспечения.
Институт программной инженерии Процесс зрелости Профиль сообщества программного обеспечения: 1998 год End Update (к сожалению, я не мог найти ссылку, к сожалению) обсуждает опрос около 800 разработчиков программного обеспечения (или, возможно, это были магазины). Средняя плотность дефектов составляла 12 дефектов на 1000 LOC.
Если у вас есть приложение с 0 дефектами (оно не существует на самом деле, но пусть предположим) и написал 1000 LOC, в среднем вы можете предположить, что вы только что ввели 12 дефектов в систему. Если QA обнаруживает 1 или 2 дефекта и что это, тогда им нужно сделать больше тестов, так как есть, вероятно, еще 10 дефектов.
Когда вы рефакторинг базы кода и можете показать, что вы удалили строки кода, и все регрессионные тесты все еще прошли.
Линии кода не так полезны на самом деле, и если они используются в качестве метрики по управлению, это приводит к тому, что программисты делают много рефакторинга, чтобы повысить свои баллы. Кроме того, бедные алгоритмы не заменяются аккуратными короткими алгоритмами, потому что это приводит к отрицательному счету LOC, который рассчитывается против вас. Честно говоря, просто не работайте в компании, которая использует LOC/d в качестве показателя производительности, потому что руководство явно не имеет никакого представления о разработке программного обеспечения, и поэтому вы всегда будете на обратной стороне с первого дня.
Когда указывается, почему изменения будут длиться так долго.
"Windows - 7 миллионов строк кода, и для проверки всех зависимостей требуется некоторое время..."
В соревнованиях.
Когда кодер не знает, что вы подсчитываете строки кода, и поэтому не имеет смысла преднамеренно добавлять избыточный код в игру в систему. И когда у каждого в команде одинаковый стиль кодирования (поэтому в строке есть известное среднее значение). И только если у вас нет лучшей меры.
Проверьте определение википедии: http://en.wikipedia.org/wiki/Source_lines_of_code
SLOC = 'исходные строки кода'
На эти показатели, в которых я работаю, на самом деле довольно много времени. Существуют также различные способы подсчета SLOC.
Из статьи в википедии:
Существует два основных типа SLOC меры: физический SLOC и логический SLOC.
Еще один хороший ресурс: http://www.dwheeler.com/sloc/
Как уже отмечалось большинством людей, это может быть неоднозначная метрика, особенно если вы сравниваете кодирование людей на разных языках.
5000 строк Lisp!= 5000 строк C
Это очень полезная идея, когда она связана с количеством дефектов. "Дефекты" дают вам качество кода. Наименее "дефекты" - лучшее программное обеспечение; Почти невозможно удалить все дефекты. Во многих случаях один дефект может быть вредным и смертельным.
Однако, похоже, что существует небезопасное программное обеспечение.
При определении уровня усилия (LOE). Если вы соберете предложение, и у вас будут примерно одинаковые инженеры, работающие над новым проектом, тогда вы сможете определить, сколько инженеров потребуется в течение долгого времени.