Maneira elegante de lidar com vários caminhos baseados na condição composta [closed]

Question

Maneira elegante de lidar com vários caminhos baseados na condição composta [closed]

#1 resposta do (8 votos)
#2 resposta do (4 votos)
#3 resposta do (3 votos)
#4 resposta do (1 votos)

4

Considere o seguinte:

if (x == 5 || x == 10 || x == 12) {
    if (x == 5) {
        doSomething()
    } else if (x == 10) {
        doSomethingElse()
    } else {
        doSomeOtherThing()
    }

    doMoreThings()
}

doThingsAfterThat()

O segundo conjunto de condições parece repetitivo, como eu as especifiquei na condição original. Eu poderia separar isso em dois condicionais, mas eu estaria repetindo 'doSomeOtherThings ()'.

Qual é a maneira mais elegante de lidar com isso?

Editar :

Esta não é uma duplicata de maneiras elegantes de lidar com se (se else) else . As razões são:

Na possível pergunta duplicada, a condição interna está testando um valor diferente do que está sendo testado na condição original. Nesta questão, as condições internas que estão sendo testadas são as mesmas que a condição original.
Nesta questão, é preciso considerar várias instruções if if else. A questão duplicada em potencial não considera isso.

coding-style conditions dry

por David Poxon 18.09.2015 / 06:15

fonte

4 respostas

Tags coding-style conditions dry

Minimizando pequenos erros de codificação [fechados] Existe uma prática recomendada para alocação / desalocação de múltiplos arrays dinâmicos em C?

score 8 · Answer 1

Procedimentos (ou funções ou métodos) existem devido à necessidade de aplicar o mesmo padrão de ações em muitas situações. Portanto, não há nada errado em repetir uma chamada de método algumas vezes. Repetir uma chamada três vezes não é um problema.

Mantenha tudo simples, evite aninhamento desnecessário, minimize linhas de código e minimize etapas executadas.

if (x == 5) {
    doSomething();
    doMoreThings();
} else if (x == 10) {
    doSomethingElse();
    doMoreThings();
} else if (x == 12) {
    doSomeOtherThing();
    doMoreThings();
}
doThingsAfterThat();

score 4 · Answer 2

A melhor solução é aquela que minimiza a quantidade de código que você precisa escrever e, portanto, a quantidade de código que você precisa para ler para entender o que está acontecendo. Geralmente, lemos qualquer pedaço de código mais vezes do que o escrevemos, então a clareza é a qualidade mais importante do código. (Além da correção, é claro).

Em vista disso, o código em sua própria pergunta é a melhor opção.

A resposta "Come from" também é muito boa, mas o que isso significa é que é mais natural pensar na solução do problema que seu código está resolvendo. Presumivelmente, você escreveu seu código do seu jeito e não "veio da maneira", porque essa era a maneira mais natural para você pensar em resolver seu problema. Então, isso é (quase por definição eu diria) o melhor caminho.

Qualquer outra opção complicaria o seu código e para quê? a fim de evitar escrever mais algumas declarações, sejam elas if declarações ou declarações de função.

Observe que o fato de você escrever essas instruções duas vezes não significa necessariamente que elas serão emitidas pelo compilador duas vezes, ou executadas duas vezes: fique certo de que o compilador fará o melhor para reestruturar o sistema. código emitido de modo a evitar qualquer duplicação desnecessária. (E se não puder, então haverá uma pequena duplicação. E daí?)

Essencialmente, como o compilador é livre para fazer o que quiser nos bastidores, o único objetivo restante para o seu código é explicar o que deve acontecer da maneira mais clara possível. A concisão também é um objetivo nobre, mas nunca à custa da clareza.

score 3 · Answer 3

Ele pode ajudar se você der nomes às condições, mas acho que é questionável neste exemplo simples. Com condições mais complexas, o benefício seria mais claro. Se algum dia você decidir mudar uma condição, terá que fazê-lo em um só lugar e não se arrisque a apresentar uma inconsistência.

final boolean someP = (x == 5);
final boolean elseP = (x == 10);
final boolean otherP = (x == 12);

if (someP) {
    doSomething();
}
if (elseP) {
    doSomethingElse();
}
if (otherP) {
    doSomeOtherThing();
}
if (someP || elseP || otherP) {
    doMoreThings();
}

doThingsAfterThat();

score 1 · Answer 4

por que não usar caso para indivíduo se e um para ou condição.

switch (x) {
 case 5: doSomething5();
        break;
   case 10: doSomething10();
        break;
case 12 : doSomething12();
        break;
}

if (x==5 || x == 10 || x == 12){
doMoreThings();
}
doThingsAfterThat();

doMoreThings também podem estar dentro do case. Mas será repititivo.

switch (x){

case 5: doSomething5();
         doMoreThings();
        break;
case 10: doSomething10();
         doMoreThings();
        break;
case 12 : doSomething12();
         doMoreThings();
       break;
       }

* se as condições forem complexas, então a verificação de variáveis simples não funcionará.