É uma boa prática nomear a variável retornada como "resultado"? [fechadas]


44

É uma boa prática chamar a variável que um método retorna com um nome de variável result?

Por exemplo:

public Zorglub calculate() {
    Zorglub result = [...]
    [...]
    return result;
}

Ou devo nomeá-lo por seu tipo?

public Zorglub calculate() {
    Zorglub zorglub = [...]
    [...]
    return zorglub;
}

Eu já vi ambos na natureza, se eu precisar escolher um, por que razões poderia me fazer preferir o primeiro ou o último (ou qualquer nome melhor)?

Estou pensando principalmente em Java.


73
Eu também vi ofTheJediusado para esse fim. Não é uma recomendação, apenas dizendo que eu já vi. Zorglub ofTheJedi = //...; return ofTheJedi;

7
Eu costumo chamá-lo de "retval" (valor para retornar), mas isso é mais ou menos a mesma coisa que "resultado", no qual eu votaria.
Zeta Two

5
Todo mundo tem uma resposta diferente, todos são semelhantes, mas diferentes e válidos, a pergunta não é voluntariamente subjetiva, mas as respostas são. É mais uma enquete.
ZJR

16
Eu diria que "resultado" como uma variável é bom, mas "calcular" como uma função não é absolutamente.
Kaz Dragon

2
Você trabalha com muitos ex-programadores Delphi?
22812 Peter Turner

Respostas:


48

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

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


40

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


2
+1 Este é o ponto principal. Eu sei o que significa resultado em qualquer contexto apenas olhando para o código.
Xeoncross

1
Eu concordo, usar o tipo de variável não ajuda a entender que você vai devolvê-lo. Nestes exemplos simples, é mais fácil ver o retorno sem rolagem ou aparência, mas é mais rápido saber antecipadamente qual é o valor retornado da função. Também é importante inicializá-lo, como feito no exemplo.
Nycynik

17

Se eu precisar de uma variável de retorno (o que realmente acontece raramente), eu sempre a chamo rete sempre a defino logo abaixo do cabeçalho da função. A função já tem um nome, que diz tudo sobre o que retorna.

Se eu tivesse myFunction, poderia nomear sua variável de retorno myFunctionReturnValuepara dizer exatamente a mesma coisa, apenas 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 o controle, posso pular para a declaração e aterrissar logo abaixo da definição da função.

Mas qualquer outro nome, que não indique implicitamente (como retou result) ou explicitamente (como myFunctionReturnValueou myFunctionResult), que essa é a variável de retorno das funções atuais é muito genérico.

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

No seu primeiro exemplo, quando olho para o código, vejo pela primeira vez o nome da função, que me diz que essa função calcula a Zorglub. Ao ler a segunda linha, vejo "ok, aqui está o zorglub, que será retornado, mas evidentemente não pode ser retornado imediatamente e, portanto, é armazenado na resultvariável" (como uma observação: se você estiver não vai reatribuir o valor, então é melhor você declarar a variável final para comunicar isso) e, em seguida, penso "agora vamos ver o que acontece antes que seja retornado". Diferentemente do primeiro exemplo, não preciso ler mais nada além disso para saber que essa é a variável, que será retornada e que eu quero seguir no corpo da função se quiser entendê-la.

Você pode ler sobre a programação Spartan , que está bastante relacionada à sua pergunta.


8
+1 para "zorglub é uma péssima escolha". Não há razão terrena para ter um nome de variável, em qualquer contexto, que seja idêntico ao nome do tipo (menos o capital inicial). A declaração informa o tipo da variável - nomear sua variável após o seu tipo não é melhor do que chamar suas variáveis ​​x1, x2, x3 e assim por diante. O nome de qualquer variável deve expressar para que serve a variável ou o que ela faz. Meu nome preferido para uma variável nesse caso específico é toReturn - porque a variável faz referência ao objeto a ser retornado. De fato, muitos dos meus nomes de variáveis ​​começam com "para".
Dawood diz que restabelece Monica

21
@ DavidWallace - isso é muito forte de um absoluto. Eu tenho uma turma chamada Container. Se eu tenho um método que modifica a quantidade, posso dizer var container = getContainer(id); container.Quantity += 1; que certamente é legível se o contexto do método operar apenas em um único contêiner, e isso é tudo o que faz. Chamar isso theContainerWeAreGoingToAdjustTheQuantityOfé simplesmente ridículo.
Scott Whitlock

4
@ David, eu discordo. Vamos assumir uma situação em que você tem várias variáveis ​​locais, cada uma de um tipo diferente (digamos Usuário, Gerente e Departamento). E suponha que a tarefa seja vincular o usuário ao departamento e à equipe do gerente. IMHO é perfeitamente OK para chamar essa instância usuário simplesmente user(em oposição a userToJoinThisDepartmentAndManagerOu o que seria a sua escolha?)
Péter Török

