Чи є хороші методи або тести для називання типів?

Незручне, відкрите запитання, але це проблема, на яку я завжди натикаюся:

Програмне забезпечення, яке легко обслуговувати та працювати з ним, - це добре розроблене програмне забезпечення. Намагатися зробити дизайн інтуїтивно зрозумілим, це називає ваші компоненти таким чином, щоб наступний розробник мав змогу зробити висновок про функцію компонента. Ось чому ми не називаємо наші класи "Тип1", "Тип2" тощо.

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

Це стає гіршим (для мене) при спробі назви сімей типів із базовим типом або інтерфейсом, який описує, що повинні робити компоненти, але не те, як вони працюють. Це , природно , призводить до кожного похідному типу намагається описати аромат реалізації (наприклад , IDataConnectionі SqlConnectionв .NET Framework), але як ви висловлюєте що - то складне , як «твір відображення і шукають певний набір атрибутів»?

Потім, коли ви, нарешті, вибрали назву типу, який, на вашу думку, описує, що він намагається зробити, ваш колега запитує "WTF чи DomainSecurityMetadataProviderсправді це робиться? "

Чи є якісь хороші прийоми вибору доречного імені для компонента чи як створити сімейство компонентів, не отримуючи заплутаних імен?

Чи є якісь прості тести, які я можу застосувати до імені, щоб краще відчути, чи є ім'я "хорошим", і чи має бути інтуїтивнішим для інших?

Для називання є шість методів, для яких було доведено, що вони працюють для мене:

1. витратити багато часу на вигадування імен
2. використовувати огляди коду
3. не соромтесь перейменувати
4. витратити багато часу на вигадування імен
5. використовувати огляди коду
6. не соромтесь перейменувати

PS. Якщо ваш API стане загальнодоступним, перед цим застосовується вище - адже, знаєте,

"Публічні API, як алмази, є назавжди. У вас є один шанс виправити це так, давайте все можливе ..." (Джошуа Блох, Як створити хороший API і чому це має значення )

Мій базовий тест - якщо ви можете описати функцію змінної, використовуючи лише слова зі змінної:

наприклад, якщо DomainSecurityMetadataProvider або "надає метадані безпеки домену" або "надає метадані, що стосуються безпеки домену", це добре.

Однак є нюанси, які різняться від людини до людини:

Наприклад, для мене original_team_code - код для початкової команди, тоді як для когось іншого це може бути оригінальний код для команди. Моїм улюбленим одним із них був "UnsafeLegacyMutex", який я не міг не прочитати як "Це Legacy Mutex, який є небезпечним", а не "Це Mutex для ThreadUnsafe Legacy Code".

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

Чи є якісь хороші прийоми вибору доречного імені для компонента чи як створити сімейство компонентів, не отримуючи заплутаних імен?

Не зовсім.

Однак одна порада - уникати "пасивного голосу".

"DomainSecurityMetadataProvider" є пасивним. Немає дієслова, всі іменники та іменники використовуються як прикметники.

"ProvideMetadataForDomainSecurity" є більш активним. Там дієслово.

Об'єктно-орієнтоване програмування - це все (дійсно) іменник-дієслово. Іменник == об’єкт. Дієслово == метод. Тож назва класу, як правило, дуже "іменник". Порушити цю звичку і почати вставляти дієслова, складно.

Чи є якісь прості тести, які я можу застосувати до імені, щоб краще відчути, чи є ім'я "хорошим", і чи має бути інтуїтивнішим для інших?

Так. Ви визначили відмінний тест у своєму питанні. Запитайте інших людей.

За старих часів ми називали це "покроковим дизайном". Це була велика потужна угода у методології водоспаду. У наш час, з методами Agile, це повинна бути звичайна співпраця між автором та користувачами класу. Це не потребує (і не повинно) забирати багато часу. Обговорення дизайну (та назви) перед написанням тестів (та коду) зменшить коефіцієнт здивування та може запобігти ВТФ.

Використання тезауруса

