valor - Expresiones booleanas en Java

retornar valor booleano en java

Question

Tengo una pregunta sobre el significado (evaluación) de las variables booleanas en las declaraciones de retorno en Java.

Yo sé eso:

if (var) { ... }

es lo mismo que:

if (var==true) { ... }

En el segundo caso, explícitamente decimos var == verdadero, pero no necesitamos hacer esto, porque Java evalúa var como verdadero de todos modos. Espero haber entendido esto bien.

Mi pregunta es: ¿es lo mismo cuando se devuelven variables booleanas? Cuando tenemos una declaración de devolución?

Por ejemplo, una tarea especifica: el método looksBetter () devolverá verdadero solo si b <a. Mi solución fue:

public boolean looksBetter() {
if (b < a) {
return true;
} else {
return false;
}
}

La respuesta simple fue:

public boolean lookBetter() {
return b < a;
}

Entonces, parece que aquí tenemos de nuevo esta suposición implícita de que en el caso de que b <a == verdadero, el retorno del método sea verdadero. Lo siento ... parece muy trivial, pero de alguna manera no estoy cómodo con esto, y no sé por qué. Gracias.

Answer 1

Al igual que C ++, cada instrucción tiene un valor de retorno, incluso cosas en el lado izquierdo del operador. Algunos de los C ++ Crazy que he visto tienen operaciones en el lado izquierdo con sus resultados asignados.

Creo que funciona mejor si hago lo siguiente:

bool result = (b > a);
return result;

La razón es que es más fácil de depurar (en casi cualquier IDE). Me parece que siempre lo envuelvo entre paréntesis, no estoy muy seguro de por qué. Creo que mantiene los electrones variables calientes mientras duermen por la noche.

Answer 2

Creo que estás preguntando por qué estás teniendo un problema conceptual.

Creo que el problema básico es que cuando devuelves directamente un valor booleano, te está faltando algo, y lo estás haciendo. Es el nombre del método en tu caso.

Your LooksBetter no significa nada. Lo que realmente estás pensando es esto:

boolean isEarlier(Time a, Time b) {
if(a < b) //for simplicity let''s ignore that this won''t work.
return true;
else
return false;
}

Ahora, puedes reducir eso a:

boolean isEarlier=a < b;

Hmm, bueno ahora podemos ver que a es anterior a b, y eso es lo que significa el valor intermedio.

Entonces, una vez que se internaliza ese valor intermedio, tiene más sentido:

boolean isEarlier(Time a, Time b) {
return a < b;
}

Tienes que pensar en ese "booleano" como un valor real, no solo en un estado intermedio. Si te hace sentir incómodo, siéntete libre de convertirlo en una variable (realmente no cuesta nada, y puede hacerlo más legible para ti en este momento).

Más adelante mirará atrás en su código y se sentirá más cómodo con la manera más corta de verlo. En su mayoría le toma tiempo a su mente crear nuevos caminos, no se avergüence de ser explícito mientras tanto.

Answer 3

No complique innecesariamente su código. Si sientes la necesidad de decir "a <b == verdadero", puedes seguir eso hasta su confluencia lógica (conclusión + confusión) y decir " ((((((((...(a<b) == true) == true).... == true) "

"a <b" es una expresión booleana. Si ya tiene un booleano, ¿por qué compararlo con otro booleano? No lo estás haciendo más booleano de esa manera.

Answer 4

No es una "suposición implícita", es lo que hace el compilador. El b < a es solo una expresión, lo mismo que si se usara para una declaración if . La expresión se evalúa como boolean , que luego se devuelve.

También cabe destacar que parece intercambiar Boolean y Boolean como si fueran iguales, pero en realidad no lo son. boolean es la forma primitiva, mientras que Boolean es un objeto que envuelve un boolean .

Answer 5

Sí, esto es cierto para todos los booleanos. Puedes pensar si (expresión) evaluando ''expresión'' para ver si es ''verdadera'' o ''falsa''. Cuando tu lo hagas

if(b < a == true)

primero prueba para ver si b <a y si lo está, ahora prueba:

if(true == true)

Ahora prueba si true == true (que obviamente lo hace). Java no hace nada complicado cuando omites el extra ''== verdadero'', solo necesita realizar una prueba menos. No hay razón por la que no puedas decir:

if(((b < a == true) == true) == true)

pero haría que Java realizara una prueba adicional cada vez que vea un signo igual.

Answer 6

Su método funcionará, pero puede ser un poco confuso qué exactamente debería suceder, especialmente si solo tiene variables llamadas a y b. Desea documentar el método y tener variables con nombres propios.

Además, si el código le resulta confuso justo después de que lo escribió, piense en alguien que vendrá en 6 meses y no tendrá idea de lo que está sucediendo. La documentación y los comentarios adecuados ayudarán mucho.

Answer 7

Una condición condicional de Java requiere un valor booleano. Si puede ponerlo en una declaración if, ya es un booleano, y no requiere más manipulación si lo que quiere es un booleano.

De hecho, los constructos como value == true pueden ser engañosos. No recuerdo de improviso las reglas de promoción en Java, pero en C ++ un bool puede ser promovido a un int, con falso convirtiéndose en 0 y verdadero en 1. Por lo tanto, int a = 2; if (a) int a = 2; if (a) e int a = 2; if (a == true) int a = 2; if (a == true) hará cosas diferentes.

Answer 8

Esto no es una "suposición implícita" o algún otro tipo de magia.
Solo dos expresiones diferentes que producen el mismo resultado.
Es algo así como

int i = 123;
return i;

o

int i = 123;
return i + 0;

"i" e "i + 0" son dos expresiones que dan como resultado el mismo valor. (El compilador debe ser lo suficientemente inteligente como para simplificar el último en el mismo que el primero)

Answer 9

Su confusión podría aliviarse si intenta pensar en los operadores como métodos. Usando su ejemplo, tenía el operador <"menor que". Para nuestros propósitos, el operador <realmente se puede considerar un "método" (no se ve como uno), que toma dos parámetros y devuelve un resultado booleano. Si el "método" se llama lessThan, su ejemplo sería equivalente a esto:

public boolean lookBetter() {
return lessThan(b, a);
} 

Quizás verlo así lo hace un poco más fácil de entender. Por cierto, cuando dirigía grupos de ejercicios en el curso ''Programación 101'' en Uni, resultó ser, por mucho, lo más difícil de enseñar, y muchas personas tuvieron problemas para captar los conceptos involucrados. Casi parece ser similar a aprender a andar en bicicleta o a nadar, una vez que obtienes cómo funciona, se vuelve evidente de alguna manera.