¿Es una buena práctica usar el operador xor para cheques booleanos?
https://stackoverflow.com/questions/160697
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
Personalmente, me gusta el operador exclusivo o , ^ cuando tiene sentido en el contexto de los controles booleanos debido a su concisión. Prefiero mucho escribir
if (boolean1 ^ boolean2)
{
//do it
}
que
if((boolean1 && !boolean2) || (boolean2 && !boolean1))
{
//do it
}
pero a menudo me confunden las miradas de otros desarrolladores de Java con experiencia (no solo los novatos) y, a veces, comentarios sobre cómo debería usarse solo para operaciones bitwise.
Tengo curiosidad por las mejores prácticas con respecto al uso del operador ^ .
Solución
Puede simplemente utilizar ! = en su lugar.
Otros consejos
Creo que has respondido tu propia pregunta: si la gente te mira de forma extraña, probablemente sea más seguro elegir la opción más explícita.
Si necesita comentarlo, entonces es mejor que lo reemplace con la versión más detallada y no haga que la gente haga la pregunta en primer lugar.
Encuentro que tengo muchas conversaciones similares. Por un lado, tiene un método compacto y eficiente para lograr su objetivo. Por otro lado, tienes algo que el resto de tu equipo puede no entender, lo que dificulta su mantenimiento en el futuro.
Mi regla general es preguntar si la técnica utilizada es algo que es razonable esperar que los programadores en general sepan. En este caso, creo que es razonable esperar que los programadores sepan cómo usar operadores booleanos, por lo que usar xor en una declaración if está bien.
Como ejemplo de algo que no estaría bien, tome el truco de usar xor para intercambiar dos variables sin usar una variable temporal. Ese es un truco con el que no esperaría que todos estuvieran familiarizados, por lo que no pasaría la revisión del código.
Creo que estaría bien si lo comentaras, por ejemplo. // ^ == XOR .
Siempre puedes envolverlo en una función para darle un nombre detallado:
public static boolean XOR(boolean A, boolean B) {
return A ^ B;
}
Pero, me parece que no sería difícil para alguien que no supiera lo que es el operador ^ para Google, que es realmente rápido. No va a ser difícil de recordar después de la primera vez. Como solicitó otros usos, es común usar el XOR para el enmascaramiento de bits.
También puede usar XOR para intercambiar los valores en dos variables sin usar una tercera variable temporal .
// Swap the values in A and B
A ^= B;
B ^= A;
A ^= B;
Aquí hay una pregunta de Stackoverflow relacionada con el intercambio de XOR .
Hace poco usé un xor en un proyecto de JavaScript en el trabajo y terminé agregando 7 líneas de comentarios para explicar lo que estaba sucediendo. La justificación para usar xor en ese contexto fue que uno de los términos ( term1 en el ejemplo a continuación) podría tomar no dos sino tres valores: undefined , true o false mientras que el otro ( term2 ) podría ser true o false . Hubiera tenido que agregar una verificación adicional para los casos undefined pero con xor, lo siguiente fue suficiente, ya que xor obliga a que el primer término se evalúe por primera vez como booleano, dejando undefined ser tratado como falso :
if (term1 ^ term2) { ...
Al final, fue un poco exagerado, pero de todos modos quería mantenerlo ahí, como una especie de huevo de Pascua.
if((boolean1 && !boolean2) || (boolean2 && !boolean1))
{
//do it
}
En mi humilde opinión este código podría simplificarse:
if(boolean1 != boolean2)
{
//do it
}
Teniendo en cuenta la claridad del código, mi opinión es que el uso de XOR en controles booleanos no es un uso típico para el operador bit a bit de XOR. Desde mi experiencia, XOR bitwise en Java es típicamente usado para implementar un comportamiento de máscara flag toggle :
flags = flags ^ MASK;
Este artículo de Vipan Singla explica el caso de uso con más detalle.
Si necesita usar XOR bitwise como en su ejemplo, comente por qué lo usa, ya que es probable que requiera que incluso una audiencia alfabetizada bitwise se detenga en sus pasos para entender por qué lo está usando.
Si el patrón de uso lo justifica, ¿por qué no? Si bien su equipo no reconoce al operador de inmediato, con el tiempo podría hacerlo. Los humanos aprenden nuevas palabras todo el tiempo. ¿Por qué no en la programación?
La única advertencia que puedo indicar es que " ^ " no tiene la semántica de cortocircuito de su segunda comprobación booleana. Si realmente necesita la semántica de cortocircuito, también funciona un método estático.
public static boolean xor(boolean a, boolean b) {
return (a && !b) || (b && !a);
}
Personalmente prefiero el " boolean1 ^ boolean2 " Expresión debido a su carácter sucinto.
Si estuviera en tu situación (trabajando en un equipo), lograría un compromiso al encapsular el " boolean1 ^ boolean2 " lógica en una función con un nombre descriptivo como " isDifferent (boolean1, boolean2) " ;.
Por ejemplo, en lugar de usar " boolean1 ^ boolean2 " ;, llamaría " isDifferent (boolean1, boolean2) " como asi:
if (isDifferent(boolean1, boolean2))
{
//do it
}
Tu " isDifferent (boolean1, boolean2) " La función se vería como:
private boolean isDifferent(boolean1, boolean2)
{
return boolean1 ^ boolean2;
}
Por supuesto, esta solución implica el uso de una llamada de función ostensiblemente extraña, que en sí misma está sujeta al escrutinio de Mejores Prácticas, pero evita la expresión verbosa (y fea) (boolean1 & amp; & amp;! boolean2) | | (boolean2 & amp; & amp;! boolean1) " ;!
! = está bien para comparar dos variables. Sin embargo, no funciona con comparaciones múltiples.
str.contains("!=") ^ str.startsWith("not(")
se ve mejor para mí que
str.contains("!=") != str.startsWith("not(")
Como operador bit a bit, xor es mucho más rápido que cualquier otro medio para reemplazarlo. Por lo tanto, para cálculos críticos de rendimiento y escalables, xor es imperativo.
Mi opinión personal subjetiva: está absolutamente prohibido, para cualquier propósito, usar la igualdad (== o! =) para los booleanos. Usándolo muestra falta de ética y fundamentos básicos de programación. Cualquiera que te dé miradas confusas sobre ^ debe ser devuelto a los conceptos básicos del álgebra booleana (tuve la tentación de escribir "a los ríos de creencias" aquí :)).
