Uma função deve ter apenas uma instrução de retorno?

Question

Existem boas razões pelas quais é uma prática melhor ter apenas uma instrução de retorno em uma função?

Ou não há problema em retornar de uma função assim que for logicamente correto fazê-lo, o que significa que pode haver muitas instruções de retorno na função?

Answer 1

Muitas vezes tenho várias declarações no início de um método para retornar em situações "fáceis".Por exemplo, isto:

public void DoStuff(Foo foo)
{
    if (foo != null)
    {
        ...
    }
}

...pode ser mais legível (IMHO) assim:

public void DoStuff(Foo foo)
{
    if (foo == null) return;

    ...
}

Então, sim, acho que não há problema em ter vários "pontos de saída" de uma função/método.

Answer 2

Ninguém mencionou ou citou Código completo então eu farei isso.

17.1 retorno

Minimize o número de retornos em cada rotina.É mais difícil entender uma rotina se, ao lê-la no final, você não tem consciência da possibilidade de ela ter retornado em algum lugar acima.

Use um retornar quando melhora a legibilidade.Em certas rotinas, depois de saber a resposta, você deseja retorná-la imediatamente à rotina de chamada.Se a rotina for definida de forma que não exija nenhuma limpeza, não retornar imediatamente significa que você terá que escrever mais código.

Answer 3

Eu diria que seria extremamente imprudente decidir arbitrariamente contra vários pontos de saída, pois descobri que a técnica é útil na prática uma e outra vez, na verdade, muitas vezes código existente refatorado para vários pontos de saída para maior clareza.Podemos comparar as duas abordagens assim: -

string fooBar(string s, int? i) {
  string ret = "";
  if(!string.IsNullOrEmpty(s) && i != null) {
    var res = someFunction(s, i);

    bool passed = true;
    foreach(var r in res) {
      if(!r.Passed) {
        passed = false;
        break;
      }
    }

    if(passed) {
      // Rest of code...
    }
  }

  return ret;
}

Compare isso com o código onde vários pontos de saída são permitido:-

string fooBar(string s, int? i) {
  var ret = "";
  if(string.IsNullOrEmpty(s) || i == null) return null;

  var res = someFunction(s, i);

  foreach(var r in res) {
      if(!r.Passed) return null;
  }

  // Rest of code...

  return ret;
}

Acho que o último é consideravelmente mais claro.Pelo que posso dizer, a crítica aos múltiplos pontos de saída é um ponto de vista bastante arcaico nos dias de hoje.

Answer 4

Atualmente estou trabalhando em uma base de código onde duas das pessoas que trabalham nela subscrevem cegamente a teoria do "ponto único de saída" e posso dizer que, por experiência própria, é uma prática horrível e horrível.Isso torna o código extremamente difícil de manter e vou mostrar o porquê.

Com a teoria do “ponto único de saída”, você inevitavelmente acaba com um código parecido com este:

function()
{
    HRESULT error = S_OK;

    if(SUCCEEDED(Operation1()))
    {
        if(SUCCEEDED(Operation2()))
        {
            if(SUCCEEDED(Operation3()))
            {
                if(SUCCEEDED(Operation4()))
                {
                }
                else
                {
                    error = OPERATION4FAILED;
                }
            }
            else
            {
                error = OPERATION3FAILED;
            }
        }
        else
        {
            error = OPERATION2FAILED;
        }
    }
    else
    {
        error = OPERATION1FAILED;
    }

    return error;
}

Isso não apenas torna o código muito difícil de seguir, mas agora diga mais tarde que você precisa voltar e adicionar uma operação entre 1 e 2.Você precisa recuar quase toda a maldita função e boa sorte para garantir que todas as condições if/else e chaves correspondam corretamente.

Este método torna a manutenção do código extremamente difícil e sujeita a erros.

Answer 5

Programação estruturada diz que você deve ter apenas uma instrução de retorno por função.Isso é para limitar a complexidade.Muitas pessoas como Martin Fowler argumentam que é mais simples escrever funções com múltiplas instruções de retorno.Ele apresenta esse argumento no clássico reestruturação livro que ele escreveu.Isso funciona bem se você seguir os outros conselhos e escrever pequenas funções.Concordo com esse ponto de vista e apenas os puristas estritos da programação estruturada aderem a declarações de retorno único por função.

Answer 6

Como observa Kent Beck ao discutir cláusulas de guarda em Padrões de Implementação fazer uma rotina ter um único ponto de entrada e saída...

