Количество строк кода как оценить
Перейти к содержимому

Количество строк кода как оценить

  • автор:

Как узнать количество строк кода в проекте?

Дано: Проект, состоящий из множества файлов (например *.java и *.xml ). Задача: Подсчитать сколько строк кода во всех этих файлах. Исключая комменты и пустые строки. Вопрос: Пилить свой велосипед или я не первый кто этим интересуется?

Отслеживать
задан 26 янв 2016 в 19:32
69.8k 9 9 золотых знаков 67 67 серебряных знаков 124 124 бронзовых знака
А зачем это может понадобиться?
26 янв 2016 в 19:34

@PavelParshin, ну, например, для обоснования длительности внесения изменений в код. Или для хвастовства.

26 янв 2016 в 19:35

Ещё для оценки (очень приблизительной) прогресса в решении к-л (сферической) задачи (сферическим) кодером.

26 янв 2016 в 20:03
@PavelParshin, вот, на вики даже статья есть на тему зачем: Количество строк кода
27 янв 2016 в 11:45
Я вас понял, спасибо)
27 янв 2016 в 11:49

3 ответа 3

Сортировка: Сброс на вариант по умолчанию

Решение задачи, в общих чертах, должно выглядеть так:

  1. Собираем список всех файлов в проекте, пробежавшись по всем его папкам.
  2. Считываем файл и считаем в нём кол-во строк
  3. Регулярками (например) выкидываем из общего числа строк файла пустые строки и закомментированные строки (в зависимости от типа файла и ЯП, определяем как именно выглядит коммент)

И да, есть готовые решения. Например, вот на гитхабе: Count Lines of Code

Вкратце алгоритм такой (для масдая):

  1. Скачиваем *.exe .
  2. Запускаем его из командной строки
  3. Указываем папку с исходниками.
  4. Получаем результат подобного вида:

введите сюда описание изображения

P.S.

У Count Lines of Code есть множество ограничений. Например «/*» тут n строк кода «*/» будут восприняты как n строк комментов. Также подсчёт идёт не логических строк кода, а непустых строк, содержащих то, что программа определяет как код, а не комменты.

Обратите внимание на приведённый в README проекта список альтернативных решений.

Средство оценки качества кода в MS Visual Studio

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

Microsoft предоставляет встроенное в Visual Studio средство, которое позволяет оценить код вашего проекта.

Получить оценку вашего кода можно нажав правой кнопкой на проекте и выбрав пункт “Calculate Code Metrics” (Эта функциональность доступна в Visual Studio 2008 Team System и Visual Studio 2010 начиная с Premium версии).

Описание метрик

Результаты содержат 5 метрик для вашего кода.

    Maintainability Index – комплексный показатель качества кода. Этот показатель разработан специалистами из Carnegie Mellon Software Engineering Institute. Рассчитывается метрика по следующей формуле:

MI = MAX(0, (171 — 5.2 * ln(HV) — 0.23 * CC — 16.2 * ln(LoC)) * 100 / 171)

  • HV – Halstead Volume, вычислительная сложность. Чем больше операторов, тем больше значение этой метрики;
  • CC – Cyclomatic Complexity. Эта метрика описана ниже;
  • LoC – количество строк кода.
Реальное использование

Когда я первый раз запустил анализ на одном из проектов, все значения Maintainability Index были зеленые. Это казалось несколько странным, т.к. там явно был код, который надо было бы переписать. Значения MI для таких участков кода были около 30-40. Получается, что показатели по умолчанию являются, скорее всего, субъективными, и решение о том, какой код считать некачественным, придется принимать самим программистам.

Для своих проектов я стараюсь для большинства методов поддерживать показатель MI около 70-90. Бывают методы, у которых этот показатель равен 50-60, и их можно переписать, но стоит оценивать затраты и выгоды.

Благодаря этому инструменту можно достаточно легко провести code review большого проекта, найти места, которые необходимо переписать. Также достаточно полезно следить за процессом изменения вышеописанных метрик. Это может показать руководителю об отношении программистов к разработке того или иного проекта, а также динамику изменения качества кода по каждому программисту, что немаловажно в нашей профессии. Другой причиной слежения за метриками, являются, определенные программистами, пороговые значения, при достижении которых, необходимо заняться рефакторингом.

Значения метрик кода

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

Разработчики могут использовать Visual Studio для создания данных метрик кода, которые измеряют сложность и удобство обслуживания управляемого кода. Данные метрик кода можно создать для всего решения или одного проекта.

Сведения о создании данных метрик кода в Visual Studio см. в статье «Практическое руководство. Создание данных метрик кода».

