Логический метод чтения имен



простой вопрос, с точки зрения читаемости, какое имя метода вы предпочитаете для логического метода:

public boolean isUserExist(...)

или:

public boolean doesUserExist(...)

или:

public boolean userExists(...)
153   11  

11 ответов:

public boolean userExists(...)

было бы моим предпочтением. Поскольку это делает ваши условные проверки гораздо более похожими на естественный английский:

if userExists ...

но я думаю, что нет жестких правил - просто будьте последовательны

Я бы сказал userExists, потому что 90% времени мой код вызова будет выглядеть так:

if userExists(...) {
  ...
}

и читается буквально на английском языке.

if isUserExist и if doesUserExist кажется излишним.

целью для удобства чтения всегда должно быть написание кода, максимально приближенного к естественному языку. Так что в данном случае userExists кажется, лучший выбор. Использование префикса "is", тем не менее, может быть правильным в других ситуациях, например isProcessingComplete.

остерегайтесь ущерба ясность во время погони читабельности.

хотя if (user.ExistsInDatabase(db)) читает лучше, чем if (user.CheckExistsInDatabase(db)), рассмотрим случай класса с шаблоном builder (или любого класса, который вы можете установить состояние):

user.WithName("Mike").ExistsInDatabase(db).ExistsInDatabase(db2).Build();

это не ясно, если ExistsInDatabase проверяет, существует ли он, или устанавливает тот факт, что он существует. Ты бы не стал писать if (user.Age()) или if (user.Name()) без какого-либо значения для сравнения, так почему if (user.Exists()) хорошая идея чисто потому, что это свойство/функция имеет логический тип, и вы можете переименовать функцию/свойство, чтобы читать больше как естественный английский? Неужели так плохо следовать тому же шаблону, который мы используем для других типов, отличных от булевых?

С другими типами, является if оператор сравнивает возвращаемое значение функции со значением в коде, поэтому код выглядит примерно так:

if (user.GetAge() >= 18) ...

который читается как "если пользователь точка получить возраст больше или равен 18..." истинный - это не "естественный английский", но я бы сказал, что object.verb никогда не напоминал естественный английский, и это просто основной аспект современного программирования (для многих основных языков). У программистов обычно нет проблем с пониманием приведенного выше утверждения, так что следующее хуже?

if (user.CheckExists() == true)

который обычно сокращается до

if (user.CheckExists())

последовал роковой шаг

if (user.Exists())

пока было сказано, что "код читается в 10 раз чаще чем написано", это также очень важно, что ошибки легко обнаружить. Предположим, что у вас есть функция с именем Exists (), которая заставляет объект существовать и возвращает true/false на основе успеха. Вы можете легко увидеть код if (user.Exists()) и не заметить ошибку - ошибка будет гораздо более очевидным, если считанный код if (user.SetExists()) например.

дополнительно, пользователя.Exists () может легко содержать сложный или неэффективный код, круглое отключение к базе данных, чтобы проверить что-то. пользователь.CheckExists() дает понять, что функция что-то делает.

Смотрите также все ответы здесь: Соглашения об именах: как назвать метод, который возвращает логическое значение?

в качестве заключительной заметки-после "Tell Don't Ask" многие функции, возвращающие true/false, все равно исчезают, и вместо того, чтобы спрашивать объект о его состоянии, вы говорите ему что-то делать, что он может делать по-разному в зависимости от его состояния.

Я бы пошел с userExists (), потому что 1) это имеет смысл на естественном языке, и 2) он следует соглашениям API, которые я видел.

чтобы увидеть, если это имеет смысл на естественном языке, прочитайте его вслух. "Если пользователь существует" звучит больше как действует английская фраза, чем "если пользователя не существует" или "если пользователь не существует". "Если пользователь существует "было бы лучше, но" the", вероятно, излишне в имени метода.

существует ли файл в Java SE 6 В вы использовать файл.существует(). Похоже, это будет то же самое в версии 7. C# использует тот же, а не Python и Рубин. Надеюсь, это достаточно разнообразная коллекция, чтобы назвать это языком-агностическим ответом. Вообще, я бы встал на сторону методов именования в соответствии с API вашего языка.

есть вещи, чтобы рассмотреть, что я думаю, были пропущены несколько других ответов здесь

  1. Это зависит, если это метод класса C++ или C функцию. Если это метод, то он, скорее всего, будет называться if (user.exists()) { ... } или if (user.isExisting()) { ... }
    не if (user_exists(&user)) . Это является причиной стандартов кодирования, что методы state bool должны начинаться с глагола, так как они будут читать как предложение, когда объект находится перед ними.

  2. к сожалению много старые функции C возвращают 0 для успеха и ненулевые для неудачи, поэтому может быть трудно определить используемый стиль, Если вы не будете следовать всем функциям bool, начинающимся с глаголов или всегда сравниваемым с true, как so if (true == user_exists(&user))

мое простое правило на этот вопрос таково:

Если логический метод уже имеет глагол, не добавляйте его. В противном случае, подумайте об этом. Некоторые примеры:

$user->exists()
$user->loggedIn()
$user->isGuest() // "is" added

Мне нравится любой из этих:

userExists(...)
isUserNameTaken(...)
User.exists(...)
User.lookup(...) != null

чисто субъективное.

предпочитаю userExists(...) потому что тогда такие заявления лучше читать:

if ( userExists( ... ) )

или

while ( userExists( ... ) )

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

Я бы, вероятно, пошел на номер три из-за того, как это звучит при чтении его в утверждениях if. "Если пользователь существует" звучит лучше, чем "если пользователь существует".

Это предполагает, что он будет использоваться в тестах операторов if, конечно...

имена методов служат для удобочитаемости, только те, которые вписываются в ваш весь код, будут лучшими, которые в большинстве случаев начинаются с условий, поэтому subjectPredicate следует естественной структуре предложения.

    Ничего не найдено.

Добавить ответ:
Отменить.