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

¿Es una buena práctica llamar a la variable que un método devuelve 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 ambos en la naturaleza, si necesito elegir uno, ¿qué razones podrían hacerme preferir el primero o el segundo (o cualquier otro nombre mejor)?

Estoy pensando principalmente en Java.

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

Como ya tiene el nombre del tipo tanto en la declaración de variable como en el tipo de retorno del método, también podría usarlo result: es descriptivo del papel de la variable.

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

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

Si tuviera myFunction, podría nombrar su variable de retorno myFunctionReturnValuepara decir exactamente lo mismo, solo que tendría que decirlo explícitamente cada vez. Dado que las funciones generalmente deberían ser cortas, no hay necesidad de tal explicitación. E incluso si pierdo el rastro, 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 reto result) o explícitamente (como myFunctionReturnValueo myFunctionResult) indique, que esta es la variable de retorno de las funciones actuales, es demasiado genérica.

En su segundo ejemplo zorglubes una elección terrible. Todo lo que la declaración realmente me dice es 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 someInto 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 a 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 resultvariable" (como nota al margen: si está 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 que eso para saber que esta es la variable, que se devolverá y que quiero seguir en el cuerpo de la función si quiero entenderla.

Es posible que desee leer sobre programación espartana , que está más bien relacionada con su pregunta.

En su segundo ejemplo, está combinando el tipo de 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 return type. Sin embargo,

double variance;

por ejemplo, me da una pista sobre lo que significa el valor de retorno , en términos de semántica del programa. Puede o no 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.

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

Si lo nombra result, no hay posibilidad de que cometa un error como ese. Además, creo que es un buen nombre; También lo he visto returnedValueo returnedObjectvarias veces, también está claro aunque un poco largo.

Personalmente no me siento completamente cómodo usando resultun nombre variable. Justo, me dice que el valor asociado es el resultado de algunos cálculos; sin embargo, supongo que eso es cierto para aproximadamente (o más) el 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á de un método / función. Sin embargo, si mantengo mis métodos cortos, enfocados en hacer una sola cosa y permanecer consistentemente en un solo nivel de abstracción, no tendré muchas variables locales y será trivial ver qué va a devolver un método.

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 función local dentro del método de inclusión. Sin embargo, (por ejemplo, en el código heredado) Zorglub resultpuede ser más fácil de entender que Zorglub zorglub.

Yo personalmente uso el nombre resultdel 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.

¿Cual es la diferencia? son solo 2 palabras diferentes que harán lo mismo, así que el verdadero problema es cuál te parece más claro.

El "resultado" o "zorglub".

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

¿Debería nombrarlo por su tipo?

No nunca. Esto se llama Systems Hungarian y está trivialmente desactualizado por la idea de usar un programa que pueda mostrar el tipo de cualquier variable en cualquier momento que lo necesite.

Siempre que necesite nombrar algo 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, puede omitir el nombre por completo. Hacer que sus métodos sean cortos y de un solo propósito es siempre el ideal al que debe apuntar. Sin embargo, es el caso de que a veces necesite 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 algoritmo de cálculo o decisión, entonces resultes un nombre perfectamente adecuado para su variable, pero ¿qué sucede si su función está devolviendo un elemento de una lista? ¿Qué sucede si su función tiene 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 por qué se creó la función. Claro, simplemente puede usar el resultado si lo desea porque es un nombre que probablemente no choque con nada más, sin embargo, desde una perspectiva de legibilidad, tiene más sentido nombrar su variable de manera más significativa y en contexto.

Me gusta combinarlos, muestra lo que es y que está destinado a ser devuelto.

así que en su ejemplo sería resultZorglub

si lo que es realmente no importa, solo sería resultado (no resultString)

No veo mucha diferencia entre establecer un valor de retorno en algún momento y luego usar condicionales para omitir todo el código que podría modificarlo, e returning de inmediato, así que voy por el retorno directo, por lo tanto, no hay resultvariable.

Si tiene un valor intermedio que puede o no cambiarse por código condicional, entonces no es un resultado (todavía), por lo que ciertamente no debería llamarse así.

Cuando trabajaba en C ++ y supongo que esto podría aplicarse en Java, lo hice.

p.ej

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 devuelto era lo único que podía seguir el bloqueo de garantía.

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 las variables con valores y calcular un resultado al final.

Ya se ha establecido 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 '' max '', pero en algunos idiomas puede omitir 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á tomado, tal vez por más de una variable, atributo o método, porque hay un campo GUI, una representación de cadena, un número y uno para la base de datos, el uso de otro aumenta la probabilidad de confusión. En métodos cortos de 3 a 7 líneas, "resultado" no debería ser un problema para un nombre.

En Object Pascal esto no es una elección. Debe asignar valor a la Resultvariable 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 "Resultado" (o "Retorno", como lo escribo en portugués para evitar conflictos 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, devolviendo la expresión directamente.

no es solo lo que usted llama el resultado (soy particular de 'r'), sino también cómo se usa. por ejemplo, si va a tener una variable de retorno, cada declaración de retorno debería devolverla. no tiene 'return r;' al final, pero espolvorea cosas como 'return m * x + b; "en todo el método / función. usa" r = m * x + b; return r; "en su lugar.

El resultado está bien. Puedo entender el código a primera vista, por lo que el nombre de la variable sirvió para el propósito.