Cuidado para não sacrificar a clareza enquanto busca a legibilidade .
Embora seja if (user.ExistsInDatabase(db))
mais agradável do que ler if (user.CheckExistsInDatabase(db))
, considere o caso de uma classe com um padrão de construtor (ou qualquer classe na qual você possa definir o estado):
user.WithName("Mike").ExistsInDatabase(db).ExistsInDatabase(db2).Build();
Não está claro se ExistsInDatabase
está verificando se existe ou definindo o fato de que existe. Você não escreveria if (user.Age())
ou if (user.Name())
sem qualquer valor de comparação, então por queif (user.Exists())
uma boa ideia simplesmente porque essa propriedade / função é do tipo booleano e você pode renomear a função / propriedade para ficar mais parecido com o inglês natural? É tão ruim seguir o mesmo padrão que usamos para outros tipos que não sejam booleanos?
Com outros tipos, uma if
instrução compara o valor de retorno de uma função a um valor no código, de forma que o código se pareça com:
if (user.GetAge() >= 18) ...
Que se lê como "se o usuário dot get age é maior ou igual a 18 ..." true - não é "inglês natural", mas eu diria que object.verb
nunca se assemelhou ao inglês natural e esta é simplesmente uma faceta básica da programação moderna (para muitas línguas convencionais). Os programadores geralmente não têm problemas para entender a declaração acima, então o que segue é pior?
if (user.CheckExists() == true)
Que normalmente é abreviado para
if (user.CheckExists())
Seguido pela etapa fatal
if (user.Exists())
Embora tenha sido dito que "o código é lido 10 vezes mais frequentemente do que escrito", também é muito importante que os erros sejam fáceis de detectar. Suponha que você tenha uma função chamada Exists () que faz com que o objeto exista e retorna verdadeiro / falso com base no sucesso. Você poderia facilmente ver o código if (user.Exists())
e não localizar o bug - o bug seria muito mais óbvio se o código lesseif (user.SetExists())
por exemplo.
Além disso, user.Exists () poderia facilmente conter código complexo ou ineficiente, retornando a um banco de dados para verificar algo. user.CheckExists () deixa claro que a função faz algo.
Veja também todas as respostas aqui: Convenções de nomenclatura: como nomear um método que retorna um booleano?
Como nota final - seguindo "Diga, não pergunte", muitas das funções que retornam verdadeiro / falso desaparecem de qualquer maneira, e em vez de perguntar a um objeto por seu estado, você diz a ele para fazer algo, o que ele pode fazer de diferentes formas com base em seu estado.
isBabbyFormed