Как оценить код программы

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

Ранее в материале «Этапы разработки программы – как создаются и проектируются программы?» мы рассмотрели общие этапы создания качественных и крупных программ. Сейчас мы поговорим, на самом деле, об одном из самых главных аспектов создания качественного ПО, а именно об управлении сложностью внутренней реализации программы, а точнее о сложности кода, т.е. насколько сложный код Вы пишите.

Зачем измерять сложность кода программы?

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

Как новичку оценить свой код

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

Отсюда и возникает этот очевидный вопрос — как измерить сложность кода, который мы написали в процессе программирования, чтобы узнать, сложный он или нет?

Способы измерения сложности исходного кода программы

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

Суть в следующем, Вы считаете, сколько в отдельно взятом методе или процедуре «Точек принятия решения», и если итоговое количество превышает рамки допустимого предела, то код подлежит переконструированию.

К «Точкам принятия решения» относятся следующие операторы:

• if
• while
• repeat
• for
• and
• or
• Каждый вариант CASE в SWITCH или в SELECT CASE.

Так вот, ориентируйтесь на следующие диапазоны значений количества точек принятия решения:

• До 5 – все хорошо;
• От 5 до 10 – можно начать думать о способах упрощения кода;
• Больше 10 – необходимо вынести часть кода в отдельные функции, процедуры и методы.

Отсюда следует, что если Ваш метод или процедура содержит, например:

Как начинающему программисту оценить свой код?

• 10 – if;
• 5 – while;
• 3 – and;
• 2 – or.

Итого 10 + 5 + 3 + 2 = 20, значит, этот метод или процедуру необходимо переделать, создать для определенных участков кода отдельные функции, процедуры и методы, а в текущем коде просто вызывать их.

Тем самым, Вы уменьшаете сложность кода, с которым Вы имеете дело в каждый момент времени.

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

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

Таким образом, чтобы измерить сложность кода, можно также подсчитать и количество уровней вложенности if и while, и, если условные конструкции или циклы содержат более 3 уровней вложенности, значит, эти конструкции сложные, и их необходимо переконструировать.

Если Вас интересуют вопросы управления сложностью, правильного конструирования ПО с использованием объектно-ориентированного языка программирования (C++, Java, Visual Basic), то я Вам рекомендую почитать книгу Стива Макконела «Совершенный код», но сразу скажу, что она для программистов, которые уже имеют базовые знания программирования, иными словами, она не для новичков, и она не учит Вас тому или иному языку.

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

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

Источник: info-comp.ru

Code metrics values

Applies to: Visual Studio Visual Studio for Mac Visual Studio Code

The increased complexity of modern software applications also increases the difficulty of making the code reliable and maintainable. Code metrics is a set of software measures that provide developers better insight into the code they are developing. By taking advantage of code metrics, developers can understand which types and/or methods should be reworked or more thoroughly tested. Development teams can identify potential risks, understand the current state of a project, and track progress during software development.

Developers can use Visual Studio to generate code metrics data that measure the complexity and maintainability of their managed code. Code metrics data can be generated for an entire solution or a single project.

For information about how to generate code metrics data in Visual Studio, see How to: Generate code metrics data.

Software measurements

The following list shows the code metrics results that Visual Studio calculates:

• Maintainability Index — Calculates an index value between 0 and 100 that represents the relative ease of maintaining the code. A high value means better maintainability. Color coded ratings can be used to quickly identify trouble spots in your code. A green rating is between 20 and 100 and indicates that the code has good maintainability. A yellow rating is between 10 and 19 and indicates that the code is moderately maintainable. A red rating is a rating between 0 and 9 and indicates low maintainability. For more information, see Maintainability index range and meaning.
• Cyclomatic Complexity — Measures the structural complexity of the code. It is created by calculating the number of different code paths in the flow of the program. A program that has complex control flow requires more tests to achieve good code coverage and is less maintainable. For more information, see Cyclomatic complexity.
• Depth of Inheritance — Indicates the number of different classes that inherit from one another, all the way back to the base class. Depth of Inheritance is similar to class coupling in that a change in a base class can affect any of its inherited classes. The higher this number, the deeper the inheritance and the higher the potential for base class modifications to result in a breaking change. For Depth of Inheritance, a low value is good and a high value is bad. For more information, see Depth of inheritance.
• Class Coupling — Measures the coupling to unique classes through parameters, local variables, return types, method calls, generic or template instantiations, base classes, interface implementations, fields defined on external types, and attribute decoration. Good software design dictates that types and methods should have high cohesion and low coupling. High coupling indicates a design that is difficult to reuse and maintain because of its many interdependencies on other types. For more information, see Class coupling.
• Lines of Source code — Indicates the exact number of source code lines that are present in your source file, including blank lines. This metric is available starting in Visual Studio 2019 version 16.4 and Microsoft.CodeAnalysis.Metrics (2.9.5).
• Lines of Executable code — Indicates the approximate number of executable code lines or operations. This is a count of number of operations in executable code. This metric is available starting in Visual Studio 2019 version 16.4 and Microsoft.CodeAnalysis.Metrics (2.9.5). The value is typically a close match to the previous metric, Lines of Code, which is the MSIL-instruction-based metric used in legacy mode.

