Неловкий, открытый вопрос, но я всегда сталкиваюсь с этой проблемой:
Программное обеспечение, которое легко поддерживать и работать, хорошо спроектировано. Попытка сделать дизайн интуитивно понятным означает присвоение имен вашим компонентам таким образом, чтобы следующий разработчик мог определить функцию компонента. Вот почему мы не называем наши классы "Type1", "Type2" и т. Д.
Когда вы моделируете концепцию реального мира (например, клиента), это обычно так же просто, как назвать свой тип после моделирования концепции реального мира. Но когда вы создаете абстрактные вещи, которые более системно ориентированы, очень легко исчерпать имена, которые легко читаются и легко усваиваются.
Это ухудшается (для меня), когда я пытаюсь назвать семейства типов, с базовым типом или интерфейсом, который описывает, что должны делать компоненты, а не как они работают. Это естественным образом приводит к тому, что каждый производный тип пытается описать вкус реализации (например, IDataConnection
и SqlConnection
в .NET Framework), но как вы выражаете что-то сложное, например, «работает по рефлексии и ищет определенный набор атрибутов»?
Затем, когда вы наконец выбрали название для типа, который, по вашему мнению, описывает то, что он пытается сделать, ваш коллега спрашивает: «WTF это DomainSecurityMetadataProvider
действительно делает? »
Есть ли хорошие методы для выбора правильного имени для компонента или как создать семейство компонентов, не получая запутанных имен?
Существуют ли какие-либо простые тесты, которые я могу применить к имени, чтобы лучше понять, является ли оно «хорошим» и должно ли оно быть более интуитивным для других?
Ответы:
Для именования было доказано, что у меня есть шесть методов :
PS. В случае, если ваш API будет общедоступным, выше применяется до этого - потому что, вы знаете,
источник
Мой базовый тест, если вы можете описать функцию переменной, используя только слова из переменной:
Однако есть нюансы, которые варьируются от человека к человеку:
Поэтому мой расширенный тест - записать переменную в доску / вики / чат, и пусть люди угадают, что это значит.
источник
На самом деле, нет.
Один совет, однако, состоит в том, чтобы избежать «пассивного голоса».
«DomainSecurityMetadataProvider» является пассивным. Там нет глагола, это все существительные и существительные, используемые в качестве прилагательных.
«ProvideMetadataForDomainSecurity» активнее. Там есть глагол.
Объектно-ориентированное программирование - это все (действительно) существительное-глагол. Существительное == объект. Глагол == метод. Так что имя класса, как правило, очень «существительное». Отказаться от этой привычки и начать вставлять глаголы сложно.
Да. Вы определили отличный тест в своем вопросе. Спроси других людей.
В старину мы называли это «прохождением дизайна». Это была большая, потная сделка в методологии водопада. В настоящее время, с Agile методами, это должно быть обычное сотрудничество между автором и пользователями класса. Это не (и не должно) занять много времени. Обсуждение дизайна (и названий) перед написанием тестов (и кода) уменьшит фактор удивления и может предотвратить WTF.
источник
ProvideMetadataForDomainSecurity
это плохим именем типа. Имена методов обычно гораздо проще назвать именно потому, что я могу свободно использовать глаголы. Ограничение языка - суть проблемы.Использование тезауруса
Очень часто я буду ссылаться на тезаурус при выполнении новых разработок, чтобы найти подходящие слова для описания моих классов и методов.
Классы, которые в основном содержат логику работы
Я склонен называть классы, которые в первую очередь предоставляют методы операций в структуре существительных-глаголов, таких как «EntityProvider», «EntityLocator» и т. Д.
Эти классы обычно не содержат много состояний.
Классы, которые содержат состояние
Экраны пользовательского интерфейса и объекты данных, как правило, с состоянием, и поэтому я просто называю эти классы шаблоном существительное или прилагательное-существительное.
Примеры: Person, Employee, CurrentEmployee, FormerEmployee
Утилиты
Классы, которые содержат только статические методы, обычно рассматриваются как «служебные» классы, поэтому я последовательно называю их суффиксом «Utility».
Примеры: NetworkUtilities, FileUtilities
тесты
У меня нет хороших тестов для определения того, имеет ли что-то плохое имя, но я бы посоветовал попытаться использовать в имени единственное существительное и / или один глагол, а затем подумать, точно ли это существительное / глагол описывает то, что вы переименование.
Если вы чувствуете, что в классе / методе есть еще что-то, что не охвачено именем, то этот класс / метод может нуждаться в рефакторинге.
Алан Грин и Джефф Этвуд написали о пороках именования классов с суффиксом «Менеджер». Они утверждают, что термин «менеджер» чрезмерно употребляется и слишком расплывчат, чтобы передать что-либо значимое. Я должен согласиться.
В статье Джеффа также содержится список рекомендуемых руководящих принципов из «Полного кода» Стива Макконнела.
переменные
Недавно я экспериментировал с более длинными описательными именами переменных / параметров, которые включают предлоги, такие как «Of», «By», «For» и т. Д. Некоторые примеры показаны ниже:
Я считаю, что это прекрасно работает с функцией intellisense в Visual Studio, облегчающей ввод этих длинных имен. Я также обнаружил, что существует меньшее дублирование префиксов имен переменных (например, personID, personFirstName, personLastName против idOfPerson, firstNameOfPerson, lastNameOfPerson), обеспечивая лучший «хэш», который делает intellisense еще более полезным.
источник
List
массивомIEnumerable
илиConcurrentQueue
. Это куча идентификаторов, которые мне нужно перечислить, и детали реализации того, как они хранятся, являются ненужным умственным багажом. Хотя я в целом согласен с тем, что если более длинное имя значительно более наглядно, оно должно быть предпочтительнее более короткого и менее понятного имени.Какое имя вы ожидаете для сложного и предметно-ориентированного класса? Это почти так же хорошо, как и то, что можно сделать, не называя имя вашего класса предложением (что заставит всех думать, что вы дали слишком большую ответственность одному классу)
Я хотел бы рассмотреть возможность отказа от имени провайдера. Если в нем конкретно упоминаются метаданные, все уже знают, что вы используете рефлексию. Вы можете сделать это одно слово более кратким (или, возможно, изменить его на другое слово - это скорее потребитель, чем провайдер из того, что вы написали)
источник
ISecurityMetadataProvider
интерфейс, в котором существует точка инъекции в инфраструктуре безопасности, для предоставления информации подсистеме. Называть сложно.DomainSecurityMetadataProvider
провайдеромDomainSecurityMetadata
объекта, гдеDomainSecurityMetadata
находятся сами метаданные. Четкое и понятное имя. Мне даже не нужно знать, что этоDomainSecurityMetadata
такое! Это просто какой-то объект, который предоставляет этот провайдер. Простое удалениеProvider
суффикса не улучшает читабельность, а наоборот - уменьшает его. Без этого суффикса я бы подумал, что это просто метаданные (объект-контейнер для некоторых метаданных), но не объект для получения метаданных (поставщик).Используйте метафоры для описания частей системы. Это не только поможет вам обнаружить новые аналогии, но и поможет наименованию.
(Я знаю, что это не сильный пример, но в любом случае) Например, вы можете вызвать переменную или тип as
mailbox
, который служит в качестве очереди для полученных сообщений для класса.источник
Одна вещь, на которой я был бы очень тверд, состоит в том, что Имена никогда не должны быть неправильными. Лучший пример, во время некоторого перефакторинга, много кода изменилось, и несколько переменных стали ссылаться на что-то другое, чем то, что предлагали их имена.
Довольно скоро один программист потратил целую вечность и использовал несколько очень дорогих обращений к базе данных, пытаясь получить определенные части данных, которые были извлечены и уже сохранены. Я переименовал все, и внезапно мы смогли удалить тонну излишне сложной и ошибочной логики.
источник
Надеемся, что случаи, когда вы должны так серьезно задуматься об именах, редки. Когда такие случаи возникают, просто напишите параграф, объясняющий, что делает класс. В отличие от функциональных комментариев или комментариев на функциональном уровне, основная цель класса редко изменяется, поэтому риск устаревания комментариев относительно невелик. Таким образом, вы можете написать пару параграфов или нарисовать ASCII, чтобы объяснить, что делает класс.
источник