10
Nitpick menor: odeio ver "ret" ou "rv" ou outras variantes abreviadas de result / returnValue. "result" não é muito longo e ninguém precisa conservar caracteres.
21412 Kristopher Johnson

2
@KristopherJohnson: "resultado" não é muito longo, mas também não significa "valor de retorno". Valores de retorno nem sempre são resultados de cálculos e, inversamente, resultados de cálculos nem sempre são valores de retorno. Suponho que você possa nomear seu valor de retorno returnValue, mas reté tradicional, assim como inte char.
Ruakh

12

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

Zorglub zorglub;

só me diz que é um Zorglub, duas vezes. Três vezes se eu me preocupo em ler o tipo de retorno do método. Contudo,

double variance;

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


8

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

Se você escolher result, não há nenhuma chance de cometer um erro como esse. Além disso, acho que esse é um bom nome; Eu também vi returnedValueou returnedObjectvárias vezes, também é clara, embora um pouco demorado.


5

Pessoalmente, não me sinto totalmente confortável usando resultcomo nome de variável. É justo dizer que o valor associado é o resultado de alguns cálculos - no entanto, acho que isso é verdade para cerca de (ou mais) 90% das variáveis ​​/ campos usados ​​em um programa.

Além disso, como várias outras respostas observadas, ele pode ser usado para marcar o valor a ser retornado de um método / função. No entanto, se eu manter 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 elas possuem, em vez de sua função local dentro do método envolvente. No entanto, (por exemplo, no código legado) Zorglub resultpode certamente ser mais fácil de entender do que Zorglub zorglub.


12
Não é chamado resultporque é o resultado de alguma computação; é chamado resultporque é o resultado desse cálculo. Isso também funciona como seu significado IMO, mesmo que não seja o significado mais específico possível. Expressar significado é de ouro, mas a intenção e os idiomas também podem ser valiosos. Nesse caso, é uma espécie de troca.
Supr

@Supr: Que nome você usaria para descrever o resultado de alguma outra computação, que será usada apenas na próxima declaração ou duas (por exemplo if (result >= 0) numChars+=result; else break;, e cujo significado será óbvio na computação em questão?) Na minha opinião, o valor que vai ser devolvido a partir desta função deve ser chamada ret, enquanto o valor que foi retornado da última função chamada deve ser result. Observe que resultpode ser mais significativo que um nome mais longo se o valor de retorno da função puder, por exemplo, representar uma quantidade ou um código de erro.
11123 supercat

@ supercat, eu o nomearia com base no que era a computação ou no que o valor se destina a ser usado. Mesmo que seja usado apenas no próximo cálculo, ainda ajuda a legibilidade se for bem nomeado. No seu exemplo, não tenho idéia de qual é o significado resultou o que o código realmente faz em um nível superior. Eu teria que me referir a onde ele está definido para ver de onde vem seu valor e qual é. Algo como addedCharsou matchedCharsseria mais transparente e ajudar a revelar o que o código está fazendo, e não requerem mentalmente malabarismo esta e as respectivas result = ...:)
Supr

@ Supr: O problema é que, em muitos casos, diferentes faixas de valores de retorno podem significar coisas diferentes. Por exemplo, uma rotina para ler um pacote em um buffer de tamanho especificado pode retornar um número de bytes se um pacote foi recebido ou um número negativo para indicar que um pacote estava (e ainda está) pendente demais para o buffer, ou um número negativo muito grande para indicar algum outro erro. Armazenar o retorno resulte depois compará-lo com esses critérios pareceria mais natural do que tentar criar um nome descritivo que cubra todos eles.
22712

@ Supercat, usando em retvez de resultparece bem por mim. É um pouco menos claro na minha opinião, porque é abreviado e não como substantivo, mas se for usado de forma consistente, será equivalente a result.
Supr

1

Eu pessoalmente uso o nome resultdo valor a ser retornado da função / método. Torna explícito que é o valor a ser retornado. Nomear por tipo não parece útil, pois pode haver mais de uma variável desse mesmo tipo.


Uhm, certamente o fato de dizer 'retornar' antes de retornar é explícito o suficiente? Você deve descrever o que fará com ele, agora o 'como'. Por que não chamá-lo totais, resultado, ou algo mais descritivo do propósito, então seu código estará pronto "retorno total" ou similar ...
Dave

@Dave Não é necessário, especialmente se você tiver alguns objetos do mesmo tipo que podem ser devolvidos, o objetivo do método é descobrir qual é o correto a ser retornado.
1013 Andy