Anonymous methods

An anonymous method is just a method that has no name. Anonymous methods are most frequently used to pass a code block as a delegate parameter. Code metrics results for an anonymous method that’s declared in a member, such as a method or accessor, are associated with the member that declares the method. They are not associated with the member that calls the method.

Generated code

Some software tools and compilers generate code that is added to a project and that the project developer either does not see or should not change. Mostly, Code Metrics ignores generated code when it calculates the metrics values. This enables the metrics values to reflect what the developer can see and change.

Code generated for Windows Forms is not ignored, because it is code that the developer can see and change.

Next steps

• How to: Generate code metrics data
• Use the Code Metrics Results window

Источник: learn.microsoft.com

Что такое качество кода и зачем его измерять

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

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

• соответствие правилам;
• сложность кода;
• дубликаты;
• комментирование;
• покрытие тестами.

Сейчас рассмотрим каждую из них.

Соответствие правилам

• синтаксические правила — одни из наиболее бесполезных правил (но только первый взгляд), поскольку совсем никоим образом не виляют на исполнение программы. К ним можно отнести стиль именования переменных (camelCase, через подчеркивание), констант (uppercase), методов, стиль написания фигурных скобок и нужны ли они если в блоке только одна строка кода. Этот список можно продолжить. Когда программист пишет код, он его легко читает, потому что он знает свой собственный стиль. Но стоит ему дать код где используется венгерская нотация и скобки с новой строки, ему придется тратить дополнительное внимание на восприятие нового стиля. Особенно веселит ситуация когда несколько совсем разных стилей используются в одном проекте или даже модуле.
• правила поддержки кода — правила, которые должны сигнализировать что код слишком сложный и его будет трудно сопровождать. К примеру, индекс сложности (подробнее о нем ниже) метода или класса слишком большой или слишком много строк кода в методе, наличие дубликатов в коде или “magic numders”. Думаю суть ясна, все они указывают нам на узкие места которые сложно будет сопровождать. Но нельзя забывать что именно мы можем решить какой индекс сложности для нас большой, а какой приемлемый.
• очистка и оптимизация кода — самые простые правила в том смысле, что редко кто-то будет утверждать что выражения очень нужны, даже когда они нигде не используются. Сюда можно отнести лишние импорты, переменные и методы которые уже не используются, но по какой-то причине их оставили в наследство.

Цикломатическая сложность кода

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

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

Дубликаты

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

Комментирование

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

Покрытие тестами

• покрытие файлов — здесь нужно определить как понять что файл покрыт тестами: зачастую файл покрыт если тест попал в файл и исполнил хотя бы одну строку кода из файла. Поэтому такая метрика используется крайне редко, но она все же имеет право на существование.
• покрытие классов — аналогично с покрытием файлов, только покрытие классов :). Также редко используется.
• покрытие методов — тот же способ исчисления метрики. Правда покрытие методов может найти более широкое распространение: если у вас на проекте существует правило покрывать каждый метод хотя бы одним тестом, тогда с помощью этой метрики можно быстро найти код не соответствующий правилам.
• покрытие строк — одна из наиболее используемых метрик по покрытию. Тот же способ исчисления, только за об’эк берется строка.
• покрытие ветвлений — то же, соответственно за элемент берется ветвление. Добиться хорошего показателя по этой метрики стоит наибольших усилий. По этой метрике можно судить насколько совестно программист подошел к покрытию тестами.
• суммарное покрытие — метрика покрытия при которой в расчетах принимается во внимание не один элемент а несколько. Наиболее часто используют суммарное покрытие строк и ветвлений.

Вместо заключения

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

Источник: habr.com