¿Es una buena práctica nombrar "variable" a la variable devuelta? [cerrado]

40

¿Es una buena práctica llamar a la variable que devuelve un método con un nombre de variable result ?

Por ejemplo:

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

¿O debería nombrarlo por su tipo?

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

He visto ambas cosas en la naturaleza, si necesito elegir una, ¿por qué motivos podrían hacerme preferir la primera o la última (o un nombre mejor)?

Estoy pensando principalmente en Java.

    
pregunta Nicolas Raoul 11.02.2012 - 01:31

17 respuestas

46

Si esta es una variable de método, realmente depende de la legibilidad.

Al ver que ya tiene el nombre de tipo tanto en la declaración de la variable como en el tipo de retorno del método, también puede usar result , es descriptivo del rol de la variable.

    
respondido por el Oded 10.02.2012 - 10:29
39

La lectura cruzada se hace más fácil si la variable se llama result . Esto deja clara tu intención.

    
respondido por el mouviciel 10.02.2012 - 10:33
16

Si necesito una variable de retorno (que en realidad ocurre raramente), siempre la llamo ret y la defino justo debajo del cabezal de función. La función ya tiene un nombre, que dice todo sobre lo que devuelve.

Si tengo myFunction I podría nombrar su variable myFunctionReturnValue para decir exactamente lo mismo, solo tendría que decirlo explícitamente cada vez. Como las funciones generalmente deben ser cortas, no hay necesidad de tal explicación. E incluso si pierdo la pista, puedo saltar a la declaración y aterrizaré justo debajo de la definición de la función.

Pero cualquier otro nombre, que no implícitamente (como ret o result ) o explícitamente (como myFunctionReturnValue o myFunctionResult ) indica que esta es la variable de retorno de funciones actual es demasiado genérica.

En tu segundo ejemplo, zorglub es una elección terrible. Toda la declaración realmente me dice que usted creó una variable, cuyo nombre es igual a la anotación de tipo que se encuentra justo al lado del nombre. Es tan útil como int someInt o Zorglub z .

En su primer ejemplo, cuando miro el código, primero veo el nombre de la función, que me dice, que esta función calcula un Zorglub . Cuando leo la segunda línea, veo "ok, aquí está el zorglub, que se devolverá, pero evidentemente no se puede devolver de inmediato y, por lo tanto, se almacena en la variable result " (como nota al margen: Si no va a reasignar el valor, entonces es mejor que declare la variable final para comunicar eso), y luego pienso "así que ahora veamos qué sucede antes de que se devuelva". A diferencia del primer ejemplo, no necesito leer más allá de eso para saber que esta es la variable, que se devolverá y que quiero seguir en el cuerpo de la función si quiero para entenderlo

Es posible que desee leer Spartan Programming , que está bastante relacionado con tu pregunta.

    
respondido por el back2dos 10.02.2012 - 12:23
12

En tu segundo ejemplo, estás combinando el tipo del resultado con lo que es .

Zorglub zorglub;

solo me dice que es un Zorglub, dos veces. Tres veces si me molesto en leer el método de retorno. Sin embargo,

double variance;

por ejemplo, me da una pista acerca de lo que significa el valor de retorno significa , en términos de semántica del programa. Puede o no puede ser más claro que simplemente llamarlo result , dependiendo del tamaño del método, es una decisión de juicio para cada método IMO.

    
respondido por el Useless 10.02.2012 - 13:05
8

Si juegas con muchos objetos Zorglub en tus métodos, "podrías" cometer un error y devolver el equivocado, y / o podrías tener la tentación de nombrar a los demás zorglub1 , zorglub2 , etc.

Si lo nombras result , no hay posibilidad de que cometas un error así. Además, me parece que es un buen nombre; También he visto returnedValue o returnedObject varias veces, también está claro aunque un poco largo.

    
respondido por el Jalayn 10.02.2012 - 10:45
5

Personalmente no me siento completamente cómodo usando result como nombre de variable. Justo lo suficiente, me dice que el valor asociado es el resultado de algunos cálculos; sin embargo, supongo que eso es cierto (aproximadamente) o más del 90% de las variables / campos utilizados en un programa.

Además, como se señaló en otras respuestas, se puede usar para marcar el valor que se devolverá desde un método / función. Sin embargo, si mantengo mis métodos cortos, enfocado en hacer solo una cosa y manteniéndome constantemente en un solo nivel de abstracción, no tendré muchas variables locales y será trivial ver qué método va a regresar.

Por lo tanto, prefiero mantener mis métodos cortos y limpios, y nombrar mis variables para expresar el significado del valor que tienen, en lugar de su rol local dentro del método adjunto. Sin embargo, (por ejemplo, en el código heredado) Zorglub result puede ser más fácil de entender que Zorglub zorglub .

    
respondido por el Péter Török 10.02.2012 - 10:40
1

Personalmente uso el nombre result para el valor que se devolverá de la función / método. Hace explícito que es el valor a devolver. Nombrarlo por tipo no parece útil, porque puede haber más de una variable del mismo tipo.

    
respondido por el Juraj Blaho 10.02.2012 - 10:32
1

¿Cuál es la diferencia? allí solo hay 2 palabras diferentes que harán lo mismo por lo que el problema real es ¿cuál le suena más claro?

El "resultado" o "zorglub".

Preferiría usar ZorglubResult para un iniciador para ver que el resultado devuelto desde Zorglub es más fácil de comparar con otros resultados que pueda tener y es un resultado como puede ver.

    
respondido por el Berker Yüceer 10.02.2012 - 10:34
1
  