Измерения программного обеспечения

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

  • Индекс доступности — вычисляет значение индекса от 0 до 100, представляющее относительную простоту поддержания кода. Высокое значение означает лучшую поддержку. Цветные закодированные оценки можно использовать для быстрого выявления проблемных мест в коде. Зеленый рейтинг составляет от 20 до 100 и указывает, что код имеет хорошую поддержку. Желтый рейтинг составляет от 10 до 19 и указывает, что код является умеренным. Красный рейтинг — это рейтинг от 0 до 9 и указывает на низкую поддержку. Дополнительные сведения см. в разделе «Диапазон индексов поддержки» и «Значение».
  • Цикломатическая сложность — измеряет структурную сложность кода. Он создается путем вычисления количества различных путей кода в потоке программы. Программа, которая имеет сложный поток управления, требует больше тестов для достижения хорошего покрытия кода и менее поддерживается. Дополнительные сведения см. в разделе «Цикломатическая сложность».
  • Глубина наследования — указывает количество различных классов, наследуемых друг от друга, вплоть до базового класса. Глубина наследования аналогична связыванию классов, что изменение базового класса может повлиять на любой из унаследованных классов. Чем выше это число, тем глубже наследование и чем выше потенциал для изменений базового класса, что приведет к критическому изменению. Для глубины наследования низкая ценность хороша, и большое значение плохо. Дополнительные сведения см. в разделе «Глубина наследования».
  • Объединение классов — измеряет связь с уникальными классами с помощью параметров, локальных переменных, возвращаемых типов, вызовов методов, универсальных или шаблонных экземпляров, базовых классов, реализаций интерфейса, полей, определенных во внешних типах и оформлении атрибутов. Хороший дизайн программного обеспечения диктует, что типы и методы должны иметь высокую сплоченность и низкую связь. Высокая связь означает дизайн, который трудно использовать и поддерживать из-за его многочисленных взаимозависимостей по другим типам. Дополнительные сведения см. в разделе «Связь классов».
  • Строки исходного кода — указывает точное количество строк исходного кода , присутствующих в исходном файле, включая пустые строки. Эта метрика доступна начиная с Visual Studio 2019 версии 16.4 и Microsoft.CodeAnalysis.Metrics (2.9.5).
  • Строки исполняемого кода — указывает приблизительное количество строк или операций исполняемого кода . Это количество операций в исполняемом коде. Эта метрика доступна начиная с Visual Studio 2019 версии 16.4 и Microsoft.CodeAnalysis.Metrics (2.9.5). Значение обычно близко соответствует предыдущей метрике, строкам кода, которая является метрикой на основе инструкций MSIL, используемой в устаревшем режиме.

Анонимные методы

Анонимный метод — это просто метод , который не имеет имени. Анонимные методы чаще всего используются для передачи блока кода в качестве параметра делегата. Результаты метрик кода для анонимного метода, объявленного в элементе, например методе или методе доступа, связаны с элементом, объявляющим метод. Они не связаны с членом, который вызывает метод.

Созданный код

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

Код, созданный для Windows Forms, не игнорируется, так как это код, который разработчик может видеть и изменять.

Связанный контент

  • Практическое руководство. Создание данных метрик кода
  • Использование окна результатов метрик кода

Количественная оценка понятности кода

image

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

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

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

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

Вот несколько примеров навскидку, которые помогут понять суть этой метрики:
Пример 1: вы встречаете в коде переменную с ни о чем не говорящим названием (например, j). Вы найдете определение этой переменной (совершите переход), и, если повезет, там окажется комментарий, поясняющий, что она означает. Если не повезет, и комментария не окажется, то вам придется искать все места, где она используется (совершать переходы) и пытаться понять ее назначение. А если даже комментарий к переменной и был, то вы, вероятно, скоро забудете его, и придется снова к нему возвращаться (совершать переход).

Пример 2: в коде вы встретили вызов функции с ни о чем не говорящим названием. Более того, не понятно, какой результат может выдавать функция. Вам придется совершать переход к реализации этой функции, несколько раз перемотать ее вниз и вверх, чтобы понять, что она делает, и какой результат возвращает. А если функция окажется длиной строк в 200-300, то листать придется много.

Пример 3: в анализируемой функции присутствует множественная вложенность: условия в циклы, циклы в условия. Держать в памяти это очень сложно, и вы будете периодически пролистывать код вверх, чтобы удерживать весь контекст в памяти.

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

Пример 5 (не из реальной работы, гипотетический): Если мы слишком сильно увлечемся рефакторингом, каждое элементарное действие выделим в функцию/класс, то навигация по ним также может превысить все разумные пределы. Понятность кода также упадет, так как нужно будет очень много держать в памяти.

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

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

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

Реализовано это может быть в виде плагина для IDE.

  • рефакторинг
  • code review
  • Совершенный код
  • Проектирование и рефакторинг

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *