2011-03-10 8 views
15

He estado leyendo un montón de códigos en las últimas semanas y estoy empezando a pensar que he estado codificando la declaración de cambio (en todos los idiomas similares) mal. Las palabras clave switch y case se alinean en la mayoría de los ejemplos que estoy viendo en la naturaleza. Siempre sangraba los casos que me daban más importancia. El inconveniente es que si tiene un caso con un condicional, las llaves aparecen buscando dos niveles de indentación desde el interruptor exterior; entonces tal vez NO sangrar el caso es correcto. Tenga curiosidad por ver qué piensan los demás acerca de esta pregunta estilística.indentación de la caja del interruptor

Aquí hay un ejemplo de cómo yo he estado haciendo (si mi pregunta tiene que ser más visual):

switch(keyCode) { 
     case TVKEY.KEY_EXIT: 
      // do something 
     case TVKEY.KEY_ENTER: 
      if(firstTest)) { // User chose to steal token 
       // do something 
      } else if(secondTest)) { 
       // other condition 
      } else { 
       // do else 
      } 
      break; 
     default: 
      // do default stuff 
      break; 

    } 

Aviso soporte de la última de contional es de dos niveles en el soporte del interruptor de cierre. ¿Incorrecto? Demasiado quisquilloso?

+0

duplicado posible de [¿Por qué la gente no sangrar instrucciones de especificadores de acceso/C++ de caso?] (Http://stackoverflow.com/questions/4299729/ why-dont-people-indent-c-access-specifiers-case-statements) – Antonio

Respuesta

12

Así que, básicamente, están discutiendo entre

switch(x) { 
    case 1: if (something) { 
      } 
    case 2: if (other) { 
      } 
} 

y

switch (x) { 
case 1: if (something) { 
     } 
case 2: if (other) { 
     } 
} 

personalmente prefiero la primera, aunque lo haga más cosas-guión. Al menos hace que el contenido del interruptor se destaque mejor.

ETA:

Ok, por lo que ha añadido una muestra. Sigo diciendo que es preferible el exceso de sangrías, debido a la claridad visual de lo que pertenece a dónde.

Por supuesto, la sangría puede/causará guerras santas: ¿Tabs/Spaces? la pestaña se detiene a 4 caracteres? 8 caracteres? ¿Tenedor? ¿Cuchara?

+1

¡Boo! ¡¡Silbido!! :-) – Ben

+16

Debo decir que no me importa iniciar el si en la misma línea que el caso, ya que eso realmente hace que la sangría sea extraña para ambos casos IMO – Rob

+0

Si el interruptor está en una enumeración y las constantes son incluso moderadas length ('ABC_MAIN_ALTERNATIVE'), luego terminas con enormes sangrías. Cuando las cosas tienen solo un dígito, no es tan malo, pero el mundo real no se trata solo de un solo dígito. –

7

Mi preferencia es que el case comience en la misma columna que el switch.

Mis razones son dos:

  1. La muesca código no es excesiva.

  2. Refleja la estructura de if, else if, else cláusulas. Probablemente, todos pensarían que el if y el else deberían alinearse, ya que son parte del código de control lógico de una única construcción condicional. El switch y el case también son claramente parte del código de control lógico de una única construcción condicional y, por consistencia, deben estar alineados. Después de todo, una construcción switch-case se puede volver a escribir como una construcción if-else y, una vez compilada, daría el mismo código de bajo nivel.

6

Mis 2 centavos, porque acabo de enfrentar el tema y encontré una solución que me gusta lo suficiente como para compartir =)

switch (mode) 
{ 
    case Value1: 
    { 
     Ptr_t ptr1 = ...; 
     return ptr1; 
    } 

    case Value2: 
    { 
     Ptr_t ptr2 = ...; 
     return ptr2; 
    } 

    default: 
    { 
     return nullptr; 
    } 
} 

explicación:

  1. A veces, hay que alcance los bloques de casos en elogios para declarar las variables locales en él. (Es un error declarar una variable después de case ya que la palabra clave no define un alcance por sí mismo. Bueno, no es la pregunta).Elijo abarcar todo para que, independientemente del contenido del caso, todo sea siempre coherente.

  2. ¡Legibilidad! Encuentro realmente claro lo que está pasando aquí, así que es un buen punto. Hay alguna indentación innecesaria, pero ¿a quién le importa cuando mejora la legibilidad?

  3. La alineación de elogios case y default se parece a otras estructuras de control, por lo que no es sorprendente para los lectores nuevos.

No es una respuesta real/definitiva, solo una elección personal.

1

Encontramos la solución más adecuada para nosotros. Sangra la palabra clave del caso (y por defecto también, también esto se aplica a público, protegido y privado) por espacio simple (se aplica a las preferencias de sangría de espacio o tabulación). Esto parece dar lo mejor de ambos mundos.

El único inconveniente que he encontrado hasta ahora: parece que no hay una herramienta de embellecimiento de automóviles que se pueda encontrar de esa manera.

Esto es como el código de la pregunta se parecería a

switch (keyCode) { 
    case TVKEY.KEY_EXIT: // indented by one space against switch 
    // do something 
    case TVKEY.KEY_ENTER: 
    if (firstTest) { // indented by one tab sizes against switch 
     // do something 
    } else if (secondTest) { 
     // other condition 
    } else { 
     // do else 
    } 
    break; // empty line visualize block, so you know code is not passing to next case 

default: 
    // do default stuff 
    break; 

} 
+0

Por favor, muestre un ejemplo, no está demasiado claro con solo una descripción de texto – Wndrr

Cuestiones relacionadas