Sé que no podemos usar el operador de asignación en las sentencias if en java, como usamos en otros pocos idiomas.Confunde con == y = en la instrucción "if"
que es
int a;
if(a = 1) { }
dará un error de compilación.
pero el siguiente código funciona bien, ¿cómo?
boolean b;
if(b = true) { }
EDITAR: Esta es la excepción a la regla que la asignación no se puede utilizar en la instrucción if.
Porque el "resultado" de una tarea es el valor asignado ... por lo que sigue siendo una expresión boolean en el segundo caso. Las expresiones if requieren que la condición sea una expresión boolean, que se cumple por el segundo pero no por el primero. Efectivamente, los dos fragmentos son:
int a;
a = 1;
if (a) { }
y
boolean b;
b = true;
if (b) { }
¿Está claro que la expansión de la segunda versión que se compilará, pero no el primero?
Esta es una razón para no hacer comparaciones entre verdadero y falso directamente. Por lo tanto, siempre escribiría if (b) en lugar de if (b == true) y if (!b) en lugar de if (b == false). Todavía tiene problemas con if (b == c) cuando b y c son variables boolean, hay un error tipográfico que puede causar un problema. Sin embargo, no puedo decir que me haya pasado alguna vez.
EDIT: En respuesta a tu edición - cesiones de todo tipo se puede utilizar en if declaraciones - y while bucles, etc, siempre y cuando la expresión de condición general es boolean. Por ejemplo, es posible que tiene:
String line;
while ((line = reader.readLine()) != null)
{
// Do something with a line
}
Mientras generalmente Evita efectos secundarios en las condiciones, este idioma en particular es a menudo útil para el ejemplo mostrado anteriormente, o el uso de InputStream.read. Básicamente es "mientras que el valor que leí es útil, úselo".
¿Estás seguro de que hay un par adicional de paréntesis en el último ejemplo? Pensé que la asignación tiene la última precedencia en Java ... –
@Carlos: Buena captura. Tal vez estoy tan acostumbrado a ponerlo deliberadamente que nunca lo intenté sin :) –
Normalmente pienso en ese modismo (y lo uso cuando la analogía se ajusta) en términos de los métodos hasNext y siguientes del iterador: básicamente está implementando un combinación de esos para algo que no es explícitamente un iterador (y de seguro desearía que los lectores implementaran esa interfaz en versiones posteriores). – Carl
Para if necesita una expresión que evalúe a boolean. b = true evaluea a boolean pero a = 1 evalúa a int ya que las asignaciones siempre evalúan los valores asignados.
La razón por la que el segundo código funciona bien es porque está asignando 'b' el valor de verdadero y luego comparando para ver si b es verdadero o falso. La razón por la que puede hacer esto es porque puede hacer operadores de asignación dentro de una instrucción if, Y puede comparar contra un booleano por sí mismo. Sería lo mismo que hacer si (verdadero).
En java, no tiene conversión implícita. Entonces valores no booleanos o no transformados automáticamente a booleanos.
En el primer caso, el resultado de las instrucciones es un int, que no es booleano, que no funcionará. El último caso, el resultado es booleano, que se puede evaluar en una instrucción if.
La regla no es que "asignación no se puede utilizar en una sentencia if", pero que "la condición en un comunicado por if debe ser del tipo boolean". Una expresión de asignación produce un valor del tipo que se le asigna, por lo que Java solo permite la asignación en una declaración if si está asignando un valor de boolean.
Esta es una buena razón por la que se debe evitar el estilo if (foo == true), y en su lugar simplemente escriba if (foo).
No es una mala idea para obtener en el hábito de poner la primera constante en sus instrucciones if .... Es decir: si (verdadero == b) {} y si (1 == a) { } Este hábito garantiza que el compilador te golpeará si escribes = en lugar de ==. –
@Ollie: las opiniones difieren ampliamente en eso. En lo que respecta a la legibilidad, esta * es * una mala idea. Además, no ofrece ningún beneficio en idiomas como Java, ya que aquí no puede haber confusión. Quiero decir, nadie escribe una prueba como 'if (a == verdadero)', ¿verdad? –
@Konrad. Tienes razón en Java, pero para este recauchutado en C que trabaja en PERL y en otros idiomas, me ha ahorrado muchas veces. –