"Era para impedir a confusão possível ao entrar e sair de muitos locais na mesma rotina.Fazia sentido quando aplicado a programas de idiomas fortran ou montagem escritos com muitos dados globais, onde mesmo entender quais declarações foram executadas era um trabalho duro ...com métodos pequenos e principalmente dados locais, é desnecessariamente conservador."

Acho uma função escrita com cláusulas de guarda muito mais fácil de seguir do que um longo grupo aninhado de if then else declarações.

Answer 7

Em uma função que não tem efeitos colaterais, não há um bom motivo para ter mais de um retorno e você deve escrevê-los em um estilo funcional.Em um método com efeitos colaterais, as coisas são mais sequenciais (indexadas no tempo), então você escreve em um estilo imperativo, usando a instrução return como um comando para interromper a execução.

Ou seja, quando possível, privilegie esse estilo

return a > 0 ?
  positively(a):
  negatively(a);

por cima disto

if (a > 0)
  return positively(a);
else
  return negatively(a);

Se você estiver escrevendo várias camadas de condições aninhadas, provavelmente há uma maneira de refatorar isso, usando a lista de predicados, por exemplo.Se você achar que seus ifs e elses estão sintaticamente distantes, você pode querer dividir isso em funções menores.Um bloco condicional que abrange mais do que uma tela cheia de texto é difícil de ler.

Não existe uma regra rígida e rápida que se aplique a todos os idiomas.Algo como ter uma única instrução de retorno não tornará seu código bom.Mas um bom código tenderá a permitir que você escreva suas funções dessa maneira.

Answer 8

Eu já vi isso em padrões de codificação para C++ que eram uma ressaca de C, como se você não tivesse RAII ou outro gerenciamento automático de memória, então você precisa limpar para cada retorno, o que significa recortar e colar da limpeza ou goto (logicamente o mesmo que 'finalmente' em linguagens gerenciadas), ambos considerados de má forma.Se suas práticas são usar ponteiros e coleções inteligentes em C++ ou outro sistema de memória automática, então não há uma razão forte para isso, e tudo se torna uma questão de legibilidade e mais uma decisão de julgamento.

Answer 9

Eu me inclino para a ideia de que declarações de retorno no meio da função são ruins.Você pode usar retornos para construir algumas cláusulas de guarda no topo da função e, claro, dizer ao compilador o que retornar no final da função sem problemas, mas retorna no meio da função pode ser fácil de perder e pode tornar a função mais difícil de interpretar.

Answer 10

Existem boas razões pelas quais é uma prática melhor ter apenas uma instrução de retorno em uma função?

Sim, há:

• O único ponto de saída oferece um excelente local para afirmar suas pós-condições.
• Ser capaz de colocar um ponto de interrupção do depurador no retorno no final da função geralmente é útil.
• Menos retornos significa menos complexidade.O código linear é geralmente mais simples de entender.
• Se tentar simplificar uma função para um único retorno causa complexidade, isso é um incentivo para refatorar para funções menores, mais gerais e mais fáceis de entender.
• Se você estiver em uma linguagem sem destruidores ou não usar RAII, um único retorno reduzirá o número de locais que você precisa limpar.
• Algumas linguagens requerem um único ponto de saída (por exemplo, Pascal e Eiffel).

A questão é frequentemente colocada como uma falsa dicotomia entre retornos múltiplos ou declarações if profundamente aninhadas.Quase sempre há uma terceira solução que é muito linear (sem aninhamento profundo) com apenas um único ponto de saída.

Atualizar:Aparentemente As diretrizes da MISRA promovem saída única, também.

Para ser claro, não estou dizendo que é sempre errado ter retornos múltiplos.Mas, dadas soluções equivalentes, há muitas boas razões para preferir aquela com retorno único.

Answer 11

Ter um único ponto de saída oferece uma vantagem na depuração, pois permite definir um único ponto de interrupção no final de uma função para ver qual valor realmente será retornado.

Answer 12

Em geral tento ter apenas um único ponto de saída de uma função.Há momentos, entretanto, em que isso acaba criando um corpo de função mais complexo do que o necessário; nesse caso, é melhor ter vários pontos de saída.Realmente tem que ser um “julgamento” baseado na complexidade resultante, mas o objetivo deve ser o menor número possível de pontos de saída, sem sacrificar a complexidade e a compreensão.

Answer 13

Não, porque não vivemos mais na década de 1970.Se sua função for longa o suficiente para que vários retornos sejam um problema, ela será muito longa.

