Назви методів bool: Is vs. Can vs.?

Яка краща назва методу, який повертає булевий?

IsSupportContentType

або

CanSupportContentType

naming naming-standards

— Посередник
джерело

Оскільки наміром є те, щоб ім'я чітко передавало стан або поведінку, і ви ніколи не скажете "цей клас підтримує вміст типу X", краще ім'я - CanSupportContentType. Ви б сказали щось на кшталт "цей клас може підтримувати вміст типу X."

— Крейг

Нерідний , але не буде чи бути SupportContentType найбільш «граматичний» варіанту?

— Роман Райнер

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

— CodesInChaos

А як просто supportsContentType? Нижче повністю читається: if (abc.supportsContentType("text/html")). "може підтримувати" означає, що існують додаткові умови для підтримки типу вмісту.

— Олів'є Грегоар

@WeylandYutani IsCanHasSupportCheezburger?

— РМ

Відповіді:

106

Є проти Кан

Відповідно до рекомендацій конвенції Microsoft щодо іменування , і "Є", і "Може" є нормальними (і так само "має") як префікс булевого типу.

Простий англійською мовою "Є" буде використовуватися для ідентифікації чогось самого типу, а не того, що він може робити. Наприклад, IsFixed, IsDerivedFrom, IsNullableвсе це можна знайти в CLR типів і методів. У всіх цих випадках "Є" супроводжується прикметником .

У той же час, «може» більш чітко вказує на можливість, наприклад CanEdit, CanRead, CanSeek. У кожному з цих випадків може супроводжуватися дієсловом .

Оскільки "Підтримка" - це дієслово, я думаю, що у вашому випадку CanSupportContentTypeкраще.

Коротша альтернатива

З іншого боку, конвенції кажуть, що префікс необов'язковий. Більше того, такий тип аргументу в назві методу доцільний, оскільки розробник може бачити тип аргументу в intellisense. Отже, ви можете просто назвати свій метод Supportsі визначити його так:

public bool Supports(System.Net.Mime.ContentType contentType)

... що коротше і все одно чітко повідомляє про мету. Ви б назвали це так:

ContentType contentType = new ContentType("text/plain");
var someClass = new MediatorsClass();
bool ok = someClass.Supports(contentType);

Або як компроміс, можливо, це найкраще:

public bool CanSupport(System.Net.Mime.ContentType contentType)

— Джон Ву
джерело

Приємно, коли він добре читає:if ( someClass.Supports(contentType) )

— candied_orange

… АбоhasSupportedContentType

— Бергі

Метод під назвою "CanSupports" inallallty викликає здивування, хто витратив час на те, щоб програмне забезпечення могло підтримувати банки (як у бляшаних банках). Просто "Підтримка" - кращий варіант, без сумніву!

— Т. Сар - Відновіть Моніку

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

— Джон Ву

Іноді коротша версія гірша. Напр. У стандартній бібліотеці С ++ std::vector::empty(). Тільки від своєї назви він спорожнює вектор? Або повертається, чи вектор порожній? Власне останнє, оскільки перше завдання виконує std::vector::clear(). Але вам потрібно взагалі прочитати документи, щоб бути впевненим. Як зворотний приклад, Qt QVectorлегше зрозуміти в цьому плані, оскільки його метод перевірки на порожнечу є QVector::isEmpty().

— Руслан

Варто зазначити, що префікс " слід " також можна використовувати. Згідно з настановою Apple , не тільки " може " і " повинен ", модальні дієслова взагалі можуть використовуватися для іменування функцій, які повертають булеві. Я не можу побачити багато вживання " волі ", але " слід ", це добре для гачок, що запитують поради, як це видно в reactjs:

shouldComponentUpdate: (newProps: any) => boolean

— Гаррі
джерело

Потрібно це дуже погано називати, "ну, документ слід закрити, але я насправді не зовсім впевнений"

— Ловіс

@lovis: Я вважаю, що коментар Гаррі дуже вірний. Наприклад, я міг би делегувати деякі дії, пов’язані з базою даних, через плагін, кожен плагін має метод "ShouldCloseConnection", який інформує рамки про те, що слід проводити деяке очищення. Просто приклад, але "слід", безумовно, є коректним префіксом.

— greg

@greg Як це менш неоднозначно, ніж WillCloseConnection?

— Основні

@Lovis Ми зазвичай використовуємо, is...але використовуємо should...в деяких назвах аргументів функції місця, де булеве вказує на те, що функція повинна змінити речі . Якщо функція може додатково закрити документ, назвавши керуючий параметр , який isClosedбуде точним (це не закрита ще ) , і тому ми будемо використовувати , shouldCloseщоб вказати , що це те , що функція повинна робити. (Довільний приклад; ми, швидше за все, не матимемо такої функції, тим більше, що закриття документа має бути досить вагомим, щоб мати спеціальний дзвінок.)

— KRyan

@Basic Принаймні в нашому випадку will...зарезервовано для асинхронних функцій, які повертають обіцянку; якщо функція, описана в моєму попередньому коментарі, є синхронною, використання will...буде невідповідним нашому іменуванню.

— KRyan