Префикс класса.NET и постфиксные соглашения о присвоении имен [закрываются]

Наша команда ставит перед всеми классами префикс «C», все интерфейсы - с помощью I, а все структуры - с T. Что ужасно - по крайней мере, эти классы начинаются с «C». Поскольку исходные файлы имеют то же имя, что и класс. Тогда, когда исходные файлы перечислены в алфавитном порядке, трудно найти то, что вам нужно! Поскольку проекту уже несколько лет, переименование всех классов и исходных файлов невозможно, поэтому соглашение останется.

Мы используем три префикса: I , T и _ . Первый используется для интерфейсов, второй - для универсальных типов, а третий - для сторонников свойств. Я категорически не советую использовать любые другие префиксы. Кстати, это соответствует рекомендациям Microsoft. РЕДАКТИРОВАТЬ : Я имею в виду, что Microsoft рекомендует не использовать префиксы, отличные от I и T . См. Рекомендации по именам - имена классов, структур и интерфейсов . Я уже нарушаю, используя _ , но я чувствую необходимость различать частные поля и средства поддержки свойств, и мне нравится тот факт, что _ не является буквенно-цифровым. / EDIT

Список постфиксов практически бесконечен. Часто они основаны на имени базового класса / интерфейса, например IDispatcher -> EmailDispatcher .

Лично мне не очень нравятся постфиксы вроде Info , потому что они слишком общие, так как большинство классов в любом случае представляют какую-то информацию. Наконец, мне нравится использовать Service в качестве постфикса вместо Manager .

ИЗМЕНИТЬ Я также довольно часто использую постфикс Provider , например, в хорошо известном BCL-классе ApplicationRoleProvider .

Для имен классов я предпочитаю суффиксы префиксам; например для различных типов классов блоков у меня есть BlockBase, BlockText, BlockCollection, BlockSequence, BlockTable, BlockDocument и т. д. Я предпочитаю суффиксы, потому что это помогает сгруппировать их по алфавиту.

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

С другой стороны, я альтернативно использую внутренние пространства имен (то есть папки в проекте / сборке) для этого.

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

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

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

Что касается, в частности, соглашений об именах, некоторые методы просто вредны и контрпродуктивны. Например, в венгерской нотации основное внимание уделяется типам, тогда как современные разработчики обычно должны уделять больше внимания интерфейсу (интерфейсам), который предоставляет тип, и полиморфизму, чем самим конкретным типам. Я также не особо люблю соглашение о «менеджере», так как большинство высокоуровневых классов, использующих композицию, часто считается подходящим к этой категории, а затем суффикс становится совершенно излишним и используется слишком часто.

FXCop распознает префиксы s_ и m_ и будет жаловаться, если вы их перепутаете. Мне они нравятся больше, чем общий префикс _, который, похоже, предпочитают разработчики C#.

I всегда используется для интерфейсов, а T - для общих параметров. Этого никто не оспаривает.

Все остальное обрабатывается суффиксами типа Collection. Я не буду их перечислять, потому что они либо очевидны, либо специфичны для библиотек моей компании.

Я неоднозначно отношусь к элементам управления. Иногда я использую правильные паскалевские имена, а иногда - старые префиксы в стиле VB, такие как txt, cmd, lbl и т. д. В обоих случаях есть свои плюсы и минусы.

Вы забыли

• Модель для моделей MVC
• Представление для представлений MVC

Также мы используем Manager , вероятно, слишком часто, для классов, которые контролируют другие классы, например UserManager.