(Além do fato de que qualquer função multilinha em uma linguagem com exceções terá vários pontos de saída de qualquer maneira.)

Answer 14

Minha preferência seria pela saída única, a menos que isso realmente complicasse as coisas.Descobri que, em alguns casos, vários pontos existentes podem mascarar outros problemas de design mais significativos:

public void DoStuff(Foo foo)
{
    if (foo == null) return;
}

Ao ver este código, eu perguntaria imediatamente:

• 'foo' é sempre nulo?
• Em caso afirmativo, quantos clientes de 'DoStuff' já chamaram a função com um 'foo' nulo?

Dependendo das respostas a estas perguntas, pode ser que

1. a verificação é inútil, pois nunca é verdadeira (ou seja,deveria ser uma afirmação)
2. a verificação raramente é verdadeira e, portanto, pode ser melhor alterar essas funções específicas do chamador, pois elas provavelmente deveriam realizar alguma outra ação de qualquer maneira.

Em ambos os casos acima, o código provavelmente pode ser retrabalhado com uma asserção para garantir que 'foo' nunca seja nulo e que os chamadores relevantes sejam alterados.

Existem duas outras razões (acho que específicas para o código C++) onde existem múltiplos podem realmente ter um negativo afetar.Eles são o tamanho do código e as otimizações do compilador.

Um objeto C++ não POD no escopo na saída de uma função terá seu destruidor chamado.Onde houver várias instruções de retorno, pode ser que existam objetos diferentes no escopo e, portanto, a lista de destruidores a serem chamados será diferente.O compilador, portanto, precisa gerar código para cada instrução de retorno:

void foo (int i, int j) {
  A a;
  if (i > 0) {
     B b;
     return ;   // Call dtor for 'b' followed by 'a'
  }
  if (i == j) {
     C c;
     B b;
     return ;   // Call dtor for 'b', 'c' and then 'a'
  }
  return 'a'    // Call dtor for 'a'
}

Se o tamanho do código for um problema, talvez valha a pena evitar isso.

