Правило Анализа кода Visual Studio - “Не выставляет универсальные списки”

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

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

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

• List часто является плохим выбором для входных параметров, поскольку он заставляет вызывающих абонентов копировать данные без необходимости. Я видел много кода, объявляющего параметры как List или T [] , когда IEnumerable было бы достаточно.

• List также может быть плохим выбором для свойств. Рассмотрим следующие альтернативы:

   Курс открытого класса {
  общедоступный список <Курс> Предпосылки {получить; }
  }
  public class Course {
  общедоступная коллекция <Курс> Предпосылки {получить; }
  }
  

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

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

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