Какие существуют анти-паттерны именования? [закрыто]

Есть некоторые имена, где, если вы обнаружите, что пытаетесь найти эти имена, вы знаете, что уже что-то напутали.

Например:

XxxManager
Это плохо, потому что класс должен описывать, что класс делает. Если самое конкретное слово, которое вы можете придумать для того, что делает класс, это «управлять», то класс слишком велик.

Какие еще существуют анти-паттерны именования?

Чтобы уточнить, я не спрашиваю «какие имена плохие» - этот вопрос является полностью субъективным, и нет никакого способа ответить на него. Я спрашиваю: «Какие имена указывают на общие проблемы проектирования системы». То есть, если вы хотите вызвать компонент Xyz, это, вероятно, указывает на то, что компонент неверен. Также обратите внимание, что здесь есть исключения из каждого правила - я просто ищу предупреждающие флаги, когда мне действительно нужно остановиться и переосмыслить дизайн.

Следующие анти-шаблоны именования относятся к .NET и, особенно, к C #:

• Несоответствия . Если вы решили начать каждое имя поля с начального подчеркивания, придерживайтесь его .
• Двусмысленные сокращения с пропущенными гласными . Я серьезно видел названия полей, такие как cxtCtrlMngr. Вы вряд ли можете догадаться, что это означает.
• Слишком длинные и подробные имена переменных . ILoginAttemptRepositoryхорошо и описательно - ILoginAttemptRepositoryUsingEntityFrameworkForObjectRelationalMappingописательно, но определенно не хорошо.

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

Я также добавлю, что использование «Engine» в качестве суффикса примерно то же, что и «Manager». Это очень расплывчато, и класс с именем XxxEngineимеет тенденцию быть тем, что представляет собой модуль в стиле VB, содержащий множество методов, поэтому он находится в одном «простом в использовании» месте, без каких-либо знаний или идеи объектно-ориентированного программирования.

Ну, сначала простые ответы: наберите венгерский ( http://mindprod.com/jgloss/unmainnaming.html , также есть несколько отличных идей. Более сбалансированный взгляд на то, когда венгер не злой, http://www.joelonsoftware.com /articles/Wrong.html )

Префикс «I» к имени интерфейса или «Абстрактный» к имени абстрактного класса. Это может быть оправдано в языках, которые не имеют понятия абстрактных классов или не различают интерфейсы и абстрактные классы - но в Java, например, это всегда плохая идея.

Кроме того, я не согласен с вами по поводу менеджера. Я иногда использую этот шаблон, и это просто означает, что если бы я попытался назвать его как-то иначе, то имя не было бы более наглядным, чем XxxxxManager. Есть некоторые задачи (не обязательно сложные), которые просто не могут быть кратко изложены в одном или двух словах.

Speeling:

У меня отклоняющаяся склонность и я не могу записать. Без проверки орфографии я бессильна, я пытаюсь скопировать все имена, которые я создаю, в текстовый процессор для проверки, но я всегда скучаю по некоторым. В моем последнем проекте я написал большую часть API, и я полагаю, что я не проверял орфографию в первый раз, когда использовал слово «ответ», и предположил, что это правильно, потому что никто не сказал мне. У нас было как минимум 50 функций с откликом в нем. В команду пришел новый человек и спросил, почему мы используем реакцию, я чувствовал себя очень глупо.

Боюсь, мои мнения немного противоречивы. Но давайте попробуем ...

Что касается меня, я должен согласиться с Майком Баранчаком, такие имена, как XxxController, XxxHandler - это то, что мы действительно часто используем. Для нас контроллер - это что-то вроде точки входа для чего-то «инкапсулированного», например, для управления транзакциями, обработки неожиданных ошибок, вызова XxxHandler для выполнения реальной работы. Я бы сказал, что XxxManager - это синоним контроллера. Я думаю, что важно не использовать Manager в одном случае и Controller в другом. Быть последовательным очень важно, если вы работаете в команде.

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

Что мне лично не нравится, так это то, что метод get ... или set ... - это больше, чем просто метод доступа. Мне нравится дет ... для определения.

Еще одна вещь, которая приходит мне в голову: по словам дяди Боба. «И» в имени метода является признаком того, что нужно много делать. Но жизнь не всегда только черно-белая - есть ситуации, когда я думаю, что это нормально - например. из-за проблем с производительностью (когда у вас уже есть данные из-за проверки, почему бы не обработать их) ...

Лично я также большой поклонник системной венгерской нотации - в большинстве случаев вы имеете дело с исходным кодом в IDE. Но часто вы используете только редактор или просматриваете репозиторий в браузере. Одним из недостатков может быть поддержка инструментов из-за префиксов типов ...

Я думаю, что самая важная вещь - быть созвучным - субоптимальное соглашение - для меня - лучше, чем отсутствие соглашения ...

Возможно, худший анти-шаблон именования это:

create table stuff(..., foo1 string, bar1 string,
                        foo2 string, bar2 string, 
                        foo3 string, bar3 string, ...)

У нас есть трехэлементный список пар [foo, bar]. Если нам нужен четвертый, нам нужно будет добавить новые столбцы в таблицу.

Ведущий к коду, как это:

'SELECT foo' + i + ', bar' + i + ' FROM stuff'

Отдельная таблица должна быть создана с колонками foo и bar и связана с таблицей материала:

create table fubar(foo string, bar string, stuff_id long)

Второе худшее это:

class Student {
  ...
  String homeStreet;
  String homeCity;
  String homeState;
  String permStreet;
  String permCity;    
  String permState;
  ...
}

Здесь у нас есть шесть полей вместо двух экземпляров класса Address.

Этот анти-шаблон помечен серией имен из двух частей, в которой перечислены все комбинации двух наборов, например [foo, bar] x [1,2,3] или [home, perm] x [улица, город, штат]

Любое имя класса или интерфейса, являющееся тавтологией, является плохим не только в Java, о котором говорится в ссылке, но и на любом языке.

Тавтология (риторика), используя разные слова, чтобы сказать то же самое, даже если повторение не дает ясности.

Я часто сталкиваюсь с библиотеками программного обеспечения с общими именами, такими как Libraryили Common. Они указывают на неоптимальный дизайн: разработчики прилагают усилия, чтобы избежать дублирования кода, но без какой-либо попытки создать дизайн, разложенный на основе функциональности.

От Microsoft по именованию я могу предоставить этот список для плохих имен:

1. Они не являются семантическими, что означает, что у них есть имена, которые вместо того, чтобы акцентировать внимание на том, что они делают, делают акцент на технологии, которую они используют, или шаблон, на котором они основаны .
2. Они не следуют синтаксической последовательности. Например, часть имен имеет верблюжий корпус, а другая часть - паскаль.
3. Это аббревиатуры, которые трудно понять, например ScrollableX вместо CanScrollHorizontally
4. Они выбраны так, что они связываются с ключевыми словами этой среды.