@ Andy, entendo seu ponto de vista, mas, na realidade, não consigo imaginar escrever uma função como essa. Se esse é o motivo para escrever uma função como essa, parece que ela deve ser dividida em funções menores e mais compreensíveis.
10242 Dave

1

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

O "resultado" ou "zorglub".

Eu preferiria usar ZorglubResultpara iniciantes para ver que o resultado é Zorglub mais fácil de comparar com outros resultados que você pode ter e é um resultado como você pode ver.


1

devo nomeá-lo por seu tipo?

Não nunca. Isso se chama Systems Hungarian e é trivialmente desatualizado pela idéia de usar um programa que pode exibir o tipo de qualquer variável a qualquer momento que você precisar.


1

Sempre que precisar nomear algo no código, forneça nomes 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 a nomeação.

Se você tiver uma função claramente nomeada e precisar apenas de uma única linha de código, poderá ignorar completamente a nomeação. Tornar seus métodos objetivos curtos e únicos é sempre o ideal que você deve buscar. Entretanto, às vezes é necessário concluir uma função com várias linhas de código. Nesses casos, é sempre aconselhável nomear sua variável para corresponder ao objetivo de sua função.

Se o objetivo da função é retornar o resultado de um cálculo ou algoritmo de decisã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 tem 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ê pode simplesmente usar o resultado, se quiser, porque é um nome que provavelmente não entrará em conflito com outra coisa; no entanto, do ponto de vista da legibilidade, faz mais sentido nomear sua variável de maneira mais significativa e contextual.


0

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

então no seu exemplo seria resultZorglub

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


Nada mal, mas acho que você teria que renomear sua variável se o tipo de retorno mudar. Com o IDE moderno, isso é feito em um ou dois cliques, de qualquer maneira, eu acho.
Jalayn

@ Jaalayn Sim, mas se o tipo foi mantido fora do nome, é uma mudança que não precisaria ser feita. (Se o tempo suficiente de um método que um nome simples não está claro, é provavelmente demasiado longo e deve ser reformulado.)
Donal Fellows

@DonalFellows Concordo plenamente com você. Quanto menos alterações você vê ao atualizar do repositório de origem, melhor.
Jalayn

Tudo bem concordou que, quando você altera o tipo de retorno, pode esquecer de alterá-lo também no nome da variável, isso é um problema. Até agora, isso nunca foi um problema para mim. Eu ainda gosto de mostrar a intenção dupla no nome, mas com um código de intenção menor já bom, também pode ser um exagero. Vocês me convenceram. Se eu sentir a necessidade de chamar minhas variáveis ​​dessa maneira de agora em diante, refatorarei até não sentir mais a necessidade. Graças
KeesDijk

0

Não vejo muita diferença entre definir um valor de retorno em algum momento e, em seguida, usar condicionais para ignorar todo o código que pode modificá-lo e returnimediatamente, por isso, busco o retorno direto, portanto, não há resultvariável.

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


0

Quando eu estava trabalhando em C ++ e acho que isso pode se aplicar em Java.

por exemplo

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

    //calculation

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

Este é o projeto por contrato, pois o bloco de garantia deve estar no final do método. Mas o retorno deve ser o último. Tínhamos a regra de que Return result era a única coisa que poderia seguir o bloco de garantia.


0

Em uma função recursiva, geralmente é eficaz levar o resultado passo a passo, para otimizar a chamada final. Para sinalizar ao usuário que ele não precisa fornecer um parâmetro, pode ser razoável nomear um parâmetro como "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, uso 'carry' e 'sofar', que já vi na natureza, e que carregam a idéia ainda um pouco melhor, na maioria dos casos.

Um segundo motivo é claro, se o 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.

Um terceiro motivo já foi afirmado, mas eu tenho um pequeno desvio: você escreve um método que realiza algum trabalho, digamos que ele avalie uma forma de '' max ''.

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

Em vez de chamar o resultado '' resultado '', poderíamos chamá-lo de '' max '', mas em alguns idiomas você pode omitir parênteses ao chamar um método, portanto max seria uma chamada recursiva para o próprio método.

Em geral, eu preferiria um nome que diga qual é o resultado. Mas se esse nome já estiver sendo usado, talvez por mais de uma variável, atributo ou método, porque existe um campo da GUI, uma representação de string, um numérico e um para o banco de dados, o uso de outro 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.


0

No Object Pascal, essa não é uma escolha. Você precisa atribuir valor à Resultvariável em algum lugar no código da função.

Exemplo:

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

Então, para mim, é bastante natural ter uma variável "Result" (ou "Retorno", como eu soletro em português para evitar conflito de nome com as palavras reservadas do idioma) para receber um valor de retorno.

É claro que, 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.


0

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


-1

resultado está bom. Sou capaz de entender o código à primeira vista, para que o nome da variável atenda ao objetivo.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.