¿Es necesario agregar el caso predeterminado mientras se usan los casos de cambio?

Durante una revisión reciente del código, se me pidió que pusiera defaultcasos en todos los archivos dondequiera switchque se use el bloque, incluso si no hay nada que hacer default. Eso significa que tengo que poner el defaultcaso y no escribir nada en él.

¿Es esto lo correcto? ¿Qué propósito tendría?

Parece que hay tres casos cuando una defaultdeclaración no es necesaria:

1. no quedan otros casos, porque hay un conjunto limitado de valores que ingresan al switch case. Pero esto podría cambiar con el tiempo (intencionalmente o accidentalmente), y sería bueno tener un cambio default casesi algo cambia _ podría registrar o advertir al usuario sobre un valor incorrecto.

2. usted sabe cómo y dónde switch casese usará y qué valores ingresarán. De nuevo, esto podría cambiar y podría ser necesario un procesamiento adicional.

3. otros casos no necesitan ningún procesamiento especial. Si este es el caso, creo que se le pide que agregue un default case, porque es un estilo de codificación aceptado y hace que su código sea más legible.

Los dos primeros casos se basan en suposiciones. Entonces (suponiendo que trabaje en un equipo no tan pequeño ya que tiene revisiones de código regulares), no puede permitirse hacer esas suposiciones. No sabe quién estará trabajando con su código o haciendo llamadas a funciones / invocando métodos en su código. Del mismo modo, es posible que deba trabajar con el código de otra persona. Tener el mismo estilo de codificación facilitará el manejo del código de alguien (incluido el suyo).

¿Es esto lo correcto? Qué propósito tendría ?

No es raro que los estándares de codificación de la empresa requieran un caso predeterminado para todas las switchdeclaraciones. Una razón para ello es que facilita a los lectores encontrar el final de la switch. Otra razón, probablemente mejor, es que te hace pensar por un segundo sobre lo que debe hacer tu código cuando la condición no coincide con tus expectativas. Independientemente de la razón del requisito, si es un estándar de la compañía, debe seguirlo a menos que haya una razón hermética para no hacerlo.

Si cree que switchincluye casos para cada condición posible, entonces una buena cosa es hacer una assertdeclaración en el caso predeterminado. De esa manera, cuando alguien cambia el código y, sin darse cuenta, agrega una condición que switchno cubre, tocará el botón asserty se dará cuenta de que necesita abordar esa parte del código.

Si switchsolo cubre algunas de las condiciones posibles, pero no hay que hacer nada especial para las demás, puede dejar el caso predeterminado vacío. Es una buena idea agregar un comentario en ese caso para indicar que el caso predeterminado está vacío intencionalmente porque las condiciones que lo afectan no necesitan ningún trabajo.

Si "activa" el tipo de enumeración pura, es peligroso tener una reserva predeterminada. Cuando luego agregue valores al tipo de enumeración, el compilador resaltará los interruptores con nuevos valores no cubiertos. Si tiene una cláusula predeterminada allí, el compilador permanecerá en silencio y es posible que se lo pierda.

En muchos aspectos, esta pregunta es la misma que la pregunta frecuente ¿Necesito una elsecláusula al final de un if/ else ifladder que cubra todas las opciones ?

La respuesta es, sintácticamente hablando, no, no lo haces. Pero hay un sin embargo ...

Una defaultcláusula puede estar allí por (al menos) dos razones:

1. Como un controlador de errores, claro, ¡ nunca debería llegar aquí! es un reclamo que se puede hacer, pero ¿y si lo hace? La corrupción de datos, o peor aún, la falta de validación de datos, son rutas para fallar en el programa si no se atrapa adecuadamente. En este caso, ¡no debería ser una cláusula vacía!
2. Cobertura de diseño / código: incluso en la forma más simple de un diagrama de flujo, hay dos rutas desde una declaración if, y siempre otherwisedesde un caso. No hay ninguna razón para no incluirlos en el código fuente.

Mi filosofía siempre es bastante simple: evaluar el peor de los casos de las dos opciones y elegir el más seguro. En el caso de una cláusula elseo una defaultcláusula vacía , las peores opciones son:

• Inclúyalos: Tres o cuatro líneas adicionales de código "redundante".
• No incluirlos: los datos no autorizados o una condición inesperada no quedan atrapados, lo que puede provocar un error del programa.

¿Sobredramático? Tal vez ... pero mi software tiene el potencial de matar gente si sale mal. Prefiero no correr ese riesgo.

Además, las pautas de MISRA-C {ver perfil para afiliación} recomiendan una defaultcláusula para cadaswitch

Java no lo obliga a tener una declaración 'predeterminada', pero es una buena práctica tenerla todo el tiempo, incluso si el código nunca se puede alcanzar (en este momento). Aquí hay algunas razones:

Al tener una cláusula predeterminada inalcanzable, le muestra al lector de su código que consideró los valores y sabe lo que está haciendo. También permite futuros cambios, por ejemplo: si se agrega un nuevo valor de enumeración, el interruptor no debe ignorar silenciosamente el nuevo valor; puedes lanzar una Excepción allí o hacer otra cosa.

Para atrapar un valor inesperado (en caso de que no esté activando una enumeración) que se pasa, puede ser mayor o menor de lo que esperaba, por ejemplo.

Para manejar acciones 'predeterminadas', donde los interruptores son para un comportamiento especial. Por ejemplo, una variable puede declararse fuera del conmutador pero no inicializarse y cada caso la inicializa en algo diferente. El valor predeterminado en este caso podría inicializarlo a un valor predeterminado para que el código inmediatamente después del cambio no produzca un error / arroje una excepción.

Incluso si decide no poner nada en el valor predeterminado (sin excepciones, registros, etc.), incluso un comentario para decir que ha considerado que el hecho de que nunca ocurrirá un valor predeterminado puede ayudar a la legibilidad de su código; Pero eso se reduce a la preferencia personal.

También agregaría que depende de la filosofía del lenguaje que esté utilizando. En Erlang, por ejemplo, donde es un enfoque común para "dejar que se bloquee", no definiría un caso predeterminado, pero dejaría que su casedeclaración generara un error si se produce una situación que no fue atendida.

Siempre debe tener un valor predeterminado a menos que haya cubierto de manera comprobable y permanente todos los casos. No cuesta nada y es un seguro contra el incumplimiento de mantener su declaración de cambio en un programa en evolución.

Si está realmente seguro de que no le importan otros casos, el valor predeterminado: break; // no me importa, pero el valor predeterminado predeterminado debería ser algo así como predeterminado: arrojar un nuevo error ("valor inesperado");

Del mismo modo, nunca debe "omitir" una construcción de caso no trivial sin agregar un comentario al efecto que desea omitir. Java se equivocó en la etapa de diseño.

Considerar

enum Gender
{
       MALE ,
       FEMALE ;
}

y

void run ( Gender g )
{
      switch ( g )
      {
           case MALE :
                 // code related to males
                 break ;
           default :
                 assert Gender . FEMALE . equals ( g ) ;
                 // code related to females
                 break ;
      }
}

Yo diría que esto es superior a tener un caso MALE, un caso FEMENINO y un caso predeterminado que arroja una excepción.

Durante la fase de prueba, la computadora verificará si g es FEMENINO. Durante la producción, se omitirá el cheque. (Sí, una microoptimización!)

Más importante aún, mantendrá su objetivo de 100% de cobertura de código. Si escribiste un caso predeterminado que arroja una excepción, ¿cómo lo probarías?