¿Debo nombrarlo por su tipo?

No. Nunca. Esto se denomina sistemas húngaros y está trivialmente desactualizado por la idea de utilizar un programa que pueda mostrar el tipo de variable en cualquier momento que lo necesite.

    
respondido por el DeadMG 10.02.2012 - 20:22
1

Cuando necesite nombrar cualquier cosa en el código, debe proporcionar nombres que sean descriptivos, significativos y legibles. El caso de una variable de retorno es un ejemplo particularmente bueno de donde las personas tienden a ser complacientes con los nombres.

Si tiene una función que tiene un nombre claro y solo necesita una sola línea de código, entonces puede omitir el nombre por completo. Hacer que sus métodos sean cortos y con un único propósito es siempre el ideal al que debe aspirar. Sin embargo, es el caso que a veces es necesario completar una función con varias líneas de código. En esos casos, siempre es recomendable nombrar su variable para que coincida con el propósito de su función.

Si el propósito de la función es devolver el resultado de un cálculo o un algoritmo de decisión, entonces result es un nombre perfectamente adecuado para que lo use su variable, pero ¿qué sucede si su función devuelve un elemento de una lista? ¿Qué pasa si su función cumple algún otro propósito que no tiene nada que ver con las matemáticas o las listas? En esos casos, es mejor proporcionar a la variable un nombre significativo que se relacione con la razón por la que se creó la función. Claro, usted podría simplemente usar el resultado si lo desea, porque es un nombre que probablemente no coincida con otra cosa, sin embargo, desde una perspectiva de legibilidad, tiene más sentido nombrar su variable de manera más significativa y en contexto.

    
respondido por el S.Robins 10.02.2012 - 22:41
0

Me gusta combinarlos, muestra lo que es y lo que se pretende devolver.

por lo que en tu ejemplo sería resultZorglub

si lo que es realmente no importa de lo que sería simplemente el resultado (no resultString)

    
respondido por el KeesDijk 10.02.2012 - 10:41
0

No veo mucha diferencia entre establecer un valor de retorno en algún punto y luego usar condicionales para omitir todo el código que pueda modificarlo, y return ing de inmediato, así que me dirijo a la devolución directa por lo tanto, no hay una variable result .

Si tiene un valor intermedio que puede o no puede ser modificado por el código condicional, entonces no es un resultado (aún), por lo que ciertamente no debería ser nombrado así.

    
respondido por el Simon Richter 10.02.2012 - 14:12
0

Cuando estaba trabajando en C ++ y supongo que esto puede aplicarse en Java lo hice.

por ejemplo

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

    //calculation

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

Este es un diseño por contrato, ya que el bloque de garantía debe estar al final del método. Pero el regreso debe ser el último. Teníamos la regla de que el resultado de devolución era lo único que podía seguir el bloque de garantía.

    
respondido por el ctrl-alt-delor 10.02.2012 - 16:42
0

En una función recursiva, a menudo es efectivo llevar el resultado paso a paso, para hacer una optimización de llamada de cola. Para indicar al usuario que no necesita proporcionar un parámetro, puede ser razonable nombrar un 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)
}

Pero más a menudo uso 'carry' y 'sofar', que he visto en la naturaleza, y que llevan la idea incluso un poco mejor, en la mayoría de los casos.

Una segunda razón es, por supuesto, si su tema sugiere la palabra '' resultado '', por ejemplo, si realiza una evaluación aritmética. Puede analizar la fórmula, reemplazar variables con valores y calcular un resultado al final.

Ya se ha indicado una tercera razón, pero tengo una pequeña desviación: escribe un método que realiza algún trabajo, digamos que evalúa una forma de '' max ''.

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

En lugar de llamar al resultado '' resultado '', podríamos llamarlo '' máximo '', pero en algunos idiomas puede omitir el paréntesis al llamar a un método, por lo que max sería una llamada recursiva al método en sí.

En general, preferiría un nombre que diga cuál es el resultado. Pero si ese nombre ya está en uso, tal vez por más de una variable, atributo o método, porque hay un campo GUI, una representación de cadena, una numérica y una para la base de datos, usar otra aumenta la probabilidad de confusión. En métodos cortos de 3 a 7 líneas, el "resultado" no debería ser un problema para un nombre.

    
respondido por el user unknown 10.02.2012 - 19:01
0

En Object Pascal esto no es una opción. Debe asignar un valor a la variable Result en algún lugar del código de la función.

Ejemplo:

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

Entonces, para mí es bastante natural tener una variable de "Resultado" (o "Retorno", ya que la deletreo en portugués para evitar el conflicto de nombres con las palabras reservadas del idioma) para recibir un valor de retorno.

Por supuesto, si es una expresión muy simple en un lenguaje derivado de C, no me molestaré en declarar una variable de resultado: devolver la expresión directamente.

    
respondido por el Fabricio Araujo 10.02.2012 - 19:19
0

no es solo lo que nombra el resultado (soy particular a 'r'), sino también su uso. por ejemplo, si va a tener una variable de retorno, entonces cada declaración de retorno debería devolverla. no tiene 'return r' al final, pero rocíe cosas como 'return m * x + b; "a lo largo del método / función. use" r = m * x + b; devuelve r; "en su lugar.

    
respondido por el rbp 10.02.2012 - 22:13
-1

el resultado está bien. Soy capaz de entender el código a primera vista, de modo que el nombre de la variable sirvió para este propósito.

    
respondido por el java_mouse 10.02.2012 - 20:42

Lea otras preguntas en las etiquetas