O outro problema está relacionado à "Otimização do valor de retorno nomeado" (também conhecido como Copy Elision, ISO C++ '03 12.8/15).C++ permite que uma implementação ignore a chamada do construtor de cópia, se puder:

A foo () {
  A a1;
  // do something
  return a1;
}

void bar () {
  A a2 ( foo() );
}

Tomando o código como está, o objeto 'a1' é construído em 'foo' e então sua construção de cópia será chamada para construir 'a2'.No entanto, a elisão de cópia permite que o compilador construa 'a1' no mesmo lugar da pilha que 'a2'.Portanto, não há necessidade de "copiar" o objeto quando a função retornar.

Vários pontos de saída complicam o trabalho do compilador na tentativa de detectar isso, e pelo menos para uma versão relativamente recente do VC++ a otimização não ocorreu onde o corpo da função tinha múltiplos retornos.Ver Otimização de valor de retorno nomeado no Visual C++ 2005 para mais detalhes.

Answer 15

Ter um único ponto de saída reduz Complexidade ciclomática e, portanto, em teoria, reduz a probabilidade de você introduzir bugs em seu código ao alterá-lo.A prática, contudo, tende a sugerir que é necessária uma abordagem mais pragmática.Portanto, tendo como objetivo ter um único ponto de saída, mas permito que meu código tenha vários, se isso for mais legível.

Answer 16

Eu me forço a usar apenas um return declaração, pois de certa forma gerará cheiro de código.Deixe-me explicar:

function isCorrect($param1, $param2, $param3) {
    $toret = false;
    if ($param1 != $param2) {
        if ($param1 == ($param3 * 2)) {
            if ($param2 == ($param3 / 3)) {
                $toret = true;
            } else {
                $error = 'Error 3';
            }
        } else {
            $error = 'Error 2';
        }
    } else {
        $error = 'Error 1';
    }
    return $toret;
}

(As condições são arbitrárias...)

Quanto mais condições, maior fica a função e mais difícil é de ler.Portanto, se você estiver atento ao cheiro do código, perceberá isso e desejará refatorá-lo.Duas soluções possíveis são:

• Devoluções múltiplas
• Refatorando em funções separadas

Múltiplas Devoluções

function isCorrect($param1, $param2, $param3) {
    if ($param1 == $param2)       { $error = 'Error 1'; return false; }
    if ($param1 != ($param3 * 2)) { $error = 'Error 2'; return false; }
    if ($param2 != ($param3 / 3)) { $error = 'Error 3'; return false; }
    return true;
}

Funções Separadas

function isEqual($param1, $param2) {
    return $param1 == $param2;
}

function isDouble($param1, $param2) {
    return $param1 == ($param2 * 2);
}

function isThird($param1, $param2) {
    return $param1 == ($param2 / 3);
}

function isCorrect($param1, $param2, $param3) {
    return !isEqual($param1, $param2)
        && isDouble($param1, $param3)
        && isThird($param2, $param3);
}

É verdade que é mais longo e um pouco confuso, mas no processo de refatorar a função dessa forma,

• criou uma série de funções reutilizáveis,
• tornou a função mais legível para humanos e
• o foco das funções está no motivo pelo qual os valores estão corretos.

Answer 17

Eu diria que você deve ter quantos forem necessários, ou qualquer um que torne o código mais limpo (como cláusulas de guarda).

Pessoalmente, nunca ouvi/vi nenhuma "prática recomendada" dizer que você deveria ter apenas uma declaração de retorno.

Na maioria das vezes, tendo a sair de uma função o mais rápido possível com base em um caminho lógico (as cláusulas de guarda são um excelente exemplo disso).

Answer 18

Acredito que retornos múltiplos costumam ser bons (no código que escrevo em C#).O estilo de retorno único é um resquício de C.Mas você provavelmente não está codificando em C.

Não existe nenhuma lei que exija apenas um ponto de saída para um método em todas as linguagens de programação.Algumas pessoas insistem na superioridade deste estilo, e por vezes elevam-no a uma “regra” ou “lei”, mas esta crença não é apoiada por qualquer evidência ou investigação.

Mais de um estilo de retorno pode ser um mau hábito no código C, onde os recursos precisam ser explicitamente desalocados, mas linguagens como Java, C#, Python ou JavaScript que possuem construções como coleta automática de lixo e try..finally blocos (e using blocos em C#), e esse argumento não se aplica - nessas linguagens, é muito incomum precisar de desalocação manual centralizada de recursos.

Há casos em que um único retorno é mais legível e casos em que não é.Veja se reduz o número de linhas de código, deixa a lógica mais clara ou reduz o número de colchetes e recuos ou variáveis ​​temporárias.

Portanto, use quantos retornos forem adequados à sua sensibilidade artística, pois é uma questão de layout e legibilidade, não técnica.

eu falei sobre isso mais detalhadamente no meu blog.

Answer 19

Há coisas boas a dizer sobre ter um único ponto de saída, assim como há coisas ruins a dizer sobre o inevitável "seta" programação que resulta.

Se estiver usando vários pontos de saída durante a validação de entrada ou alocação de recursos, tento colocar todas as 'saídas de erro' de forma bem visível no topo da função.

Tanto o Programação Espartana artigo da "SSDSLPedia" e o ponto de saída de função única artigo do "Wiki do Portland Pattern Repository" tem alguns argumentos perspicazes sobre isso.Além disso, é claro, há esta postagem a ser considerada.

Se você realmente deseja um único ponto de saída (em qualquer linguagem sem exceção), por exemplo, para liberar recursos em um único local, acho que a aplicação cuidadosa de goto é boa;veja, por exemplo, este exemplo bastante inventado (compactado para economizar espaço na tela):

int f(int y) {
    int value = -1;
    void *data = NULL;

    if (y < 0)
        goto clean;

    if ((data = malloc(123)) == NULL)
        goto clean;

    /* More code */

    value = 1;
clean:
   free(data);
   return value;
}

Pessoalmente, em geral, não gosto mais de programar com setas do que de vários pontos de saída, embora ambos sejam úteis quando aplicados corretamente.O melhor, claro, é estruturar seu programa para não exigir nenhum dos dois.Dividir sua função em vários pedaços geralmente ajuda :)

Embora, ao fazer isso, acabe com vários pontos de saída, como neste exemplo, onde alguma função maior foi dividida em várias funções menores:

int g(int y) {
  value = 0;

  if ((value = g0(y, value)) == -1)
    return -1;

  if ((value = g1(y, value)) == -1)
    return -1;

  return g2(y, value);
}

Dependendo do projeto ou das diretrizes de codificação, a maior parte do código padrão pode ser substituída por macros.Como observação lateral, dividir dessa forma torna as funções g0, g1, g2 muito fáceis de testar individualmente.

Obviamente, em uma linguagem OO e habilitada para exceções, eu não usaria instruções if como essa (ou mesmo, se pudesse me safar com pouco esforço), e o código seria muito mais simples.E não-flecha.E a maioria dos retornos não finais provavelmente seriam exceções.

Resumidamente;

• Poucos retornos são melhores do que muitos retornos
• Mais de um retorno é melhor do que flechas enormes, e cláusulas de guarda geralmente estão bem.
• As exceções provavelmente poderiam/deveriam substituir a maioria das 'cláusulas de proteção' quando possível.

Answer 20

Você conhece o ditado - a beleza está nos olhos de quem vê.

Algumas pessoas juram NetBeans e alguns por IDEIA do IntelliJ, alguns por Pitão e alguns por PHP.

Em algumas lojas você poderá perder seu emprego se insistir em fazer isso:

public void hello()
{
   if (....)
   {
      ....
   }
}

A questão é toda sobre visibilidade e manutenção.

Sou viciado em usar álgebra booleana para reduzir e simplificar a lógica e o uso de máquinas de estado.No entanto, houve colegas anteriores que acreditaram que meu emprego de "técnicas matemáticas" na codificação era inadequado, porque não seria visível e sustentável.E isso seria uma má prática.Desculpe pessoal, as técnicas que utilizo são muito visíveis e fáceis de manter para mim - porque quando eu retornar ao código seis meses depois, eu entenderia o código claramente, em vez de ver uma bagunça de espaguete proverbial.

Ei amigo (como dizia um ex-cliente) faça o que quiser desde que saiba como consertar quando eu precisar que você conserte.

Lembro-me que há 20 anos um colega meu foi despedido por empregar o que hoje se chamaria desenvolvimento ágil estratégia.Ele tinha um plano incremental meticuloso.Mas seu gerente estava gritando com ele: "Você não pode liberar recursos de forma incremental para os usuários!Você deve ficar com o cachoeira." Sua resposta ao gerente foi que o desenvolvimento incremental seria mais preciso para as necessidades do cliente.Ele acreditava no desenvolvimento para as necessidades do cliente, mas o gerente acreditava na codificação de acordo com as "necessidades do cliente".

Freqüentemente somos culpados por quebrar a normalização de dados, MVP e MVC limites.Nós inline em vez de construir uma função.Pegamos atalhos.

Pessoalmente, acredito que PHP é uma prática ruim, mas o que eu sei?Todos os argumentos teóricos se resumem a tentar cumprir um conjunto de regras

Qualidade = precisão, manutenção e lucratividade.

Todas as outras regras ficam em segundo plano.E é claro que esta regra nunca desaparece:

A preguiça é a virtude de um bom programador.

Answer 21

Eu me inclino a usar cláusulas de guarda para retornar mais cedo e sair no final de um método.A regra de entrada e saída única tem significado histórico e foi particularmente útil ao lidar com código legado que ocupava 10 páginas A4 para um único método C++ com vários retornos (e muitos defeitos).Mais recentemente, uma boa prática aceita é manter os métodos pequenos, o que torna as saídas múltiplas uma impedância menor para a compreensão.No seguinte exemplo de Kronoz copiado acima, a questão é o que ocorre em //Resto do código...?:

void string fooBar(string s, int? i) {

  if(string.IsNullOrEmpty(s) || i == null) return null;

  var res = someFunction(s, i);

  foreach(var r in res) {
      if(!r.Passed) return null;
  }

  // Rest of code...

  return ret;
}

Sei que o exemplo é um tanto artificial, mas ficaria tentado a refatorar o para cada faça um loop em uma instrução LINQ que poderia então ser considerada uma cláusula de guarda.Novamente, em um exemplo inventado, a intenção do código não é aparente e algumaFunção() pode ter algum outro efeito colateral ou o resultado pode ser usado no // Resto do código....

if (string.IsNullOrEmpty(s) || i == null) return null;
if (someFunction(s, i).Any(r => !r.Passed)) return null;

Dando a seguinte função refatorada:

void string fooBar(string s, int? i) {

  if (string.IsNullOrEmpty(s) || i == null) return null;
  if (someFunction(s, i).Any(r => !r.Passed)) return null;

  // Rest of code...

  return ret;
}

Answer 22

Um bom motivo que consigo pensar é para manutenção de código:você tem um único ponto de saída.Se você quiser alterar o formato do resultado,..., é muito mais simples de implementar.Além disso, para depuração, você pode simplesmente colocar um ponto de interrupção lá :)

