Когда, если когда-нибудь, “количество строк кода” полезная метрика?

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

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

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

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

Количество строк кода зависит от языка.

Например, одна строка кода C стоит в среднем x строк кода ASM. 1 строка C ++ -> C и т.д ....

Java и C # инкапсулируют довольно много строк кода из-за фоновой поддержки со стороны виртуальной машины.

Это так часто используется во время торговых презентаций. Например, KLoC (Kilo Lines of Code) или LoC используется для демонстрации компетенции организации-поставщика в отношении больших / сложных систем. Это особенно верно, когда поставщик пытается продемонстрировать свою способность ОБСЛУЖИВАТЬ сложные устаревшие системы. В рамках переговоров иногда организация-заказчик предоставляет репрезентативный фрагмент кода для выполнения Proof of Concept с поставщиком, чтобы проверить его возможности. Этот репрезентативный код будет иметь достаточно сложностей, с которыми компания-поставщик сможет справиться, и ее коммерческое предложение о "поддержании" системы с несколькими миллионами LoC "могут оказаться незамеченными.

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

При указании, почему изменение собирается занять много времени.

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

Я сказал бы, что это - когда Вы удаление код для создания проекта выполненным лучше.

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

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

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

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

От статьи Википедии:

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

Другой хороший ресурс: http://www.dwheeler.com/sloc/

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

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

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

Я удивлен, что никто еще не упомянул известную кавычку Dijkstra, таким образом, здесь идет:

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

кавычка от статьи, названной" На жестокости действительно обучающей вычислительной науки ".

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

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

проблемы с этой метрикой входят, когда она используется для оценки производительности или уровня вклада в некоторый проект. Если программист "X" записи 2x количество строк как программист 'Y", он мог бы или не мог бы способствовать более - возможно, "Y", работает над более трудной проблемой...

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

При хвастовстве друзьям.

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

Ответ: когда можно говорить об отрицательных строках кода. Как в: "Я удалил 40 посторонних строк кода сегодня, и программа все еще функционирует, а также прежде".

Это полезно во многих отношениях.

я не помню точный #, но Microsoft имела веб-бросок, который говорил о для каждых X строк кода в среднем существует y количество ошибок. Можно взять тот оператор и использовать его для предоставления базовой линии для нескольких вещей.

• , Как хорошо рецензент кода делает их задание.
• уровень квалификации оценки 2 сотрудников путем сравнения их отношения ошибки по нескольким проектам.

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

я думаю, что я записал, что x строки кода за день являются ужасной мерой. Это не берет счета на трудность проблемы, язык Ваша запись в, и так далее.

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

Это - конечно, не единственная мера сложности. Например, отладка запутываемого сценария Perl 100 строк очень отличается от отладки 5 000 проектов Java строки с шаблонами комментария.

, Но не смотря на источник, Вы обычно думали бы, что больше строк кода более сложно, так же, как Вы могли бы думать, что источник 10 МБ tarball более сложен, чем источник 15 КБ tarball.

Мне кажется, что существует конечный предел того, к какому количеству строк кода я могу обратиться первое, что пришло на ум из любого данного проекта. Предел, вероятно, очень похож для среднего программиста. Поэтому, если Вы знаете, что Ваш проект имеет 2 миллиона строк кода, и Ваши программисты, как могут ожидать, будут в состоянии понять, связана ли ошибка с 5K строками кода, который они знают хорошо, тогда Вы знаете, что необходимо нанять 400 программистов для кодовой базы, которая будет хорошо покрыта от чьей-то памяти.

Это также заставит Вас думать дважды о росте Вашей кодовой базы слишком быстро и могло бы заставить Вас думающий о рефакторинге его делать его более понятным.

Примечание я составил эти числа.

Это - метрика производительности, а также сложность. Как все метрики, это должно быть оценено с осторожностью. Одиночная метрика обычно не достаточна для полного ответа.

IE, 500 программ строки совсем не так же сложны как 5 000 строк. Теперь необходимо задать другие вопросы для получения лучшего представления программы..., но теперь у Вас есть метрика.

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

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

пример:

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

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

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

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

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

Строки кода полезны для знания, когда Вы задаетесь вопросом, становится ли файл кода слишком большим. Хм... Этот файл является теперь 5 000 строк кода. Возможно, я должен осуществить рефакторинг это.

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

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

