Должен ли подсчет LOC включать тесты и комментарии?

Question

Хотя LOC (# строк кода) является проблематичным измерением сложности кода, он является наиболее популярным и при очень осторожном использовании может дать приблизительную оценку, по крайней мере, относительной сложности основ кода (т. Е. Если один Программа - 10KLOC, а другая - 100KLOC, написанная на одном языке командами с примерно одинаковой компетенцией, вторая программа почти наверняка намного сложнее).

При подсчете строк кода вы предпочитаете считать комментарии? А как насчет тестов?

Я видел разные подходы к этому. Такие инструменты, как cloc и sloccount, позволяют включать или исключать комментарии. Другие люди считают комментарии частью кода и его сложностью.

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

Я видел подходы по всему спектру, от подсчета только «эксплуатационных» незаполненных строк без комментариев до «XXX строк проверенного, закомментированного кода», что больше похоже на выполнение «wc -l для всего кода» файлы в проекте ".

Какое ваше личное предпочтение и почему?

Answer 1

Один мудрец однажды сказал мне: «Вы получаете то, что измеряете», когда речь идет об управлении программистами.

Если вы удивительно оцениваете их в выводе LOC, вы, как правило, получаете много строк кода.

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

Если вы оцените их по добавленным функциям, вы получите множество функций.

Если вы оцениваете их по цикломатической сложности, вы получаете смехотворно простые функции.

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

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

Но если вы действительно хотите измерить «размер кода», просто tar.gz базу кода. Он служит более точной приблизительной оценкой «содержания», чем подсчет строк, который подвержен различным стилям программирования.

Answer 2

Тесты и комментарии также должны быть сохранены. Если вы собираетесь использовать LOC в качестве метрики (и я просто предполагаю, что не могу отговорить вас от этого), вы должны указать все три (строки реального кода, комментарии, тесты).

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

Lines of Code:       75,000
Lines of Comments:   10,000
Lines of Tests:      15,000
                  ---------
Total:              100,000

Таким образом, вы можете быть уверены, что это будет

1. Готово.
2. Делай так же каждый раз.

Answer 3

Лично я не считаю, что сама по себе метрика LOC столь же полезна, как некоторые другие метрики кода.

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

Существует также бесплатная CodeMetric надстройка для Отражатель

Answer 4

Строки кода означает, что: комментарии или пустые строки не учитываются. И для того, чтобы он был сопоставим с другим исходным кодом (независимо от того, полезна ли метрика сама по себе или нет), вам нужны как минимум схожие стили кодирования:

for (int i = 0; i < list.count; i++)
{
    // do some stuff
}

for (int i = 0; i < list.count; i++){
    // do some stuff
}

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

Answer 5

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

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

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

Есть много инструментов, которые измеряют этот вид сложности. Быстрый поиск в Google по вашему любимому языку найдет десятки инструментов, которые делают такого рода сложности.

Answer 6

Выдержка из статьи: Как вы подсчитываете количество строк кода (LOC)? относительно инструмента NDepend, который подсчитывает логические номера строк кода . NET программы.

---

Как вы рассчитываете количество строк кода (LOC)?

Считаете ли вы объявление подписи метода? Считаете ли вы строки только в скобках? Считаете ли вы несколько строк, когда один вызов метода записывается в несколько строк из-за большого количества параметров? Считаете ли вы декларации «пространства имен» и «используя пространство имен»? Вы считаете интерфейс и объявление абстрактных методов? Считаете ли вы присвоение полей, когда они объявлены? Вы считаете пустую строку?

В зависимости от стиля кодирования каждого разработчика и в зависимости от выбранного языка (C #, VB.NET…) может быть существенная разница при измерении LOC.

Видимо, измерение LOC при разборе исходных файлов выглядит как сложная тема. Благодаря проницательности существует простой способ точно измерить то, что называется логическим LOC. Логический LOC имеет 2 существенных преимущества перед физическим LOC (LOC, который выводится из анализа исходных файлов):

• Стиль кодирования не мешает логическому LOC. Например, LOC не изменится, потому что вызов метода порождается в несколько строк из-за большого количества аргументов.
• Логический LOC не зависит от языка. Значения, полученные из сборок, написанных на разных языках, сравнимы и могут быть суммированы.

В мире .NET логический LOC может быть вычислен из файлов PDB, файлов, которые используются отладчиком для связи кода IL с исходным кодом. Инструмент NDepend вычисляет логический LOC для метода следующим образом: он равен числу точек последовательности, найденных для метода в файле PDB. Точка последовательности используется для обозначения места в коде IL, которое соответствует определенному местоположению в исходном источнике. Подробнее о точках последовательности здесь. Обратите внимание, что точки последовательности, которые соответствуют скобкам C # ‘{‘ и ‘} ', не учитываются.

Очевидно, что LOC для типа - это сумма его методов 'LOC, LOC для пространства имен - это сумма его типов', LOC для сборки - это сумма LOC его пространств имен 'и LOC для заявка - это сумма его сборок LOC. Вот некоторые наблюдения:

• Интерфейсы, абстрактные методы и перечисления имеют LOC, равный 0. При вычислении LOC учитывается только конкретный код, который эффективно выполняется.
• Пространства имен, типы, поля и объявления методов не считаются строкой кода, поскольку они не имеют соответствующих точек последовательности.
• Когда компилятор C # или VB.NET сталкивается с инициализацией встроенных полей экземпляра, он генерирует точку последовательности для каждого конструктора экземпляра (то же самое замечание применяется для инициализации встроенных статических полей и статического конструктора).
• LOC, вычисленный по анонимному методу, не мешает LOC его внешних методов объявления.
• Общее соотношение между NbILInstructions и LOC (в C # и VB.NET) обычно составляет около 7.

Answer 7

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

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

Наконец, отказ от ответственности - используйте метрики разумно. Хорошее использование метрик состоит в том, чтобы помочь ответить на вопрос «какая часть кода выиграет больше всего от рефакторинга» или «насколько срочно проверка кода для последней проверки?» - функция из 1000 строк с цикломатической сложностью 50 - мигающая неоновая вывеска с надписью «рефакторинг меня сейчас». Неправильное использование метрик - «насколько продуктивен программист X» или «Насколько сложно мое программное обеспечение» .

Answer 8

Зависит от того, для чего вы используете LOC.

Как мера сложности - не так уж и много. Возможно, 100KLOC - это в основном код, сгенерированный из простой таблицы, и 10KLOC kas 5KLOC regexps.

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

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

[редактировать] [кто-то с похожим мнением о размере кода] 1