Наименование методов bool: «против» против «против»?

Какое имя лучше для метода, который возвращает логическое значение?

IsSupportContentType

или же

CanSupportContentType

naming naming-standards

— медиатор
источник

Поскольку намерение состоит в том, чтобы имя четко передавало состояние или поведение, и вы никогда не сказали бы, что «этот класс поддерживает тип содержимого X», лучшее имя - CanSupportContentType. Вы бы сказали что-то вроде «этот класс может поддерживать тип содержимого X».

— Крейг

Не носитель языка, но не будет ли SupportContentType наиболее «грамматическим» вариантом?

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

Первый должен IsSupportedContentTypeбыть грамматически правильным. (если только «тип контента поддержки» не является существительным, что маловероятно)

— CodesInChaos

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

— Оливье Грегуар

@WeylandYutani IsCanHasSupportCheezburger?

— RM

Ответы:

106

Есть против Can

В соответствии с рекомендациями Microsoft по соглашению об именах , «Is» и «Can» в порядке (как и «Has») в качестве префикса для логического значения.

На простом английском языке «Is» будет использоваться для идентификации чего-либо о самом типе, а не о том, что он может делать. Например, IsFixed, IsDerivedFrom, IsNullableвсе это можно найти в типах CLR и методах. Во всех этих случаях «Is» сопровождается прилагательным .

В то же время, «может» более четко указывает на возможность, например 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 заставил меня задуматься, кто потратил время на то, чтобы программное обеспечение могло поддерживать банки (как в жестяных банках). Просто «Поддержка» - лучший вариант, без сомнения!

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

Иногда разработчики не могут сказать, когда что-то «звучит странно», например, если английский не является их родным языком.

— Джон Ву,

Иногда более короткая версия хуже. Например, в стандартной библиотеке C ++ у нас есть std::vector::empty(). Только из его названия, он очищает вектор? Или возвращается ли вектор пустым? На самом деле последнее, так как первое задание выполнено std::vector::clear(). Но вы должны в общем прочитать документы, чтобы быть уверенным. В качестве противоположного примера, Qt QVectorлегче понять в этом отношении, поскольку его метод проверки на пустоту таков QVector::isEmpty().

— Руслан

Стоит отметить, что также можно использовать префикс « следует ». Согласно руководству Apple , не только слова « можно » и « следует », модальные глаголы в целом можно использовать для именования функций, которые возвращают логическое значение. Я не вижу много случаев использования « воли », но « должен » хорош для хуков, запрашивающих советы, как видно в реагирующих:

shouldComponentUpdate: (newProps: any) => boolean

— Гарри
источник

Должно ли это IMHO довольно бедное именование, «хорошо, он должен закрыть документ, но я на самом деле я не совсем уверен»

— Lovis

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

— Грег

@greg Как это менее двусмысленно, чем WillCloseConnection?

— Базовый

@Lovis Мы обычно используем, is...но используем should...в некоторых именах аргументов функции места, где логическое значение указывает, на что функция должна что-то менять . Если функция может дополнительно закрыть документ, вызвав параметр , управляющий , который isClosedбудет точной (это не закрыто еще ) , и поэтому мы будем использовать , shouldCloseчтобы указать , что это то , что функция должна делать. (Произвольный пример; у нас вряд ли будет такая функция, особенно потому, что закрытие документа должно быть достаточно весомым, чтобы иметь выделенный вызов.)

— KRyan

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

— KRyan