c - name - seo meta tags

Conmutar declaración con devoluciones-corrección de código

Question

Digamos que tengo un código en C con aproximadamente esta estructura:

switch (something)
{
    case 0:
      return "blah";
      break;

    case 1:
    case 4:
      return "foo";
      break;

    case 2:
    case 3:
      return "bar";
      break;

    default:
      return "foobar";
      break;
}

Ahora, obviamente, los "quiebres" no son necesarios para que el código se ejecute correctamente, pero parece una mala práctica si no los pongo ahí.

¿Qué piensas? ¿Está bien eliminarlos? ¿O los conservarás para una mayor "corrección"?

Answer 1

¿Qué piensas? ¿Está bien eliminarlos? ¿O los conservarás para una mayor "corrección"?

Está bien eliminarlos. El uso de return es exactamente el escenario en el que no se debe usar el break .

Answer 2

¿No sería mejor tener una matriz con

arr[0] = "blah"
arr[1] = "foo"
arr[2] = "bar"

y return arr[something]; ?

Si se trata de la práctica en general, debe mantener las declaraciones de interrupción en el cambio. En el caso de que no necesite declaraciones de return en el futuro, se reduce la posibilidad de que caiga en el siguiente case .

Answer 3

Creo que los * break * s están ahí para un propósito. Es mantener viva la ''ideología'' de la programación. Si solo queremos ''programar'' nuestro código sin coherencia lógica, tal vez sería legible para usted ahora, pero intente mañana. Intenta explicárselo a tu jefe. Intente ejecutarlo en Windows 3030.

Bleah, la idea es muy simple:

Switch ( Algorithm )
{

 case 1:
 {
   Call_911;
   Jump;
 }**break**;
 case 2:
 {
   Call Samantha_28;
   Forget;
 }**break**;
 case 3:
 {
   Call it_a_day;
 }**break**;

Return thinkAboutIt?1:return 0;

void Samantha_28(int oBed)
{
   LONG way_from_right;
   SHORT Forget_is_my_job;
   LONG JMP_is_for_assembly;
   LONG assembly_I_work_for_cops;

   BOOL allOfTheAbove;

   int Elligence_says_anyways_thinkAboutIt_**break**_if_we_code_like_this_we_d_be_monkeys;

}
// Sometimes Programming is supposed to convey the meaning and the essence of the task at hand. It is // there to serve a purpose and to keep it alive. While you are not looking, your program is doing  // its thing. Do you trust it?
// This is how you can...
// ----------
// **Break**; Please, take a **Break**;

/ * Solo una pequeña pregunta sin embargo. ¿Cuánto café has tenido mientras leías lo anterior? TI Rompe el sistema a veces * /

Answer 4

Eliminar las declaraciones de interrupción. No son necesarios y tal vez algunos compiladores emitan advertencias de "código inalcanzable".

Answer 5

Eliminarlos. Es idiomático regresar de las declaraciones de case , y de lo contrario es ruido de "código inalcanzable".

Answer 6

Interesante. El consenso de la mayoría de estas respuestas parece ser que la declaración de break redundante es un desorden innecesario. Por otro lado, leí la declaración de interrupción en un interruptor como el ''cierre'' de un caso. case bloques de case que no terminan en un break tienden a saltar hacia mí como posibles errores de caída.

Sé que no es así cuando hay un return lugar de un break , pero así es como mis ojos "leen" el caso bloquea un interruptor, por lo que personalmente preferiría que cada case se combinara con un break . Pero muchos compiladores se quejan de la break después de un return es superfluo / inalcanzable, y aparentemente parezco estar en minoría de todos modos.

Así que deshazte del break después de un return .

NB: todo esto ignora si la violación de la regla de entrada / salida única es una buena idea o no. En la medida de lo posible, tengo una opinión que lamentablemente cambia según las circunstancias ...

Answer 7

Mantenga los descansos: es menos probable que tenga problemas si edita el código más tarde si los cortes ya están en su lugar.

Una vez dicho esto, muchos (incluido yo) consideran que es una mala práctica regresar desde el medio de una función. Idealmente, una función debe tener un punto de entrada y un punto de salida.

Answer 8

Normalmente escribiría el código sin ellos. OMI, código muerto tiende a indicar descuido y / o falta de comprensión.

Por supuesto, también consideraría algo como:

char const *rets[] = {"blah", "foo", "bar"};

return rets[something];

Editar: incluso con la publicación editada, esta idea general puede funcionar bien:

char const *rets[] = { "blah", "foo", "bar", "bar", "foo"};

if ((unsigned)something < 5)
    return rets[something]
return "foobar";

En algún momento, especialmente si los valores de entrada son escasos (por ejemplo, 1, 100, 1000 y 10000), en su lugar, desea una matriz dispersa. Puede implementar eso como un árbol o un mapa razonablemente bien (aunque, por supuesto, un interruptor todavía funciona en este caso también).

Answer 9

Para "corrección", una sola entrada, bloques de salida individuales son una buena idea. Al menos lo fueron cuando hice mi grado de informática. Probablemente declare una variable, se la asigne en el interruptor y vuelva una vez al final de la función

Answer 10

Personalmente eliminaría las devoluciones y mantendría los descansos. Usaría la declaración de cambio para asignar un valor a una variable. A continuación, devuelva esa variable después de la declaración de cambio.

Aunque este es un punto discutible, siempre he pensado que un buen diseño y encapsulado significa una manera de entrar y salir. Es mucho más fácil garantizar la lógica y no te pierdes accidentalmente el código de limpieza basado en la complejidad ciclomática de tu función.

Una excepción: el regreso temprano está bien si se detecta un parámetro incorrecto al comienzo de una función, antes de que se adquieran recursos.

Answer 11

Personalmente tiendo a perder el break s. Posiblemente, una fuente de este hábito proviene de los procedimientos de programación de ventanas para aplicaciones de Windows:

LRESULT WindowProc (HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
    switch (uMsg)
    {
        case WM_SIZE:
            return sizeHandler (...);
        case WM_DESTROY:
            return destroyHandler (...);
        ...
    }

    return DefWindowProc(hwnd, uMsg, wParam, lParam);
}

Personalmente, considero que este enfoque es mucho más simple, breve y flexible que declarar una variable de retorno establecida por cada controlador, y luego devolverla al final. Dado este enfoque, las break son redundantes y, por lo tanto, deben irse; no sirven para nada (sintácticamente o IMO visualmente) y solo inflan el código.

Answer 12

Tomaría una táctica diferente por completo. NO REGRESE en el medio del método / función. En su lugar, simplemente coloque el valor de retorno en una variable local y envíela al final.

Personalmente, encuentro que lo siguiente es más legible:

String result = "";

switch (something) {
case 0:
  result = "blah";
  break;
case 1:
  result = "foo";
  break;
}

return result;

Answer 13

Yo digo eliminarlos. Si tu código es tan ilegible que necesitas pegar pausas allí para estar seguro, deberías reconsiderar tu estilo de codificación :)

También siempre he preferido no mezclar saltos y retornos en la declaración de cambio, sino seguir con uno de ellos.

Answer 14

Yo diría eliminarlos y definir un predeterminado: rama.

Answer 15

Yo los eliminaría. En mi libro, un código muerto como ese debería considerarse un error porque hace que lo hagas doblemente y te preguntes "¿Cómo podría ejecutar esa línea?"