Dito isto, uma vez tive que trabalhar em uma biblioteca onde os padrões de codificação impunham 'uma instrução de retorno por função', e achei isso muito difícil.Eu escrevo muitos códigos de cálculos numéricos e muitas vezes há 'casos especiais', então o código acabou sendo bastante difícil de seguir...

Answer 23

Vários pontos de saída são adequados para funções pequenas o suficiente - ou seja, uma função que pode ser visualizada inteira em uma tela.Se uma função longa também incluir vários pontos de saída, é um sinal de que a função pode ser ainda mais dividida.

Dito isto, evito funções de saída múltipla a menos que seja absolutamente necessário.Tenho sentido dor com bugs devido a algum retorno perdido em alguma linha obscura em funções mais complexas.

Answer 24

Eu trabalhei com padrões de codificação terríveis que forçaram você a ter um único caminho de saída e o resultado é quase sempre um espaguete não estruturado se a função for tudo menos trivial - você acaba com muitas interrupções e continuações que apenas atrapalham.

Answer 25

Um único ponto de saída - todas as outras coisas iguais - torna o código significativamente mais legível.Mas há um problema:construção popular

resulttype res;
if if if...
return res;

é falso, "res=" não é muito melhor que "return".Possui uma única instrução de retorno, mas vários pontos onde a função realmente termina.

