% explícito do blocoelse
A primeira regra apenas polui o código e o torna nem mais legível nem menos propenso a erros. O objetivo do seu colega - suponho - é ser explícito, mostrando que o desenvolvedor estava totalmente ciente de que a condição pode ser avaliada como false
. Embora seja bom ser explícito, tal explicitação não deve ter o custo de três linhas extras de código .
Nem sequer mencionei o fato de que uma instrução if
não é necessariamente seguida por else
ou nada: ela pode ser seguida por um ou mais elif
s também.
A presença da declaração return
torna as coisas piores. Mesmo se você realmente tivesse código para executar dentro do bloco else
, seria mais legível fazê-lo assim:
if (something)
{
doStuff();
return whatever;
}
doOtherThings();
return somethingElse;
Isso faz com que o código use duas linhas a menos e desmembra o bloco else
. As cláusulas Guard são sobre isso.
Observe, no entanto, que a técnica do seu colega poderia resolver parcialmente um padrão muito desagradável de blocos condicionais empilhados sem espaços:
if (something)
{
}
if (other)
{
}
else
{
}
No código anterior, a falta de uma quebra sã de linha após o primeiro bloco if
torna muito fácil interpretar incorretamente o código. No entanto, embora a regra de seu colega dificulte a leitura errada do código, uma solução mais fácil seria simplesmente adicionar uma nova linha.
Teste para true
, não para false
A segunda regra pode fazer algum sentido, mas não em sua forma atual.
Não é falso que o teste de uma porta fechada seja mais intuitivo do que o teste para uma porta não aberta . Negações e especialmente negações aninhadas são geralmente difíceis de entender:
if (!this.IsMaster || (!this.Ready && !this.CanWrite))
Para resolver isso, em vez de adicionar blocos vazios, crie propriedades adicionais, quando relevante, ou variáveis locais .
A condição acima pode ser facilmente legível:
if (this.IsSlave || (this.Synchronizing && this.ReadOnly))