¿esta declaración de cambio huele mal?

Switch(some case) { 
    case 1: 
      // compute something ... 
      return something; 
      break; 
    case 2: 
      // compute something ... 
      return something; 
      break; 

/* some more cases ... */ 

    case X: 
      // compute something ... 
      return something; 
      break; 
    default: 
      // do something 
      return something; 
      break; 
}

En mi opinión:¿esta declaración de cambio huele mal?

Suponiendo que esta sentencia switch es justificable, el retorno y romper apenas no se ve bien o se siente bien.

La ruptura es obviamente redundante, pero es un estilo de omisión pobre (¿o es este estilo pobre para empezar?)?

Yo personalmente no hago esto, pero hay algo de esto en la base de código en el trabajo. Y no, no voy a ser farisaico y corregiré la base de código.

Fuente

2009-03-27 Anonymous

LOLLLL @ la etiqueta "código de olor"! – Poni

El compilador de C# da una advertencia si haces esto diciendo que el código de ruptura es inalcanzable. Entonces, en mi libro, es mala forma tener tanto retorno como ruptura.

Fuente

2009-03-27 16:01:44

Una gran fuente de reflexión para las personas que utilizan idiomas interpretados –

En mi opinión, omitiría la palabra clave 'break'. Personalmente creo que ayuda a recordarle a la gente que '¡la ejecución ha terminado! ¡Nada más que ver aquí!'.

Fuente

2009-03-27 15:59:40 MPritchard

me gustaría hacer un pequeño cambio:

switch(some case) { 
    case 1: 
      // compute something ... 
      break; 
    case 2: 
      // compute something ... 
      break; 
/* some more cases ... */ 
    case X: 
      // compute something ... 
      break; 
    default: 
      // do something 
      break; 
} 
return something;

Fuente

2009-03-27 15:59:59 Elie

Recomendaría esto, ya que significa que debe leer todo el enunciado del caso para verificar si algo más le sucede a la variable 'algo'. Si acaba de regresar, está inmediatamente claro que, no, nada lo hace :-) – MPritchard

Dado que tiene una declaración de interrupción al final de cada caso, nada más podría cambiarla. Sin embargo, después de haber leído algunas de las otras respuestas, estaría de acuerdo con que la alternativa sería reemplazar cada una de las rupturas con la declaración de devolución. – Elie

Elie - Veo de dónde vienes, consideraría esta como la respuesta del libro de texto –

No, omisión no es un estilo pobre - inclusión es pobre estilo. Esas son declaraciones inalcanzables. Deshazte de ellos.

Me gusta el hecho de que las fundas vuelvan directamente en lugar de establecer una variable local y luego regresar justo en la parte inferior; significa que es increíblemente claro cuando está leyendo el código que hace falta, y eso es todo.

nota lateral, en términos de conmutación en el primer lugar:

En cuanto a si el uso de una sentencia switch es lo que hay que hacer aquí, que realmente depende de otras cosas. ¿Tendría sentido usar un tipo polimórfico en su lugar? Si estás en Java, ¿podrías usar una enumeración inteligente? (Puede imitar estos en C#, pero no hay tanto soporte.)

Yo diría que esto debería al menos solicitar teniendo en cuenta diseños diferentes, pero puede ser la forma más sencilla de hacer lo que quiera .

Fuente

2009-03-27 16:00:04

Poner una declaración de devolución en todos los casos está bien hasta el día en que decida hacer algo más para 'algo' antes de regresar. Digamos, por ejemplo, que quiere registrar las cosas. Ahora, en lugar de un lugar central en la parte inferior de tu rutina, tienes que revisar y quizás reconsiderar todos los casos. Como todos los demás, no siempre cumplo con la directriz de "un punto de retorno", pero hay razones para ello y este ejemplo de cambio de muchos casos lo pide. –

Entonces, en ese punto, puede extraerlo en un método diferente o puede cambiarlo para usar una variable local. No hay problema en dejar eso hasta que realmente lo necesites ... y es una refactorización mecánica, después de todo. –

El olor del código implica un problema de diseño. Esto es solo un problema de formateo. Creo que la mayoría de la gente estaría de acuerdo en que una versión omitida es superior.

Fuente

2009-03-27 16:01:31 Tmdean

La interrupción es redundante.

Algunas reglas generales, siempre es bueno salir de una función en un solo lugar, pero desde que se hizo esta regla, Try-Catch fue inventada (oop goto).

Si mantiene el mismo estilo en toda la aplicación, creo que puede vivir con la devolución en el interruptor.

Fuente

2009-03-27 16:02:13

no estoy seguro de cómo literal que el código está destinado a ser lo que algunas de estas observaciones pueden no ser aplicables ...

"caso 1" Si usted es realmente difícil numers codificantes como este me piensa que es un estilo pobre y deberías considerar usar una enumeración.

Si simplemente está devolviendo algo y no hay una lógica adicional en un subconjunto de casos, puede considerar poner los "algo" en una matriz o diccionario y simplemente abordarlos por su índice en lugar de usar una declaración de cambio. ..

tantos retorno [índice]

Fuente

2009-03-27 16:03:17 lJohnson

El olor código aquí son los valores codificados en las declaraciones de casos.

En cuanto a las devoluciones, es más una cuestión de gusto y buen juicio. Claro que si su caso abarca páginas múltiples, es más fácil de leer si la devolución está en el caso, pero entonces el problema es el gran cambio para empezar.

Personnaly Prefiero la opción de devolución única porque si alguna vez necesita agregar algo más de procesamiento, entonces es más barato refactorizar que visitar todos los casos. Además, si se le da a otra persona para refactorizar, no tendrán la tentación de copiar y pegar el código en todos los casos, al menos eso espero ... si lo hacen, es mejor que no sea yo quien haga su revisión del código (para el copiar pegar obviamente).

Fuente

2009-04-03 07:35:15 Newtopian

¿Estabas bromeando sobre los valores codificados? ¿No puedes ver que estaba usando pseudocódigo? –

sí Veo que está usando un pseudo código, y también veo que los valores de los casos no son constantes, sino números. Todo lo que digo es que los números como valores de casos huelen mal y generalmente indican algo que necesita atención. – Newtopian

el regreso ...descanso; no es un código que huele, es solo un problema de formateo, cualquiera que sea la forma de cortarlo, nunca causará un error. Por lo tanto, estaba diciendo, que si hay un olor a código aquí debería ser que los números en cuanto al resto no califica como un olor a código, en mi humilde opinión. – Newtopian

Las declaraciones de interruptor son en sí mismas un olor a código.

En la línea de lo que l99057j dijo, si todo lo que hace es mapear entradas a valores constantes, este es un lugar para una estructura de búsqueda apropiada, como una matriz/lista para entradas secuenciales o un diccionario/mapa para uno escaso, no una declaración de cambio. Si está calculando algo, entonces el valor sería un delegado al que llama con la entrada.

Fuente

2009-11-20 17:33:35

Otros han comentado sobre otros aspectos. En cuanto a las interrupciones que son redundantes después de los retornos: LAS GUARDARÉ, siguiendo el mismo razonamiento que {} en torno a un solo enunciado si cuerpo: debería ser una segunda naturaleza para cada programador colocar esos frenos allí. Es mejor tener 100 de esas interrupciones redundantes que una falta involuntariamente.

Fuente

2011-09-10 21:11:42

¿esta declaración de cambio huele mal?

Respuesta

Cuestiones relacionadas