Se você tiver uma função com vários retornos (ou "res="s), geralmente é uma boa ideia dividi-la em várias funções menores com um único ponto de saída.

Answer 26

Minha política usual é ter apenas uma instrução de retorno no final de uma função, a menos que a complexidade do código seja bastante reduzida pela adição de mais.Na verdade, sou um fã de Eiffel, que impõe a única regra de retorno por não ter nenhuma instrução de retorno (há apenas uma variável de 'resultado' criada automaticamente para inserir seu resultado).

Certamente há casos em que o código pode ficar mais claro com vários retornos do que seria a versão óbvia sem eles.Alguém poderia argumentar que é necessário mais retrabalho se você tiver uma função que é muito complexa para ser compreensível sem múltiplas declarações de retorno, mas às vezes é bom ser pragmático sobre essas coisas.

Answer 27

Se você tiver mais do que algumas devoluções, pode haver algo errado com seu código.Caso contrário, eu concordaria que às vezes é bom poder retornar de vários lugares em uma sub-rotina, especialmente quando isso torna o código mais limpo.

Perl 6:Mau exemplo

sub Int_to_String( Int i ){
  given( i ){
    when 0 { return "zero" }
    when 1 { return "one" }
    when 2 { return "two" }
    when 3 { return "three" }
    when 4 { return "four" }
    ...
    default { return undef }
  }
}

seria melhor escrito assim

Perl 6:Bom exemplo

@Int_to_String = qw{
  zero
  one
  two
  three
  four
  ...
}
sub Int_to_String( Int i ){
  return undef if i < 0;
  return undef unless i < @Int_to_String.length;
  return @Int_to_String[i]
}

Observe que este foi apenas um exemplo rápido

Answer 28

Eu voto no retorno único no final como diretriz.Isso ajuda um manipulação comum de limpeza de código ...Por exemplo, dê uma olhada no código a seguir ...

void ProcessMyFile (char *szFileName)
{
   FILE *fp = NULL;
   char *pbyBuffer = NULL:

   do {

      fp = fopen (szFileName, "r");

      if (NULL == fp) {

         break;
      }

      pbyBuffer = malloc (__SOME__SIZE___);

      if (NULL == pbyBuffer) {

         break;
      }

      /*** Do some processing with file ***/

   } while (0);

   if (pbyBuffer) {

      free (pbyBuffer);
   }

   if (fp) {

      fclose (fp);
   }
}

Answer 29

Esta é provavelmente uma perspectiva incomum, mas acho que qualquer pessoa que acredite que múltiplas instruções de retorno devem ser favorecidas nunca teve que usar um depurador em um microprocessador que suporta apenas 4 pontos de interrupção de hardware.;-)

Embora os problemas de "código de seta" estejam completamente corretos, um problema que parece desaparecer ao usar várias instruções de retorno é na situação em que você está usando um depurador.Você não tem uma posição conveniente para colocar um ponto de interrupção para garantir que verá a saída e, portanto, a condição de retorno.

Answer 30

Quanto mais instruções de retorno você tiver em uma função, maior será a complexidade desse método.Se você está se perguntando se tem muitas instruções de retorno, você pode querer se perguntar se tem muitas linhas de código nessa função.

Mas não, não há nada de errado com uma/muitas declarações de retorno.Em algumas linguagens, é uma prática melhor (C++) do que em outras (C).