А хороший пример использования строк кода находится в метрике: Ошибки на строки кода. Это может дать Вам шестое чувство того, сколько ошибок необходимо ожидать находить в проекте. В моей организации мы обычно - приблизительно 20 ошибок на 1 000 строк кода. Это означает, что, если мы готовы поставить продукт, который имеет 100 000 строк кода, и наша база данных ошибки показывает, что мы нашли 50 ошибок, тогда мы должны, вероятно, сделать еще некоторое тестирование. Если у нас есть 20 ошибок на 1 000 строк кода, то мы, вероятно, приближаемся к качеству, в котором мы обычно.

А плохой пример использования должен измерить производительность разработчика. Если Вы измеряете производительность разработчика строками кода, то люди склонны использовать больше строк для поставки меньше.

Я записал 2 сообщения в блоге, детализирующие про и недостатки подсчета Строк кода (LoC):

, Как проводят Вас подсчет Ваше количество Строк кода (LOC)? : идея состоит в том, чтобы объяснить, что необходимо считать логическое количество строк кода вместо физического количества. Чтобы сделать так, можно использовать инструменты как NDepend, например.

, Почему полезно считать количество Строк кода (LOC)? : идея состоит в том, что LoC никогда не должен использоваться, чтобы измерить производительность, но больше сделать оценку тестового покрытия и оценку крайнего срока программного обеспечения.

Когда необходимо планировать для количества перфокарт, необходимо заказать.

Я слышал, что Microsoft раньше увольняла 5% людей каждые 6 месяцев, я всегда предполагал, что это будет основано на строках записанного кода, который является, почему Windows является настолько большим, медленным и неэффективным;). Строки кода являются полезной метрикой для измерения сложности приложения с точки зрения грубого упорядочивания, т.е. программа новичков в Основном могла бы быть 10 строками кода, 100 строк кода игрушечное приложение, 50 000 строк разумное приложение размера, 10 миллионов строк кода чудовище, названное Windows.

Строки кода не являются очень полезной метрикой, хотя, я раньше писал игры в ассемблере (68000 главным образом), они будут иметь размеры в приблизительно в 50k строки кода, но я подавил количество строк кода, не продвинув регистры к стеку и отслеживая то, что содержалось в регистрах для сокращения размера кода (другие программисты, которых я знал, сделал нажатие несколько d0-d7, a0-a6 к стеку, который, очевидно, замедляет код, но упрощает отслеживание того, что затронуто).

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

Количество кодов, добавленных для данной задачи в основном, зависит от того, кто пишет код. Это не должно использоваться в качестве меры производительности. Данный человек может продолжить 1 000 линий избыточного и замысловатого дерьма, в то время как та же проблема могла быть решена другим человеком в 10 кратких строках кода. При попытке использовать LOC, добавленный, поскольку должна также быть принята во внимание метрика, "кто" учитывает.

на самом деле полезная метрика была бы "количеством дефектов, найденных против количества добавленных строк". Это дало бы Вам признак возможностей кодирования и тестового покрытия данной команды или человека.

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

Это уже - главным образом добавление к volumnous комментарий.. Но в основном, строки кода (или возможно totalCharacterCount/60) указывают на размер монстра. Как несколько человек сказали, который дает ключ к разгадке сложности кодовой базы. Это находится на одном уровне сложности оказывает большое влияние. Частично это оказывает влияние на то, как трудный это должно постигать систему и внести изменение.

Вот почему люди хотят меньше строк кода. В теории меньше строк кода менее сложно, и существует меньше места для ошибки. Я не уверен, что знание, которое заранее ужасно полезно для чего-либо кроме оценки и планирования.

, Например: Предполагаемый у меня есть проект, и на поверхностном исследовании я понимаю, что вопрос включит изменение целых 1 000 строк кода в рамках приложения, которое имеет 10 000 строк. Я знаю, что этот проект, вероятно, займет больше времени, чтобы реализовать, быть менее стабильным, и занять больше времени, чтобы отладить и протестировать.

Это также чрезвычайно полезно для понимания объема изменения между двумя сборками. Я записал немного программы, которая проанализирует объем изменения между любыми двумя изменениями SVN. Это посмотрит на объединенную разность, и от него, выяснит, сколько строк было добавлено, удалено или изменено. Это помогает мне знать, что ожидать в тестировании и QA, который следует за новой сборкой. В основном большие числа изменения означают, что мы должны наблюдать ту сборку ближе, проведите его посредством полного регрессионного тестирования и т.д.