É uma boa prática nomear a variável retornada “result”? [fechadas]

Se esta é uma variável de método, realmente depende da legibilidade.

Vendo que você já tem o nome do tipo na declaração de variável e no tipo de retorno do método, você pode usar também result - é descritivo da função da variável.

A leitura cruzada é facilitada se a variável receber o nome result . Isso deixa sua intenção clara.

Se eu preciso de uma variável de retorno (o que na verdade acontece raramente), eu sempre chamo de ret e sempre o defino logo abaixo da cabeça de função. A função já tem um nome, que diz tudo sobre o que retorna.

Se eu tiver myFunction I poderia nomear a variável de retorno myFunctionReturnValue para dizer exatamente a mesma coisa, só eu teria que dizê-lo explicitamente todas as vezes. Como as funções geralmente devem ser curtas, não há necessidade de tal explicitação. E mesmo se eu perder a noção, eu posso pular para a declaração e pousar logo abaixo da definição da função.

Mas qualquer outro nome, que não implicitamente (como ret ou result ) ou explicitamente (como myFunctionReturnValue ou myFunctionResult ), que esta é a variável de retorno de funções atual, é muito genérico.

No seu segundo exemplo, zorglub é uma escolha terrível. Tudo o que a declaração realmente me diz é que você criou uma variável, cujo nome é igual à anotação de tipo encontrada ao lado do nome. É tão útil quanto int someInt ou Zorglub z .

No seu primeiro exemplo, quando olho para o código, vejo primeiro o nome da função, que me diz, que esta função calcula um Zorglub . Enquanto eu leio a segunda linha, vejo "ok, aqui está o zorglub, que será retornado, mas evidentemente não pode ser retornado imediatamente e, portanto, é armazenado na variável result " (como uma observação: Se você não vai reatribuir o valor, então é melhor declarar a variável final para comunicar isso), e então eu penso "então agora vamos ver o que acontece antes que seja retornado". Ao contrário do primeiro exemplo, eu não preciso realmente ler mais do que isso para saber que isso é a variável, que será retornada e que eu quero seguir no corpo da função se eu quiser para entender isso.

Você pode querer ler a Programação Spartan , que é mais relacionada a sua pergunta.

No seu segundo exemplo, você está combinando o tipo do resultado com o que é .

Zorglub zorglub;

apenas me diz que é um Zorglub duas vezes. Três vezes se me incomodo em ler o tipo de retorno do método. No entanto,

double variance;

por exemplo, me dá uma pista sobre o que o valor de retorno significa , em termos de semântica de programa. Pode ou não ser mais claro do que apenas chamá-lo de result , dependendo do tamanho do método - isso é uma avaliação para cada método IMO.

Se você jogar com muitos objetos Zorglub em seus métodos, "poderá" cometer um erro e retornar o errado, ou / e poderá ser tentado a nomear os outros zorglub1 , zorglub2 , etc.

Se você nomear result , não há chance de cometer um erro como esse. Além disso, acho que é um bom nome; Eu também vi returnedValue ou returnedObject várias vezes, também está claro, embora um pouco longo.

Pessoalmente, não me sinto completamente confortável usando result como nome de variável. É justo, isso me diz que o valor associado é o resultado de alguma computação - no entanto, eu acho que é verdade para cerca de (ou mais) 90% das variáveis / campos usados em um programa.

Além disso, como várias outras respostas notaram, ele pode ser usado para marcar o valor a ser retornado de um método / função. No entanto, se mantiver meus métodos curtos, focados em fazer apenas uma coisa e permanecer consistentemente em um único nível de abstração, não terei muitas variáveis locais e será trivial ver o que um método retornará.

Portanto, prefiro manter meus métodos curtos e limpos e nomear minhas variáveis para expressar o significado do valor que possuem, em vez de sua função local dentro do método de inclusão. No entanto, (por exemplo, no código legado) Zorglub result certamente pode ser mais fácil de entender do que Zorglub zorglub .

Eu pessoalmente uso o nome result para o valor a ser retornado da função / método. Isso explicita que é o valor a ser retornado. Nomeando-o por tipo não parece útil, porque pode haver mais de uma variável do mesmo tipo.

Qual é a diferença? são apenas duas palavras diferentes lá que farão a mesma coisa, então o problema real é qual soa mais claro para você?

O "resultado" ou "zorglub".

Eu preferiria usar ZorglubResult para um iniciante para ver que o resultado retorna de Zorglub mais fácil de comparar com outros resultados que você possa ter e seu resultado como você pode ver ..

should I name it by its type?

Não. Nunca. Isso é chamado de sistemas húngaros e é trivialmente ultrapassado pela idéia de usar um programa que pode exibir o tipo de qualquer variável sempre que precisar.

Sempre que você precisar nomear qualquer coisa no código, você deve fornecer nomes que sejam descritivos, significativos e legíveis. O caso de uma variável de retorno é um exemplo particularmente bom de onde as pessoas tendem a se tornar complacentes com relação à nomenclatura.

