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

Question

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

Когда пользователь нажимает на вашу кнопку, вы хотите сделать 2 вещи. Вы хотите показать несколько изображений, или вы хотите позвонить finish().

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

Я создал флаг с именем firstClick, который по умолчанию установлен на true. Когда пользователь нажимает вашу кнопку (button1 в этом примере), мы проверяем это и показываем изображения. Затем мы устанавливаем его на false, поэтому следующий щелчок вызовет finish().

private ImageView equipament1;
private ImageView equipament2;

// The current state of the Activity
private boolean firstClick = true;

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_analise)                        
    equipament1 = findViewById(R.id.equipamento1);
    equipament2 = findViewById(R.id.equipamento2);


    // Setting your OnClickListener
    Button button = (Button) findViewById(R.id.button1);
    button.setOnClickListener(new OnClickListener() {

        public void onClick(View v) {
            if( firstClick ) {
                firstClick = false;
                sentImg();
            } else {
                finish();
            }
        }
    });
}

public void sentImg() {
    equipament1.setImageResource(R.drawable.reactor);
    equipament2.setImageResource(R.drawable.reactor);
}

14

metrics code-metrics

задан Mitch Wheat 9 November 2008 в 09:54

8 ответов

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

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

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

Этот способ, которым можно быть уверены, что он будет

, сделан.
сделаны тем же путем каждый раз.

9

ответ дан 1 December 2019 в 08:44

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

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

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

2

ответ дан 1 December 2019 в 08:44

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

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

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

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

1

ответ дан 1 December 2019 в 08:44

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

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

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

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

[редактирование] [кто-то с подобным мнением о размере кода] 1

0

ответ дан 1 December 2019 в 08:44

Строки кода средства точно, что: Никакие комментарии или пустые строки не считаются. И для него, чтобы быть сопоставимыми с другим исходным кодом (неважно, если метрика в 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 меньше. Когда у Вас есть много вложенных циклов, это может подвести итог вполне немного. Который является, почему метрики как единицы функциональности были изобретены.

1

ответ дан 1 December 2019 в 08:44

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

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

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

0

ответ дан 1 December 2019 в 08:44

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

0

ответ дан 1 December 2019 в 08:44

Другие вопросы по тегам:

metrics code-metrics

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

8 ответов

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

Похожие вопросы: