É uma boa prática usar o operador xor para verificações booleanas? [fechadas]

Pessoalmente, gosto do operador exclusivo ou , ^quando faz sentido no contexto de verificações booleanas devido à sua concisão. Eu prefiro muito escrever

if (boolean1 ^ boolean2)
{
  //do it
}

do que

if((boolean1 && !boolean2) || (boolean2 && !boolean1))
{
  //do it
}

mas muitas vezes recebo olhares confusos de outros desenvolvedores Java experientes (não apenas dos novatos) e, às vezes, comenta sobre como ele deve ser usado apenas para operações bit a bit.

Estou curioso sobre as melhores práticas em relação ao uso do ^operador.

Você pode simplesmente usar !=.

Acho que você respondeu sua própria pergunta - se você receber olhares estranhos das pessoas, provavelmente é mais seguro usar a opção mais explícita.

Se você precisar comentar, provavelmente será melhor substituí-lo pela versão mais detalhada e não fazer com que as pessoas façam a pergunta em primeiro lugar.

Acho que tenho muitas conversas semelhantes. Por um lado, você tem um método compacto e eficiente para atingir seu objetivo. Por outro lado, você tem algo que o resto da sua equipe pode não entender, dificultando a manutenção no futuro.

Minha regra geral é perguntar se a técnica usada é algo que é razoável esperar que os programadores em geral conheçam. Nesse caso, acho razoável esperar que os programadores saibam como usar operadores booleanos, portanto, usar xor em uma instrução if está correto.

Como um exemplo de algo que não seria bom, use o xor para trocar duas variáveis ​​sem usar uma variável temporária. Esse é um truque com o qual eu não esperaria que todos estivessem familiarizados, para que não passasse na revisão de código.

Eu acho que tudo bem se você comentar, por exemplo // ^ == XOR.

Você sempre pode envolvê-lo em uma função para fornecer um nome detalhado:

public static boolean XOR(boolean A, boolean B) {
    return A ^ B;
}

Mas, parece-me que não seria difícil para quem não sabia o que é o operador ^ para o Google, muito rápido. Não será difícil lembrar depois da primeira vez. Como você solicitou outros usos, é comum usar o XOR para mascarar bits.

Você também pode usar o XOR para trocar os valores em duas variáveis ​​sem usar uma terceira variável temporária .

// Swap the values in A and B
A ^= B;
B ^= A;
A ^= B;

Aqui está uma pergunta sobre o Stackoverflow relacionada à troca de XOR .

Recentemente, usei um xor em um projeto JavaScript no trabalho e acabei adicionando 7 linhas de comentários para explicar o que estava acontecendo. A justificação para a utilização de xor nesse contexto que era um dos termos ( term1no exemplo a seguir) pode assumir não dois, mas três valores: undefined, trueou falseenquanto o outro ( term2) pode ser trueou false. Eu teria que adicionar uma verificação adicional para os undefinedcasos, mas com o xor, o seguinte foi suficiente, pois o xor força o primeiro termo a ser avaliado pela primeira vez como um booleano, permitindo que undefinedseja tratado como false:

if (term1 ^ term2) { ...

No final, foi um pouco exagerado, mas eu queria mantê-lo lá de qualquer maneira, como uma espécie de ovo de páscoa.

if((boolean1 && !boolean2) || (boolean2 && !boolean1)) 
{ 
  //do it 
} 

IMHO este código pode ser simplificado:

if(boolean1 != boolean2) 
{ 
  //do it 
} 

Com a clareza do código em mente, minha opinião é que o uso do XOR em verificações booleanas não é um uso típico para o operador bit a bit do XOR. Pela minha experiência, o XOR bit a bit em Java é normalmente usado para implementar um flag togglecomportamento de máscara :

flags = flags ^ MASK;

Este artigo de Vipan Singla explica o caso de uso em mais detalhes.

Se você precisar usar o XOR bit a bit, como no seu exemplo, comente o motivo de usá-lo, pois é provável que exija que mesmo um público alfabetizado bit a bit pare em suas trilhas para entender por que você está usando.

Pessoalmente, prefiro a expressão "boolean1 ^ boolean2" devido à sua sucessão.

Se eu estivesse na sua situação (trabalhando em equipe), obteria um compromisso encapsulando a lógica "boolean1 ^ boolean2" em uma função com um nome descritivo como "isDifferent (boolean1, boolean2)".

Por exemplo, em vez de usar "boolean1 ^ boolean2", você chamaria "isDifferent (boolean1, boolean2)" assim:

if (isDifferent(boolean1, boolean2))
{
  //do it
}

Sua função "isDifferent (boolean1, boolean2)" seria semelhante a:

private boolean isDifferent(boolean1, boolean2)
{
    return boolean1 ^ boolean2;
}

Obviamente, essa solução implica o uso de uma chamada de função aparentemente ostensiva, que por si só está sujeita ao exame de Melhores Práticas, mas evita a expressão detalhada (e feia) "(boolean1 &&! Boolean2) || (boolean2 &&! Boolean1) "!

Se o padrão de uso justifica, por que não? Embora sua equipe não reconheça o operador imediatamente, com o tempo que eles puderam. Os humanos aprendem novas palavras o tempo todo. Por que não na programação?

O único cuidado que posso afirmar é que "^" não possui a semântica de curto-circuito da sua segunda verificação booleana. Se você realmente precisa da semântica de curto-circuito, um método utilitário estático também funciona.

public static boolean xor(boolean a, boolean b) {
    return (a && !b) || (b && !a);
}

! = está OK para comparar duas variáveis. Porém, não funciona com múltiplas comparações.

Como operador bit a bit, o xor é muito mais rápido do que qualquer outro meio para substituí-lo. Portanto, para cálculos críticos e escalonáveis ​​de desempenho, xor é imperativo.

Minha opinião pessoal subjetiva: é absolutamente proibido, para qualquer finalidade, usar igualdade (== ou! =) Para booleanos. Usá-lo mostra falta de ética e fundamentos básicos de programação. Qualquer um que lhe dê uma olhada confusa ^ deve ser enviado de volta ao básico da álgebra booleana (fiquei tentado a escrever "nos rios da crença" aqui :)).

str.contains("!=") ^ str.startsWith("not(")

parece melhor para mim do que

str.contains("!=") != str.startsWith("not(")