Se você tem uma função claramente nomeada e precisa apenas de uma única linha de código, pode ignorar completamente a nomeação. Tornar os seus métodos curtos e únicos é sempre o ideal que você deve estar procurando. No entanto, é o caso que às vezes você precisa concluir uma função com várias linhas de código. Nesses casos, é sempre aconselhável nomear sua variável para corresponder ao propósito de sua função.

Se o propósito da função é retornar o resultado de um cálculo ou um algoritmo de decisão, então result é um nome perfeitamente adequado para sua variável usar, mas e se sua função estiver retornando um item de uma lista? E se sua função estiver servindo a algum outro propósito que não tenha nada a ver com matemática ou listas? Nesses casos, é melhor fornecer à variável um nome significativo relacionado ao motivo pelo qual a função foi criada. Claro, você poderia simplesmente usar o resultado se quisesse, porque é um nome que provavelmente não colidirá com qualquer outra coisa, no entanto, de uma perspectiva de legibilidade, faz mais sentido nomear sua variável de forma mais significativa e contextualizada.

Eu gosto de combiná-los, mostra o que é e que deve ser devolvido.

então, no seu exemplo, seria resultadoZorglub

se o que é realmente não importa do que seria apenas resultado (não resultString)

Eu não vejo muita diferença entre definir um valor de retorno em algum ponto e, em seguida, usar condicionais para pular todo o código que possa modificá-lo, e return ing imediatamente, então vou para o retorno direto, Portanto, não há result variável.

Se você tem um valor intermediário que pode ou não ser alterado por código condicional, então não é um resultado (ainda), então certamente não deve ser nomeado assim.

Quando eu estava trabalhando em C ++ e acho que isso pode ser aplicado em Java.

por exemplo,

int Width() const
{
    Requires(....);
    Requires(....);

    //calculation

    Ensures(...);
    Ensures(...);
    return Result;
}

Isso é design por contrato, já que o bloco de garantia deve estar no final do método. Mas o retorno deve ser o último. Tivemos a regra que retornou O resultado foi a única coisa que poderia seguir o bloco de garantia.

Em uma função recursiva, muitas vezes é eficaz levar o resultado de um passo para o outro, para fazer uma otimização de chamada final. Para sinalizar ao usuário, que ele não precisa fornecer um parâmetro, pode ser razoável nomear um parâmetro "resultado":

def removeOccurence [A] (slice: Seq[A], original: Seq[A]) = {
  @scala.annotation.tailrec
  def remove (leftOriginal: Seq[A], result: Seq[A]) : Seq[A] =
    trimStart (slice, leftOriginal) match {
      case (h :: tail) => remove (tail, h +: result)
      case (Nil)       => result.reverse
    }
    remove (original, Nil)
}

Mas mais frequentemente eu uso 'carry' e 'sofar', que eu vi na natureza, e que levam a idéia até um pouco melhor, na maioria dos casos.

Uma segunda razão é claro, se o seu tópico sugerir a palavra '' resultado '', por exemplo, se você fizer uma avaliação aritmética. Você pode analisar a fórmula, substituir variáveis por valores e calcular um resultado no final.

Uma terceira razão já foi declarada, mas eu tenho um pequeno desvio: você escreve um método que executa algum trabalho, digamos que ele avalia uma forma de '' max ''.

def max = {
  val result = somethingElseToDo
  if (foo) result else default 
}

Em vez de chamar o resultado '' result '', poderíamos chamar de '' max '', mas em alguns idiomas você pode omitir parênteses ao chamar um método, então max seria uma chamada recursiva para o método em si.

Em geral, eu preferiria um nome que informa, qual é o resultado. Mas se esse nome já for usado, talvez por mais de uma variável, atributo ou método, porque existe um campo GUI, uma representação de string, uma numérica e outra para o banco de dados, usando outra aumenta a probabilidade de confusão. Em métodos curtos de 3 a 7 linhas, "resultado" não deve ser um problema para um nome.

No Object Pascal isso não é uma escolha. Você tem que atribuir um valor para a variável Result em algum lugar no código da função.

Exemplo:

function AddIntegers( A,B: Integer): Integer;
begin
  Result := A + B; 
end; 

Portanto, para mim é bastante natural ter uma variável "Resultado" (ou "Retorno", como eu soletro em português para evitar conflito de nomes com palavras reservadas da linguagem) para receber um valor de retorno.

De couse, se for uma expressão muito simples em uma linguagem derivada de C, não me preocuparei em declarar uma variável de resultado - retornando a expressão diretamente.

não é apenas o que você nomeia o resultado (eu sou especial para 'r'), mas também como é usado. Por exemplo, se você tiver uma variável de retorno, todas as instruções de retorno devem retorná-la. não tem 'return r;' no final, mas polvilhe coisas como 'return m * x + b;' através do método / função. use "r = m * x + b; return r; "em vez disso.

o resultado é bom. Eu sou capaz de entender o código à primeira vista, então o nome da variável serviu ao propósito.