Как избежать неприятного запаха кода — руководство по NDepend

Цели обучения

• Избегайте общих запахов кода в C# с помощью NDepend

Предпосылки

• Сначала установите последнюю версию Visual Studio здесь.

* Загрузите NDepend Trail Edition здесь.

* Разархивируйте загрузку и установите расширение VS.

Официальная документация fили дополнительная информация

.Net Code Analysis — NDepend, часть 1

Начало работы

Разработчики .NET могут оценивать и визуализировать кодовую базу с помощью надежного инструмента статического анализа NDepend. Он помогает программистам понять качество и ремонтопригодность кода, выявить ошибки и другие возможные проблемы, а также отслеживать показатели кода.

Рефакторинг типов со слишком большим количеством методов

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

Пример кода

Предположим, что класс «Клиент» имеет следующие методы:

public class Customer
{
    public void AddOrder(Order order) { ... }
    public void RemoveOrder(Order order) { ... }
    public void UpdateOrder(Order order) { ... }
    public void GetOrders() { ... }
    public void GetCustomerDetails() { ... }
    public void GetCustomerHistory() { ... }
    // ... more than 20 methods
}

Ошибка зависимости

Рефакторинг решения

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

* Служба Заказа Клиента

* Служба сведений о клиентах

* Служба истории клиентов

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

public class CustomerOrderService
{
    public void AddOrder(Customer customer, Order order) { ... }
    public void RemoveOrder(Customer customer, Order order) { ... }
    public void UpdateOrder(Customer customer, Order order) { ... }
    public void GetOrders(Customer customer) { ... }
}

public class CustomerDetailsService
{
    public void GetCustomerDetails(Customer customer) { ... }
}

public class CustomerHistoryService
{
    public void GetCustomerHistory(Customer customer) { ... }
}

// Refactor remaining methods as well

Рефакторинг класса «Клиент» в эти три меньших класса улучшил удобство сопровождения кода и снизил риск появления ошибок в будущем.

Избегайте статических полей, не предназначенных только для чтения

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

Статические поля в C# используются для обмена данными между экземплярами класса. После инициализации он сохраняет значение на протяжении всего времени существования домена приложения.

Пример кода

public class MyClass
{
    public static int Count = 0;

    public void IncrementCount()
    {
        Count++;
    }
}

Если создается несколько экземпляров класса MyClass и все они могут редактировать поле Count, это может привести к непредвиденному поведению.

Ошибка зависимости

Рекомендуется по возможности указывать статические поля как доступные только для чтения, чтобы предотвратить эти проблемы. Когда статическое поле обозначено как доступное только для чтения, либо в объявлении, его значение может быть изменено только один раз. Это снижает вероятность возникновения незаметных проблем и упрощает анализ состояния программы.

Рефакторинг решения

public class MyClass
{
    public static readonly int Count = 0;

    static MyClass()
    {
        Count = 10;
    }
}

Не назначайте статические поля из методов экземпляра.

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

Пример кода

public class MyClass
{
    public static int Count = 0;

    public void IncrementCount()
    {
        Count++;
    }
}

Ошибка зависимости

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

Рефакторинг решения

public class MyClass
{
    public static int Count = 0;

    static MyClass()
    {
        IncrementStaticCount();
    }
    private static void IncrementStaticCount()
    {
        Count++;
    }
}

Наконец, я добавил частный статический метод с именем IncrementStaticCount в этот рефакторинговый код, который увеличивает значение статического поля Count. Метод IncrementCount теперь вызывает метод IncrementStaticCount как метод экземпляра.

Дополнительную информацию см. в обозревателе правил

Обозреватель правил NDepend

Спасибо за прочтение. Надеюсь, статья вам понравилась. Оставьте свой отзыв в разделе комментариев.