Дуже часто я посилаюсь на тезаурус, коли роблю нову розробку, щоб знайти відповідні слова для опису своїх занять та методів.

Класи, які в першу чергу містять логіку роботи

Я схильний називати класи, які в основному забезпечують методи роботи в структурі іменника-дієслова, такі як "EntityProvider", "EntityLocator" тощо.

Ці класи, як правило, не містять багато штату.

Класи, що містять стан

Екрани користувальницького інтерфейсу та сукупності даних, як правило, є статними, і тому я просто називаю ці класи за допомогою іменника або прикметника-іменника.

Приклади: особа, працівник, поточний працівник, колишній працівник

Корисні класи

Класи, які містять лише статичні методи, як правило, вважаються класами "корисні", тому я послідовно називаю їх суфіксом "Утиліта".

Приклади: NetworkUtilities, FileUtilities

Тести

У мене немає хороших тестів для вирішення питання про те, що щось названо погано, але я б запропонував спробувати використовувати в імені один іменник та / або один дієслово, а потім подумайте, чи точно цей іменник / дієслово описує те, що ви ' перейменування.

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

Алан Грін та Джефф Еттвуд писали про зло назви класів з суфіксом "Менеджер". Вони стверджують, що термін "Менеджер" надмірно використовується і є надто розпливчастим, щоб передати щось значиме. Я повинен погодитися.

Стаття Джеффа також містить перелік запропонованих вказівок із Кодексу Стіва МакКоннелла.

змінні

Нещодавно я експериментував із більш довгими описовими назвами змінних / параметрів, які містять прийменники, такі як "Of", "By", "For" тощо. Деякі приклади наведено нижче:

string firstNameOfEmployee;

string lastNameOfEmployee;

// here I nimbly avoid worrying about whether to call it "Id" or "ID" :)
int idOfEmployee;

decimal amountForDeposit;

Account accountForDeposit;

Я вважаю, що це добре працює з функцією інтелігенції Visual Studio, що полегшує набір цих довгих імен. Я також вважаю, що є менше дублювання префіксів імен змінних (наприклад, personID, personFirstName, personLastName проти idOfPerson, firstNameOfPerson, lastNameOfPerson), що забезпечує кращий "хеш", що робить intellisense ще більш корисним.

Потім, коли ви нарешті вибрали назву типу, який, на вашу думку, описує те, що він намагається зробити, ваш колега запитує: "Чи справді цей DomainSecurityMetadataProvider робить?"

Яку назву ви очікуєте для складного класу та домену? Це приблизно так само добре, як це вийде, не склавши вирок свого класу (який подумає всіх, хто вважає, що ви занадто багато відповідальності перед одним класом)

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

Використовуйте метафори для опису частин системи. Це не тільки змусить вас відкрити нові аналогії, але допоможе назвати простіше.

(Я знаю, що це не вагомий приклад, але все одно) Наприклад, ви можете викликати змінну або тип як mailbox, який служить чергою для отриманих повідомлень для класу.

Одне, що я дуже твердий, - це те, що Імена НІКОЛИ не повинні дозволяти бути неправильними. Найкращий приклад, під час деякого рефакторингу багато коду змінилося, і кілька змінних почали посилатися на щось інше, ніж те, що пропонували їх назви.

Досить скоро один програміст витрачав віки і використовував дуже дорогі дзвінки до бази даних, намагаючись обзавестися певними фрагментами даних, які вже були вилучені та збережені. Я все перейменував, і раптом ми змогли усунути тону занадто складної та помилкової логіки.

Сподіваємось, випадки, коли вам доведеться так важко подумати над іменами, рідкісні. Коли виникають ці випадки, просто напишіть абзац з поясненням того, що робить клас. На відміну від коментарів, що функціонують, або коментарів на рівні функцій, основне призначення класу рідко змінюється, тому ризик застарілих коментарів відносно невеликий. Тож у вас є розкіш написати пару абзаців або навіть намалювати ASCII, щоб пояснити, що робить клас.