Які анти-шаблони іменування існують? [зачинено]

Є деякі імена, де, якщо ви виявите, що дотягуєтесь до цих імен, ви знаєте, що вже щось зіпсували.

Наприклад:

XxxManager
Це погано, оскільки клас повинен описувати, що робить клас. Якщо найбільш конкретне слово, яке ви можете придумати для того, що робить клас, - це "керувати", то клас занадто великий.

Які ще анти-шаблони іменування існують?

Для уточнення я не запитую "які імена погані" - це питання цілком суб'єктивне, і немає можливості відповісти на нього. Я запитую, "які назви вказують на загальні проблеми дизайну в системі". Тобто, якщо ви хочете викликати компонент Xyz, це, ймовірно, вказує на те, що компонент погано сприймається. Також зауважте, що з кожного правила є винятки - я просто шукаю попереджувальні прапори, коли мені справді потрібно зупинитись і переосмислити дизайн.

Наступні імена анти-шаблонів пов'язані з .NET і, особливо, C #:

• Невідповідності . Якщо ви вирішили почати кожне ім'я поля з головного підкреслення, дотримуйтесь його .
• Абревіатури Ambiguos з відсутніми голосними . Я серйозно бачив такі назви полів, як cxtCtrlMngr. Ви навряд чи здогадуєтесь, на що це повинно стояти.
• Занадто довгі і багатослівні назви змінних . ILoginAttemptRepositoryдобре і описово - ILoginAttemptRepositoryUsingEntityFrameworkForObjectRelationalMappingє описовим, але, безумовно, непоганим.

Я часто стикаюся з тим, що взагалі не використовую жодного шаблону імен. Як правило, це вказує на незнання розробника (що іменування моделей - це добре ), а також цей антидіапазон має тенденцію до грубого порушення SRP шляхом введення в цей клас самих різних способів, які пов'язані з класом, таким чином, наприклад, клієнт клас має властивості, методи CRUD, все, що віддалено пов’язане із замовником, якого потребує частина програми.

Додам також, що використовувати "Engine" як суфікс - це приблизно те саме, що використовувати "Manager". Це дуже розпливчасто, і клас, який називається, XxxEngineмає тенденцію до того, що становить модуль у стилі VB, що містить безліч методів, тому він знаходиться в одному "простому у використанні" місці, без будь-якого знання та ідеї об'єктно-орієнтованого програмування.

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

Префіксація "Я" до імені інтерфейсу, або "Анотація" до імені абстрактного класу. Це може бути виправданим у мовах, які не мають поняття абстрактних класів або не розрізняють інтерфейси та абстрактні класи - але, наприклад, у Java це завжди погана ідея.

Крім того, я не згоден з вами у справі менеджера. Я використовую цей шаблон іноді, і це просто означає, що якби я спробував назвати його чимось іншим, то ім'я не було б більш описовим, ніж XxxxxManager. Є деякі завдання (не обов'язково складні), які просто неможливо чітко узагальнити одним або двома словами.

Speeling:

У мене схильна інвалідність і не можу писати. За допомогою перевірки орфографії я безсилий, я намагаюся скопіювати всі імена, які я створюю, в текстовий процесор для перевірки, але я завжди пропускаю їх. У своєму останньому проекті я написав значну частину api, і, мабуть, я не перевірив правопис, коли я вперше застосував слово відповідь, і я припустив, що це правильно, тому що ніхто мені не сказав. У нас було щонайменше 50 функцій з відповіддю на неї. Нова команда прийшла в команду і запитала, чому ми використовуємо реакцію, я відчував себе справді німим.

Ну боюся, мої думки трохи суперечливі. Але давайте спробуємо ...

Що стосується мене, я маю згоду з Майком Баранчаком, такі імена, як XxxController, XxxHandler - це те, що ми справді часто використовуємо. Для нас Контролер - це щось на кшталт вхідної точки для чогось "інкапсольованого", наприклад управління транзакціями, боротьба з несподіваними помилками, виклик XxxHandler для виконання фактичної роботи. Я б сказав, що XxxManager - синонім контролера. Я думаю, що важливо не використовувати Менеджер в одному випадку, а Контролер в іншому. Бути послідовним дуже важливо, якщо ти працюєш у команді.

Було б дуже важко або, можливо, навіть неможливо знайти кращі назви таких предметів. Xxx слід правильно вибрати, щоб зробити ситуацію більш зрозумілою.

Мені особисто не подобається, коли метод, який називається get ... or set ..., є більш ніж простим аксесуаром. Мені подобається det ... для визначення.

Інша річ, що спадає мені на думку: за словами дядька Боба. Значення "І" у назві методу є ознакою того, що потрібно робити багато. Але життя не завжди є просто чорно-білим - бувають ситуації, коли я думаю, що це нормально - наприклад. через проблеми з ефективністю (коли у вас уже є дані, щоб перевірити, чому їх не обробити) ...

Я особисто також великий фанат системних угорських позначень - більшу частину часу ви маєте справу з вихідним кодом в 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;
  ...
}

Тут ми маємо шість полів замість двох примірників класу Адреса.

Цей антидіапазон позначений низкою імен з двох частин, у яких перераховано кожну комбінацію двох наборів, наприклад [foo, bar] x [1,2,3] або [home, perm] x [вулиця, місто, штат]

Будь-яке іменування класу чи інтерфейсу, яке є тавтологією, є поганим, не тільки на Java, про яке йдеться в посиланні, але й будь-якою мовою.

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

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

Від корпорації Майкрософт щодо іменування я можу надати цей список для невірних імен:

1. Вони не семантичні, це означає, що вони мають імена, які замість того, щоб робити акцент на тому, що він робить, роблять акцент на технології, яку він використовує, або на основі структури .
2. Вони не дотримуються синтаксичної послідовності. Наприклад, частина імен розміщена на верблюдах, а інша частина - у паскалі.
3. Вони є абревіатурами, які важко зрозуміти, як ScrollableX замість CanScrollHorizontally
4. Вони вибрані такими, що вони возиться з ключовими словами того середовища.