Não especificando um retorno em uma função, bom ou ruim?

4

Eu codifiquei assim muitas vezes, e nunca encontrei um problema, mas o compilador sempre avisa quando espera um retorno e não há nenhum.

Por exemplo, veja isto:

-(NSString *)outputStringForInteger:(NSInteger)int
{
    if (int == 0)
    {
        return @"Number is Zero";
    }
    else
    {
        return @"Number is not Zero";
    }
    //no "failsafe" or other explicit return
}

Se a função nunca chegará à última linha, é importante ainda ter uma opção à prova de falhas, ou vocês apenas lidam com os avisos do compilador?

    
por Justin 01.11.2010 / 19:35
fonte

7 respostas

22

Obtenha um compilador melhor. As que eu uso reclamam que você tem código que nunca será executado se você colocar o retorno "à prova de falhas" lá. Esse é um aviso muito melhor que o falso que você está aparentemente vendo.

    
por 01.11.2010 / 19:41
fonte
6

Não sei em que idioma você está, por isso vou usar o Java no meu exemplo.

String outputStringForInteger(int i) {
   String returnString = "Number is not Zero";

   if (i == 0)
      returnString = "Number is Zero";

   return returnString;
}

Isso fornecerá um valor de retorno "padrão", além de ser mais legível (IMO).

    
por 01.11.2010 / 19:52
fonte
4

Em C:

String outputStringForInteger(int i) {
   return (i == 0) ? "Number is Zero" : "Number is not Zero";
}

Se você insiste que o operador ternário é uma invenção do Diabo, como alguns fazem:

String outputStringForInteger(int i) {
   String returnString;

   if (i == 0) {
      returnString = "Number is Zero";
   } else {
      returnString = "Number is not Zero";
   }
   return returnString;
}
    
por 01.11.2010 / 20:38
fonte
2

Eu prefiro não ter vários retornos em uma função.

    
por 01.11.2010 / 20:09
fonte
1

Desde que você tenha coberto todos os caminhos de código possíveis, você está bem.

Se o seu compilador está reclamando, há duas possibilidades:
1) Você acha que cobriu tudo e não fez. 2) Seu compilador está com morte cerebral.

Dito isso, é bem provável que você possa reestruturar o código para aplacar o compilador e ainda cobrir os caminhos de código. (por exemplo, solte o else em seu exemplo)

    
por 02.11.2010 / 16:34
fonte
1

Que tal isso (Java - não sei a linguagem do OP)?

String outputStringForInteger(int i)
{

   if (i == 0)
      return "Number is Zero";

   return "Number is not Zero";
}
    
por 02.11.2010 / 16:52
fonte
1

Em D, exceto em alguns casos triviais onde o compilador pode provar estaticamente que o fim da função é inacessível sem uma declaração de retorno sendo executada ou uma exceção sendo lançada, você deve colocar um declaração de retorno, uma instrução throw ou assert(0) no final da função. Em outras linguagens eu acho que esta é geralmente uma boa prática, embora não necessariamente em casos como o seu exemplo, onde um leitor poderia trivial e estaticamente dizer que o fim da função é inacessível e um compilador decente deve ser capaz de provar isso.

Você não deve ter um valor de retorno padrão que acredita ser inacessível. Se algum dia ele for usado, seu código estará, por definição, em um estado para o qual você nunca pretendeu que estivesse. Um assert(0) transmite suas intenções tanto para o leitor quanto para o compilador muito melhor.

    
por 01.11.2010 / 21:08
fonte