Isso é algo que estou fazendo muito ultimamente.
Exemplo:
setCircle(circle, i, { current }) {
if (i == current) {
circle.src = 'images/25CE.svg'
circle.alt = 'Now picking'
} else if (i < current) {
circle.src = 'images/25C9.svg'
circle.alt = 'Pick failed'
} else if (i > current) {
circle.src = 'images/25CB.svg'
circle.alt = 'Pick chance'
}
}Muitas vezes, a escada if / else é significativamente mais complicada do que isso ...
Veja a cláusula final? É redundante. A escada deve pegar todas as condições possíveis. Assim, poderia ser reescrito assim:
setCircle(circle, i, { current }) {
if (i == current) {
circle.src = 'images/25CE.svg'
circle.alt = 'Now picking'
} else if (i < current) {
circle.src = 'images/25C9.svg'
circle.alt = 'Pick failed'
} else {
circle.src = 'images/25CB.svg'
circle.alt = 'Pick chance'
}
}Era assim que eu escrevia código, mas não gosto desse estilo. Minha reclamação é que a condição sob a qual a última parte do código será executada não é óbvia a partir do código. Assim, comecei a escrever essa condição explicitamente para torná-la mais evidente.
Contudo:
- Escrever explicitamente a condição exaustiva final é minha, e eu tenho más experiências com minhas próprias idéias - geralmente as pessoas gritam comigo sobre o quão horrível o que estou fazendo é - e (às vezes muito) depois, eu descobri que era realmente subótimo;
- Uma dica de por que isso pode ser uma péssima idéia: não aplicável ao Javascript, mas em outros idiomas, os compiladores tendem a emitir avisos ou mesmo erros sobre o controle que atinge o fim da função. Sugerir que algo assim pode não ser muito popular ou estou fazendo errado.
- As reclamações do compilador me fizeram às vezes escrever a condição final em um comentário, mas acho que isso é horrível, pois os comentários, ao contrário do código, não têm efeito na semântica real do programa:
} else { // i > current
circle.src = 'images/25CB.svg'
circle.alt = 'Pick chance'
}Estou esquecendo de algo? Ou é bom fazer o que descrevi ou é uma má ideia?
+1 na resposta execllent de @ Christophe que a redundância no código aumenta as chances de defeitos. Há também um problema de eficiência muito menor . Para expandir isso, no que diz respeito ao exemplo de código em questão, poderíamos escrever a série de if-else-if como apenas if separados sem quaisquer outros fatores, mas geralmente não forneceríamos, desde o if-else, ao leitor a noção de alternativas exclusivas em vez de séries de condições independentes (o que também seria menos eficiente, pois isso indica que todas as condições devem ser avaliadas mesmo após uma partida).
—
Erik Eidt
@ErikEidt>, uma vez que diz que todas as condições devem ser avaliadas mesmo depois que uma corresponde a +1, a menos que você esteja retornando de uma função ou "interrompendo" um loop (o que não é o caso no exemplo acima).
—
Darek Nędza 22/09/19
+1, boa pergunta. Como um aparte, pode interessar-lhe que, na presença de NaNs, o exemplo não é exaustivo.
—
monocell 22/09/19