Используете ли вы время при именовании методов логического типа возврата?

Question

Итак, когда вы пишете логический метод, используете ли вы tense, например "has" или "was", в именовании метода возврата или вы используете только "is"?

это метод Java, который я недавно написал, очень просто ..

boolean recovered = false;

public boolean wasRecovered()
{
     return recovered;
}

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

Answer 1

Я предпочитаю использовать IsFoo(), независимо от времени, просто потому, что это хорошо понятное соглашение, которое все еще не понимают носители языка.Неродные носители английского языка регулярно рассматриваются в современной мировой индустрии разработки.

Answer 2

Я использую время, соответствующее значению значения. В противном случае по существу создается код, который читает один путь и ведет себя другим. Давайте посмотрим на реальный пример в .Net Framework: Thread.IsAlive

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

if (thread.IsAlive ) {
  // Code that depends on the thread being alive
  ...

Проблема здесь в том, что свойство не представляет текущее состояние объекта, оно представляет прошлое состояние. Как только значение будет вычислено как true, рассматриваемый поток может немедленно выйти и аннулировать значение. Следовательно, это значение можно безопасно использовать только для идентификации прошлого состояния потока, а свойство прошедшего времени является более подходящим. Теперь давайте вернемся к примеру, который выглядит немного иначе

if ( thread.WasAlive ) {
  // Code that depends on the thread being alive
  ...

Они ведут себя одинаково, но очень плохо читают, потому что на самом деле это плохой код.

Вот список некоторых других правонарушителей

• File.Exists
• Directory.Exists
• DriveInfo.IsReady
• WeakReference.IsAlive

Answer 3

Префикс isXxx является широко распространенным соглашением об именах, поэтому он обычно является лучшим выбором.

Для операций, чувствительных к порядку, подходит wasXxx,Например, в JDBC получение значения столбца базы данных может вернуть ноль, если поле фактически равно NULL (не установлено);в этом случае последующий вызов wasNull определяет, какое значение равно после фактического извлечения.

Для получения настроек атрибута, hasXxxможет быть более подходящим.Это предпочтение грамматики, так как в «флаге объекта установлено установлено» против «объекта имеет атрибут».

Затем существуют тесты возможностей canXxx.Например, вызов canWrite, чтобы увидеть, доступен ли файл для записи.Но такие имена, вероятно, можно переименовать в форму isXxx, например isWritable.

Answer 4

Это зависит от того, заботитесь ли вы о прошлом или будущем состоянии рассматриваемой недвижимости.

Чтобы попытаться упростить семантику, поймите, что есть несколько сценариев, которые делают дискуссионную форму IsXXX, и некоторые очень распространенные сценарии, где форма IsXXX является единственной полезной.

Ниже приведена таблица истинности для Thread.IsAlive (), основанная на возможных состояниях потока с течением времени. Забудьте о , почему поток может переворачивать состояния флопа, нам нужно сосредоточиться на используемом языке.

Сценарии возможных состояний потока во времени:

    Past        Present     Future  
    =====       =======     =======  
 1. alive       alive       alive  
 2. alive       alive       dead  
 3. alive       dead        dead  
 4. dead        dead        dead
 5. dead        dead        alive
 6. dead        alive       alive
 7. dead        alive       dead
 8. alive       dead        alive

Примечание: я говорю о состоянии Future ниже для согласованности. Знание того, умрет ли поток, очень вероятно неизвестно как подмножество Проблема остановки )

Когда мы запрашиваем объект, вызывая метод, существует общее предположение «Жив ли этот поток, в то время, когда я спросил ? Для этих случаев ответ в столбце« Настоящее время »- это все». мы заботимся о том, чтобы форма IsXXX работала нормально.

Сценарии # 1 (всегда живы) и # 4 (всегда мертвы) - самые простые и распространенные. Ответ на IsAlive() не изменится между вызовами. Битва за язык возникает из-за других 6 случаев, когда результат вызова IsAlive() зависит от , когда вызывается.

Сценарии # 2 (умрет) и # 3 (умер) переходы из живого в мертвого.
Сценарии # 5 (начнется) и # 6 (начался) перехода от мертвого к живому.

Для этих четырех (2, 3, 5, 6) ответ на IsAlive() не является постоянным. Возникает вопрос: меня волнует настоящее состояние, IsAlive(), или меня интересует состояние прошлого / будущего, WasAlive() и WillBeAlive()? Если вы не можете предсказать будущее, вызов WillBeAlive() становится бессмысленным для всех, кроме самых специфических проектов.

При работе с пулом потоков нам может потребоваться перезапустить потоки, находящиеся в «мертвом» состоянии, для обслуживания запросов на подключение, и не имеет значения, были ли они когда-либо живы, просто они в настоящее время мертвы. В этом случае мы можем использовать WasDead(). Конечно, мы должны попытаться гарантировать, что мы не перезапускаем поток, который был только что перезапущен, но это проблема проектирования, а не семантическая. Предполагая, что никто не может перезапустить поток, не имеет большого значения, используем ли мы IsAlive() == false или WasDead() == true.

Теперь о двух последних сценариях. Сценарий # 7 (был мертв, жив, будет мертв) практически такой же, как # 6 . Вы знаете когда в будущем он умрет? Через 10 секунд, 10 минут, 10 часов? Собираетесь ли вы подождать, прежде чем решить, что делать. Нет, вас волнует только текущее (настоящее) состояние. Мы говорим здесь об именах, а не о многопоточности.

Сценарий # 8 (был жив, мертв, будет жив), практически совпадает с # 3 . Если вы повторно используете потоки, то они могут циклически проходить через живые / мертвые состояния несколько раз. Беспокойство о разнице между # 3 и # 8 восходит к проблеме остановки и поэтому может быть проигнорировано.

IsAlive() должно работать для всех случаев. IsAlive() == false работает (для # 5 и # 6 ) вместо добавления WasAlive().

Answer 5

Я не уверен, что вы думаете об этом правильно.Причина, по которой можно использовать свойство Recovered, заключается в том, что это состояние, в котором находится объект , теперь , а не потому, что это было состояние, в котором объект использовался. Возможно, в прошлом был какой-то процесс(Восстановление), которое теперь завершено, но тот факт, что мы получаем доступ к этому свойству, теперь означает, что в этом завершенном процессе есть что-то, что изменило текущее состояние, и это текущее состояние важно.Для меня «Восстановленный» отражает природу этого состояния.Для этого примера (и большинства подобных ситуаций) я бы использовал IsRecovered, чтобы назвать предикат, который указывает на это условие.(Это также соответствует нормальному английскому: «Это восстановленный документ».)

Очень редко я могу использовать что-либо, кроме настоящего времени, для именования предиката (IsDirty, HasCoupon) или логического значенияфункция (IsPrime(x)) в программе.

Исключением может быть указание на состояние, которое с тех пор было изменено, которое, возможно, потребуется восстановить (DocumentWindow.WasMaximizedAtLastExit).

Я бы обычно использовал инфинитив для будущего времени (скорее, ToBeCopied)чем WillBeCopied), так как лучшие планы программного обеспечения иногда изменяются (или отменяются).

Answer 6

Я не против wasRecovered так много.Восстановление - это прошлое событие, которое могло или не могло произойти - оно говорит вам, произошло ли это или нет.Но если вы используете его из-за каких-то последствий восстановления, я бы предпочел isCached, isValid или какое-то другое описание того, что на самом деле означают эти последствия.То, что вы что-то восстановили, по сути не означает, что с тех пор вы его больше не потеряли.

Всегда помните, что в английском языке причастие прошлого в качестве прилагательного неоднозначно между переходными и непереходными глаголамии возможно между активным и пассивным голосом).isRecovered может означать, что объект был восстановлен чем-то другим, или это может означать, что объект восстановил .Если ваш объект представляет пациента в больнице, означает ли «isRecovered», что пациент в порядке и что кто-то забрал пациента из рентгеновского отделения?wasRecovered может быть поэтому лучше для последнего.

Answer 7

Я склонен, да.Например, при проверке ошибок:

$errors = false;
public function hasErrors()
{
  return $this->errors;
}

Answer 8

Поскольку ваш вопрос относится к Java, имя метода должно начинаться с «is», если ваш класс является JavaBean, а метод является методом доступа для свойства.

http://download.oracle.com/javase/tutorial/javabeans/properties/properties.html

Answer 9

Концепция именования методов заключается в том, что вы извлекаете информацию о рассматриваемом объекте.Чтобы он был назван в прошедшем времени, он должен был быть информацией о предыдущем состоянии объекта, а не о его текущем состоянии.для использования прошедшего времени, если я проверял кэшированный результат чего-то, что ранее произошло, но это больше не так.Для надуманного примера, возможно, получение предыдущего значения после чего-то вроде swap() вызова.Это может быть полезно в элементарных операциях.Впрочем, вряд ли в дикой природе.