Declaração de mudança com retornos - correção do código

Digamos que eu tenha um código em C com aproximadamente esta estrutura:

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;
}

Obviamente, os breaks não são necessários para o código funcionar corretamente, mas parecerá uma prática ruim se eu não os colocar lá para mim.

O que você acha? Posso removê-los? Ou você os guardaria para aumentar a "correção"?

Remova as breakdeclarações. Eles não são necessários e talvez alguns compiladores emitam avisos de "Código inacessível" .

Eu tomaria uma abordagem totalmente diferente. NÃO RETORNE no meio do método / função. Em vez disso, basta colocar o valor de retorno em uma variável local e enviá-lo no final.

Pessoalmente, acho o seguinte mais legível:

String result = "";

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

return result;

Pessoalmente, gostaria de remover as devoluções e manter os intervalos. Eu usaria a instrução switch para atribuir um valor a uma variável. Em seguida, retorne essa variável após a instrução switch.

Embora este seja um ponto discutível, sempre achei que um bom design e encapsulamento significam uma entrada e uma saída. É muito mais fácil garantir a lógica e você não perderá acidentalmente o código de limpeza com base na complexidade ciclomática de sua função.

Uma exceção: retornar antecipadamente está correto se um parâmetro inválido for detectado no início de uma função - antes que quaisquer recursos sejam adquiridos.

Mantenha as pausas - é menos provável que você tenha problemas se / quando editar o código mais tarde, se as quebras já estiverem no lugar.

Dito isso, é considerado por muitos (inclusive eu) uma má prática retornar do meio de uma função. Idealmente, uma função deve ter um ponto de entrada e um ponto de saída.

Remova eles. É idiomático retornar de caseinstruções e, caso contrário, é ruído de "código inalcançável".

Eu iria removê-los. Em meu livro, um código morto como esse deve ser considerado um erro porque faz você ficar surpreso e se perguntar "Como eu executaria essa linha?"

Eu normalmente escreveria o código sem eles. IMO, código morto tende a indicar desleixo e / ou falta de compreensão.

Claro, eu também consideraria algo como:

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

return rets[something];

Editar: mesmo com a postagem editada, essa ideia geral pode funcionar bem:

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

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

Em algum ponto, especialmente se os valores de entrada forem esparsos (por exemplo, 1, 100, 1000 e 10000), você deseja uma matriz esparsa. Você pode implementar isso como uma árvore ou um mapa razoavelmente bem (embora, é claro, uma opção ainda funcione neste caso também).

Eu diria para removê-los e definir um padrão: branch.

Não seria melhor ter um array com

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

e fazer return arr[something];?

Se for sobre a prática em geral, você deve manter as breakinstruções no switch. No caso de você não precisar de returndeclarações no futuro, diminui a chance de passar para a próxima case.

Para "correção", blocos de entrada única e saída única são uma boa ideia. Pelo menos eles eram quando eu fiz minha graduação em ciência da computação. Então, eu provavelmente declararia uma variável, atribuiria a ela no switch e retornaria uma vez no final da função

O que você acha? Posso removê-los? Ou você os guardaria para aumentar a "correção"?

Não há problema em removê-los. Usar return é exatamente o cenário onde breaknão deve ser usado.

Interessante. O consenso da maioria dessas respostas parece ser que a breakafirmação redundante é uma desordem desnecessária. Por outro lado, eu li a breakdeclaração em um switch como o 'encerramento' de um caso. caseblocos que não terminam em umbreak tendem a saltar sobre mim como uma queda potencial através de insetos.

Eu sei que não é assim quando há um em returnvez de um break, mas é assim que meus olhos 'lêem' os blocos de caso em um switch, então eu pessoalmente prefiro que cada um caseseja pareado com um break. Mas muitos compiladores reclamam que o breakdepois returné supérfluo / inacessível, e aparentemente eu pareço estar em minoria de qualquer maneira.

Portanto, livre-se do breakseguintereturn .

NB: tudo isso ignora se violar a regra de entrada / saída única é uma boa ideia ou não. Quanto a isso, tenho uma opinião que, infelizmente, muda dependendo das circunstâncias ...

Eu digo para removê-los. Se o seu código é tão ilegível que você precisa colocar as quebras lá 'para estar no lado seguro', você deve reconsiderar seu estilo de codificação :)

Além disso, sempre preferi não misturar quebras e retornos na instrução switch, mas sim ficar com um deles.

Eu pessoalmente tendo a perder o breaks. Possivelmente, uma fonte desse hábito são os procedimentos da janela de programação para aplicativos do 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);
}

Pessoalmente, acho essa abordagem muito mais simples, sucinta e flexível do que declarar uma variável de retorno definida por cada manipulador e retorná-la no final. Dada essa abordagem, os breaks são redundantes e, portanto, devem ser eliminados - eles não têm nenhum propósito útil (sintaticamente ou IMO visualmente) e apenas incham o código.

Eu acho que o * intervalo * s têm um propósito. É para manter viva a 'ideologia' da programação. Se quisermos apenas 'programar' nosso código sem coerência lógica, talvez ele seja legível para você agora, mas tente amanhã. Tente explicar isso ao seu chefe. Tente executá-lo no Windows 3030.

Bleah, a ideia é muito simples:

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**;

/ * Só uma pequena questão. Quanto café você bebeu durante a leitura do texto acima? TI quebra o sistema às vezes * /

Saia do código em um ponto. Isso fornece melhor legibilidade para o código. Adicionar instruções de retorno (saídas múltiplas) entre elas tornará a depuração difícil.

Se você tiver o tipo de código "lookup", poderá empacotar a cláusula switch-case em um método por si só.

Eu tenho alguns desses em um sistema de "hobby" que estou desenvolvendo para me divertir:

private int basePerCapitaIncomeRaw(int tl) {
    switch (tl) {
        case 0:     return 7500;
        case 1:     return 7800;
        case 2:     return 8100;
        case 3:     return 8400;
        case 4:     return 9600;
        case 5:     return 13000;
        case 6:     return 19000;
        case 7:     return 25000;
        case 8:     return 31000;
        case 9:     return 43000;
        case 10:    return 67000;
        case 11:    return 97000;
        default:    return 130000;
    }
}

(Sim. Esse é o espaço GURPS ...)

Concordo com os outros que você deve, na maioria dos casos, evitar mais de um retorno em um método e reconheço que este poderia ter sido melhor implementado como um array ou outra coisa. Acabei de descobrir que switch-case-return é uma combinação muito fácil para uma tabela de pesquisa com uma correlação de 1-1 entre entrada e saída, como a coisa acima (jogos de RPG estão cheios deles, tenho certeza de que existem em outros "negócios" também): D

Por outro lado, se a cláusula case for mais complexa, ou algo acontecer após a instrução switch, eu não recomendaria usar return nela, mas sim definir uma variável na switch, terminar com uma pausa e retornar o valor da variável no final.

(Por outro lado ... você sempre pode refatorar um switch em seu próprio método ... Duvido que tenha um efeito no desempenho, e não me surpreenderia se compiladores modernos pudessem reconhecê-lo como algo que poderia ser embutido ...)