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

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

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

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

1. сделать.
2. сделать то же самое каждый раз.

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

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

существует также бесплатный CodeMetric добавить-в на отражатель

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

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

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

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

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

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

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

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

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

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

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

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

[edit] [кто-то с аналогичным мнением о коде размер]1

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

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

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

выдержка из статьи: Как вы подсчитываете количество строк кода (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 его сборок. Вот некоторые наблюдения:

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