Devo usar parênteses em declarações lógicas mesmo quando não for necessário?

100

Digamos que eu tenho uma condição booleana a AND b OR c AND de estou usando um idioma em ANDque uma ordem de operação maior é anterior a OR. Eu poderia escrever esta linha de código:

If (a AND b) OR (c AND d) Then ...

Mas, na verdade, isso é equivalente a:

If a AND b OR c AND d Then ...

Existem argumentos a favor ou contra, incluindo os parênteses estranhos? A experiência prática sugere que vale a pena incluí-los para facilitar a leitura? Ou é um sinal de que um desenvolvedor precisa realmente se sentar e se tornar confiante no básico de seu idioma?

Jeff Bridgman
fonte
90
Posso ser preguiçoso, mas prefiro ter parênteses na maioria dessas situações para facilitar a leitura.
Thorsten Müller
6
Eu também. Eu só espero que eu esteja fazendo isso mais para facilitar a leitura e menos porque tenho preguiça de me tornar confiante / competente no básico do meu idioma.
11133 Jeff Bridgman
16
Um bom uso de parênteses é como um bom uso de gramática. 2 * 3 + 2pode ser o mesmo, (2 * 3) + 2mas o segundo é mais fácil de ler.
Reactgular
16
@ Matthew Talvez se você é fraco em matemática. Para casos mais complexos, com certeza, use parênteses. Mas, para os cegamente óbvios (BODMAS ...), eles reduzem a legibilidade mais do que ajudam devido à confusão.
Konrad Rudolph
3
Dito isto, a mesma precedência de AND / OR é válida em Basic, Python, SQL ... minha impressão é que essa é a regra na grande maioria das linguagens modernas (embora nem todas).
Tim Goodman

Respostas:

118

Bons desenvolvedores se esforçam para escrever um código claro e correto . Parênteses em condicionais, mesmo que não sejam estritamente necessários, ajudam nos dois.

Quanto à clareza , pense nos parênteses como comentários no código: eles não são estritamente necessários e, em teoria, um desenvolvedor competente deve ser capaz de descobrir o código sem eles. E, no entanto, essas dicas são extremamente úteis, porque:

  • Eles reduzem o trabalho necessário para entender o código.
  • Eles fornecem a confirmação da intenção do desenvolvedor.

Além disso, parênteses extras, como recuos, espaços em branco e outros padrões de estilo, ajudam a organizar visualmente o código de maneira lógica.

Quanto à correção , condições sem parênteses são uma receita para erros tolos. Quando eles acontecem, podem ser difíceis de encontrar - porque geralmente uma condição incorreta se comporta corretamente na maioria das vezes, e apenas ocasionalmente falha.

E mesmo se você acertar, a próxima pessoa a trabalhar no seu código pode não, adicionando erros à expressão ou entendendo mal sua lógica e, assim, adicionando erros em outros lugares (como LarsH corretamente aponta).

Eu sempre uso parênteses para expressões que combinam ande or(e também para operações aritméticas com problemas de precedência semelhantes).

user82096
fonte
3
Embora, eu ouvi dizer que os comentários são desculpas (por código ruim / difícil de ler) ... há uma boa chance de você ter escrito melhor. Eu acho que você poderia dizer coisas semelhantes sobre parênteses.
11133 Jeff Bridgman
6
Outro aspecto da correção é preservá-lo através de alterações: embora o desenvolvedor original possa ter precedência sem parênteses quando escreve o código pela primeira vez com o objetivo e o contexto atualizados, ele (ou outro) que aparece mais tarde e não se lembra de tudo os detalhes podem atrapalhar quando adicionam mais termos à expressão. (Que foi principalmente já implícito, mas eu senti que era importante ressaltar.)
Larsh
1
@ LarsH, obrigado, eu adicionei isso explicitamente à resposta.
8
+1 "Eles fornecem confirmação da intenção do desenvolvedor." - qualquer programador (OK, talvez não todos, mas todos os que residem aqui ...) pode descobrir o que o compilador fará com a lógica mais complexa. Absolutamente ninguém pode descobrir o que o desenvolvedor original pretendia (inclusive ele mesmo), algumas semanas mais
tarde
2
Acho que @JeffBridgman estava fazendo referência a um ponto de vista bastante conhecido de "comentários às vezes podem ser um cheiro de código". Por exemplo, veja o resumo de Jeff Atwood, que inclui a pergunta "Você pode refatorar o código para que os comentários não sejam necessários?". Eu diria que, se o seu comentário está explicando por que o seu código é tão pouco intuitivo, pode ser definitivamente uma dica de que algo está errado. Em momentos como esse, é uma boa ideia simplificar o código. No entanto, concordo plenamente com a sua resposta real e assumo parênteses.
Daniel B
94

Importa menos se você está confiante em sua compreensão do idioma. O que importa mais é a compreensão do idioma do n00b que segue você.

Escreva seu código da maneira mais clara e inequívoca possível. Parênteses extras geralmente ajudam (mas nem sempre). Colocar apenas uma declaração em uma linha geralmente ajuda. A consistência no estilo de codificação geralmente ajuda.

Há muitos parênteses, mas é uma daquelas situações em que você não precisa de conselhos - você saberá quando vir. Nesse ponto, refatorar seu código para reduzir a complexidade da instrução em vez de remover parênteses.

Dan Pichelman
fonte
72
Não esqueça que, mesmo se você for um desenvolvedor solo quando estiver doente, cansado ou lidando com o código que escreveu no ano passado; seu nível de compreensão é reduzido ao de um n00b.
11113 Dan Neely
30
There is such a thing as too many parenthesis- você não é, obviamente, um lisper;)
paul
18
Esse é um mau conselho: não escreva para noobs. Isso reduzirá a qualidade do código (consideravelmente) porque você não pode usar expressões bem estabelecidas que vão além dos dois primeiros capítulos de um livro para iniciantes.
Konrad Rudolph
10
@KonradRudolph: talvez sim, mas não escreva para os únicos que conhecem a Art of Computer Programming de capa a capa, ou esteja preparado para ter que depurar seu código posteriormente e não tenha idéia de por que você fez as coisas dessa maneira . O código é lido muito mais do que está escrito.
haylem
15
@dodgethesteamroller: já vi muitos desenvolvedores competentes / respeitados introduzirem bugs de precedência (todo mundo tem um dia ruim de vez em quando) que passam despercebidos por muito tempo. Para bons desenvolvedores que conhecem as regras de precedência, o risco de erros / erros não detectados é muito alto. Para todos os outros, o risco é maior. Os melhores desenvolvedores são os que costumavam lembrar as regras de precedência da linguagem, mas as esqueciam devido ao uso habitual de parênteses para algo não óbvio.
Brendan
32

sim

Você sempre deve usar parênteses ... você não controla a ordem de precedência ... o desenvolvedor do compilador. Aqui está uma história que aconteceu comigo sobre o não uso de parênteses. Isso afetou centenas de pessoas durante um período de duas semanas.

Razão do mundo real

Eu herdei um aplicativo de quadro principal. Um dia, do nada, parou de funcionar. É isso aí ... só parou.

Meu trabalho era fazê-lo funcionar o mais rápido possível. O código fonte não foi modificado por dois anos, mas de repente parou. Tentei compilar o código e ele quebrou na linha XX. Olhei para a linha XX e não sabia dizer o que faria a linha XX quebrar. Eu pedi as especificações detalhadas para esta aplicação e não havia nenhuma. A linha XX não era a culpada.

Imprimi o código e comecei a analisá-lo de cima para baixo. Comecei a criar um fluxograma do que estava acontecendo. O código era tão complicado que eu mal conseguia entender. Desisti de tentar fazer um fluxograma. Eu tinha medo de fazer alterações sem saber como essa alteração afetaria o restante do processo, principalmente porque não tinha detalhes do que o aplicativo fazia ou de onde estava na cadeia de dependência.

Então, decidi começar no topo do código-fonte e adicionar freios à linha branca e à espinha para tornar o código mais legível. Percebi que, em alguns casos, havia condições combinadas ANDe ORque não eram claramente distinguíveis entre quais dados estavam sendo ANDeditados e quais estavam sendo OReditados. Então comecei a colocar parênteses em torno das condições ANDe ORpara torná-las mais legíveis.

À medida que me afastava lentamente, eu periodicamente salvava meu trabalho. A certa altura, tentei compilar o código e aconteceu uma coisa estranha. O erro saltou da linha de código original e agora estava mais abaixo. Então eu continuei, speparating o ANDe ORcondições com parênteses. Quando terminei de limpá-lo, funcionou. Vai saber.

Decidi então visitar a loja de operações e perguntar se eles haviam instalado recentemente algum novo componente no chassi principal. Eles disseram que sim, recentemente atualizamos o compilador. Hmmmm.

Acontece que o compilador antigo avaliou a expressão da esquerda para a direita, independentemente. A nova versão do compilador também avaliou expressões do código da esquerda para a direita, mas ambíguo, o que significa uma combinação pouco clara ANDe ORnão pôde ser resolvida.

Lição que aprendi com isso ... SEMPRE, SEMPRE, SEMPRE use parênteses para separar ANDcondições e ORcondições quando usadas em conjunto.

Exemplo simplificado

IF Product = 191 OR Product = 193 AND Model = "ABC" OR Product = 201 OR Product = 202 AND Model = "DEF" ...(código repleto de várias delas)

Esta é uma versão simplificada do que encontrei. Havia outras condições também com instruções lógicas booleanas compostas.

Lembro-me de encaminhá-lo para:
IF ((Product = 191 OR Product = 193) AND Model = "ABC") OR ((Product = 201 OR Product = 202) AND Model = "DEF") ...



Não pude reescrevê-lo porque não havia especificações. O autor original se foi há muito tempo. Lembro-me de uma pressão intensa. Um navio de carga inteiro estava preso no porto e não podia ser descarregado porque esse pequeno programa não funcionava. Nenhum aviso. Nenhuma alteração no código fonte. Só me ocorreu perguntar às Operações de Rede se elas modificaram alguma coisa depois que eu notei que adicionar parênteses alterava os erros.

Michael Riley - AKA Gunny
fonte
22
Isso parece uma ilustração melhor do por que é importante ter um bom compilador.
ruach
6
@CapeCodGunny: Tenho certeza que não. Mas o problema aqui é que você tinha um fornecedor ruim de compilador que fez uma alteração de última hora. Não vejo como você aprendeu uma lição para "SEMPRE, SEMPRE, SEMPRE" solucionar esse problema, mesmo ao usar melhores compiladores.
ruach
5
@ruakh - Não, o fornecedor simplesmente mudou seu analisador de código. Eu sou da velha escola, não confio na minha capacidade de lembrar de todos os sistemas em que codifiquei ou em que estive envolvido. Sem documentação, tudo o que você tem é o código-fonte. Quando o código fonte é difícil de ler e seguir, cria uma situação extremamente estressante. Programadores que não usam espaço em branco provavelmente nunca tiveram que lidar com uma situação como a que eu estava enfrentando. Também aprendi que faz mais sentido escrever código como: Veja Dick; Veja Jane; Veja Dick AND Jane; Declarações simples que são fáceis de ler ... comentar ... e seguir.
Michael Riley - AKA Gunny
2
Ótima história, mas concordo que não é uma razão para usar parênteses. e / ou precedência é quase universal e é a coisa menos provável de mudar em que se poderia pensar. Se você não pode confiar em um comportamento consistente para uma operação básica e padrão, seu compilador é lixo e você é processado independentemente do que faz. Sua história é 100% um problema do compilador e 0% um problema de código. Especialmente considerando que o comportamento padrão era simples avaliação da esquerda para a direita - a ordem sempre seria clara, então por que alguém usaria parênteses?
7
Eu acho que há lições aprendidas aqui dos dois lados ... É muito melhor usar parênteses, especialmente quando a alternativa é confiar no comportamento não documentado de um compilador em relação ao código ambíguo . E se o programador não souber quais expressões são ambíguas, melhor use parens. Por outro lado, é perigoso alterar o comportamento de um compilador, mas pelo menos gerou um erro nos casos em que o comportamento foi alterado. Seria pior se o compilador não tivesse emitido um erro, mas tivesse começado a compilar de maneira diferente. O erro protegeu você de bugs despercebidos.
Larsh
18

Sim, se houver misto 'e' e 'ou'.

Também é uma boa idéia () o que é logicamente uma verificação.

Embora o melhor seja usar funções de predicado bem nomeadas e remover a maioria das verificações e condições, deixando-as simples e legíveis.

Balog Pal
fonte
6
É verdade que há uma chance muito boa de a AND bprovavelmente ser substituída por uma função ou um valor boolen pré-calculado que tenha um nome mais descritivo.
Jeff Bridgman
14

Os parênteses são semanticamente redundantes, portanto o compilador não se importa, mas isso é um problema - a verdadeira preocupação é a legibilidade e compreensão do programador.

Vou assumir a posição radical aqui e dar um "não" caloroso aos parênteses a AND b OR c AND d. Todo programador deve saber de cor que a precedência nas expressões booleanas NÃO é E> OU , assim como lembrar Por favor, desculpe minha querida tia Sally por expressões algébricas. A pontuação redundante apenas adiciona confusão visual na maioria das vezes no código, sem nenhum benefício na legibilidade do programador.

Além disso, se você sempre usa parênteses em expressões lógicas e algébricas, renuncia à capacidade de usá-los como um marcador de "algo complicado está acontecendo aqui - cuidado!" Ou seja, nos casos em que você deseja substituir a precedência padrão e ter a adição avaliada antes da multiplicação, ou OR antes de AND, os parênteses são um bom sinalizador vermelho para o próximo programador. Muito uso deles quando não são necessários, e você se torna o Garoto que Chorou Lobo.

Eu abriria uma exceção para qualquer coisa fora do domínio da álgebra (booleano ou não), como expressões de ponteiro em C, onde algo mais complicado que expressões idiomáticas padrão como *p++ou p = p->nextprovavelmente deveria ser colocado entre parênteses para manter a desreferenciação e a aritmética retas. E, é claro, nada disso se aplica a idiomas como Lisp, Forth ou Smalltalk que usam alguma forma de notação polonesa para expressões; mas para a maioria das linguagens convencionais, a precedência lógica e aritmética é totalmente padronizada.

dodgethesteamroller
fonte
1
+1, parênteses para maior clareza são bons, mas ANDvs ORé um caso bastante básico que eu gostaria que os outros desenvolvedores da minha equipe soubessem. Eu me preocupo que às vezes "usar parênteses para maior clareza" seja realmente "usar parênteses para que eu nunca precise me preocupar em aprender a precedência".
Tim Goodman
1
Em todas as línguas que eu trabalho com regularidade é .memberantes de operadores unários, unárias antes de operadores binários, *e /antes +e -antes <e >e ==antes &&antes ||antes da atribuição. Essas regras são fáceis de lembrar porque correspondem ao meu "senso comum" sobre como os operadores são normalmente usados ​​(por exemplo, você não daria ==maior precedência do que +ou 1 + 1 == 2para de trabalhar) e cobre 95% das questões de precedência que eu teria .
Tim Goodman
4
@ TimGoodman Sim, exatamente certo, para ambos os seus comentários. Outros respondentes aqui parecem pensar que é uma questão em preto ou branco - use parênteses o tempo todo, sem exceções, ou voe descuidadamente pelo assento da calça por um mar de regras arbitrárias e impossíveis de lembrar, seu código transbordando com possíveis erros difíceis de detectar. (Metáforas mistas muito intencionais.) Obviamente, o caminho certo é a moderação; a clareza do código é importante, mas também o conhecimento de suas ferramentas, e você deve esperar de seus colegas uma certa compreensão mínima da programação e dos princípios de CS.
Dodgethesteamroller
8

Da maneira que eu vejo:

SIM Profissionais:

  • A ordem das operações é explícita.
  • Protege você de futuros desenvolvedores que não entendem a ordem das operações.

SIM Contras:

  • Pode resultar em código desordenado e difícil de ler

NÃO Profissionais:

  • ?

NÃO Contras:

  • A ordem das operações está implícita
  • O código é menos sustentável para desenvolvedores sem um bom entendimento da ordem das operações.
MetaFight
fonte
Bem dito, embora eu ache que "pode ​​resultar em código desorganizado e difícil de ler" é bastante subjetivo.
FrustratedWithFormsDesigner
2
Como tornar explícita a semântica do seu código dificulta a leitura?
Mason Wheeler
1
Eu concordo com os outros ao questionar seus "Sim Contras". Eu acho que é quase sempre o oposto.
@ Frustrado Tão subjetivo quanto a afirmação oposta. Significado, de forma alguma, realmente. Apenas difícil de medir.
Konrad Rudolph
1
@ MasonWheeler: Embora eu concorde que parênteses explícitas são muito importantes em muitos casos, posso ver como alguém pode exagerar ao tornar a semântica explícita. Acho 3 * a^2 + 2 * b^2mais fácil ler do que (3 * (a^2)) + (2 * (b^2)), porque o formato e a precedência são familiares e padrão. Da mesma forma, você pode (para ser extremo) proibir o uso de funções e macros (ou compiladores!) Para tornar a semântica do seu código mais explícita. Obviamente, não estou defendendo isso, mas espero responder à sua pergunta sobre por que precisa haver limitações (um equilíbrio) em tornar as coisas explícitas.
Larsh
3

Existem argumentos a favor ou contra, incluindo os parênteses estranhos? A experiência prática sugere que vale a pena incluí-los para facilitar a leitura? Ou é um sinal de que um desenvolvedor precisa realmente se sentar e se tornar confiante no básico de seu idioma?

Se ninguém mais tivesse que olhar para o meu código novamente, acho que não me importaria.

Mas, pela minha experiência:

  • Eu olho para o meu código novamente ocasionalmente (às vezes anos depois de escrevê-lo)
  • Outros às vezes olham para o meu código
    • Ou ainda tem que expandir / consertar!
  • Nem eu nem o outro nos lembramos exatamente o que eu estava pensando quando escrevi
  • Escrever código criptografado "minimizar a contagem de caracteres" prejudica a legibilidade

Quase sempre faço isso porque confio na minha capacidade de ler rapidamente e não cometer pequenos erros muito mais com parênteses do que nada mais.

No seu caso, eu quase certamente faria algo como:

if (a AND b) then ab = true
if (c AND d) then cd = true
If (ab OR cd) Then ...

Sim, é mais código. Sim, eu posso fazer operadores bool chiques. Não, não gosto da chance de, ao ler o código mais de um ou mais anos no futuro, interpretar mal os operadores booliques sofisticados. E se eu estivesse escrevendo código em um idioma que tivesse precedência diferente de AND / OR e tivesse que voltar para corrigir isso? Eu vou dizer: "aha! Lembro-me dessa coisinha inteligente que fiz! Não precisei incluir parênteses quando escrevi este ano passado, coisa boa que lembro agora!" se isso acontecer (ou pior, alguém que não estava ciente dessa inteligência ou foi jogado em uma situação do tipo "conserte o mais rápido possível")?

Separar com () torna muito mais fácil deslizar e entender rapidamente mais tarde ...

enderland
fonte
7
Se você vai fazer isso, por que não ab = a AND b?
Eric
1
Talvez porque abpermaneça inalterado, se não a AND b.
Armali
3

Caso Geral

Em C #, multiplicação e divisão têm precedência sobre adição e subtração.

Ainda assim, o StyleCop, uma ferramenta que aplica estilo comum em toda a base de código com um objetivo adicional de mitigar o risco de erros introduzidos por código que podem não ser suficientemente claros, possui a regra SA1407 . Esta regra produzirá um aviso com um pedaço de código como este:

var a = 1 + 2 * 3;

É claro que o resultado é 7e não 9, mas ainda assim, o StyleCop sugere colocar parênteses:

var a = 1 + (2 * 3);

Seu caso particular

No seu caso particular, há uma precedência de AND em comparação com OR no idioma específico que você usa.

Não é assim que todo idioma se comporta. Muitos outros tratam AND e OR igualmente.

Como desenvolvedor que trabalha principalmente com C #, quando vi sua pergunta pela primeira vez e li o trecho de código sem ler o que você escreveu antes, minha primeira tentação foi comentar que as duas expressões não são as mesmas. Felizmente, li toda a pergunta antes de comentar.

Essa particularidade e o risco de alguns desenvolvedores acreditarem que AND e OR têm a mesma prioridade torna ainda mais importante adicionar parênteses.

Não escreva código com o objetivo de mostrar que você é inteligente. Escreva um código com o objetivo de facilitar a leitura, inclusive por pessoas que talvez não estejam familiarizadas com todos os aspectos do idioma.

Arseni Mourzenko
fonte
1
"Isso é muito incomum": de acordo com Stroustrup2013, o C ++ 11 parece ter precedência diferente de AND e OR (p. 257). O mesmo para Python: docs.python.org/2/reference/expressions.html
Dirk
10
Re: "Todas as línguas que conheço tratam AND e OR igualmente": duvido que seja verdade. Se for verdade, você não conhece nenhuma das dez linguagens mais populares (C, Java, C ++, PHP, JavaScript, Python, C #, Perl, SQL e Ruby) e não está em posição de comentar. o que é "incomum", muito menos "muito incomum".
ruach
1
Eu concordo com a ruakh e procurei por C ++ 11, python, matlab e java.
Dirk
3
Os idiomas em que AND e OR são operadores binários, e que não tratam AND como tendo uma precedência mais alta que OR, são uma porcaria de danos físicos cujos autores são lacaios da ciência da computação. Isso vem da notação lógica. Olá, "soma de produtos" não significa nada? Existe até uma notação booleana que usa multiplicação (justaposição de fatores) para AND e o símbolo + para OR.
Kaz
3
@ruakh Você acabou de fazer o meu ponto para mim. Como existem vários casos de borda patológica, isso não significa que você não deve aprender a precedência booleana padrão e assumir que ela é válida até prova em contrário. Não estamos falando de decisões arbitrárias de design aqui; A álgebra booleana foi inventada muito antes dos computadores. Além disso, mostre-me as especificações de Pascal de que você está falando. Aqui e aqui mostram AND antes de OR.
dodgethesteamroller
1

Como todos disseram, use parênteses sempre que tornar a expressão mais legível. No entanto, se a expressão for complicada, aconselho a introduzir novas funções para as subexpressões .

Honza Brabec
fonte
0

Ou é um sinal de que um desenvolvedor precisa realmente se sentar e se tornar confiante no básico de seu idioma?

Se você usa estritamente a linguagem no singular, talvez. Agora leve todas as linguagens que você conhece, desde as mais antigas até as mais modernas, desde compiladas até scripts para SQL até sua própria DSL que você inventou no mês passado.

Você se lembra das regras de precedência exata para cada um desses idiomas, sem olhar?

Seguro
fonte
1
E como o @Cape Cod Gunny mencionou acima, mesmo se você acha que conhece o idioma frio, o compilador / tempo de execução pode mudar abaixo de você.
Jordânia
0

"Devo usar parênteses em declarações lógicas mesmo quando não for necessário."

Sim, porque duas pessoas os acharão úteis:

  • O próximo programador, com conhecimento, competência ou estilo pode ser diferente

  • O futuro você que retorna a este código em uma data posterior!

Michael Durrant
fonte
-1

Condicionais complexos são "álgebra booleana", que você escreve de várias maneiras que, bem, fazem com que pareça exatamente exatamente com álgebra, e você definitivamente usaria parênteses para álgebra , não é?

As regras realmente úteis são as negativas:

!(A || B) <=> !A && !B
!(A && B) <=> !A || !B

Ou, em um formato um pouco mais claro:

!(A + B) <=> !A * !B
!(A * B) <=> !A + !B

que é realmente claramente apenas álgebra quando escrito como:

-1*(A + B) = -A + -B
-1*(A * B) = -A * -B

Mas também podemos aplicar o pensamento para simplificação e expansão algébrica:

(A && B) || (C && D) => 
((A && B) || C) && ((A && B) || D) => 
(AC && BC) && (AD && BD) =>
AC && BC && AD && BD

embora no código você precise escrever:

(A||C) && (B||C) && (A||D) && (B||D)

ou, em um formato um pouco mais claro:

(A + B) * (C + D) => 
((A + B) * C) + ((A + B) * D) => 
(AC + BC) + (AD + BD) =>
AC + BC + AD + BD

Basicamente, um condicional ainda é apenas uma expressão algébrica e, usando claramente parênteses, você pode aplicar mais facilmente as várias regras algébricas que você já conhece à expressão, incluindo o conceito antigo de "simplificar ou expandir esta fórmula".

Narfanator
fonte
2
Não tenho certeza se você está realmente respondendo à pergunta, já que lidera sua resposta com uma suposição que não é necessariamente verdadeira. Eu usaria parênteses para álgebra? Nem sempre. Se isso ajuda na legibilidade, certamente, mas outros já expressaram isso aqui. E expandir a álgebra matemática em outras formas não tem exatamente uma correspondência individual com a programação - e se você estiver verificando o status de alguns valores de string?
Derek
Se a álgebra booleana correspondente for suficientemente complicada para justificar parênteses, seu condicional provavelmente deve usar parênteses. Se é simples o suficiente para não justificar parênteses, você não precisa, ou não deveria. De qualquer maneira, pensar nisso como se fosse uma expressão matemática provavelmente esclarece a questão.
Narfanator
Meus exemplos acima usam dois e quatro booleanos. Se você estiver verificando o status de dois ou mais valores de sequência, ele mapeia. Cada verificação corresponde a uma variável booleana; independentemente de essa verificação ser igual a um número inteiro ou a uma string; inclusão de string, array ou hash; uma expressão complexa em si ... Não importa; tudo o que importa é que você tem mais de uma medida de verdadeiro / falso em sua expressão.
Narfanator
2
Apenas nitpicking, mas dentro !(A + B) <=> !A + !Be -1*(A + B) = -A + -Bo operador não deveria ter sido mudado de +para *na segunda expressão?
22813 Jeff Bridgman
-1

Usarei parênteses, mesmo que seja opcional, porque porque ajuda a entender melhor para todos, para quem escreve o código e para quem está pronto para ver esse código. No seu caso, mesmo os operadores booleanos têm precedência, pode funcionar bem no início, mas não podemos dizer que o ajudará em todos os casos. então eu prefiro o parêntese do usuário em qualquer condição que possa exigir ou opcionalmente.

singa selva sankar
fonte
-1

Sim. Você deve usar em qualquer caso quando achar que seu código será mais claro. Lembre-se de que seu código deve ser claro o suficiente para que outras pessoas possam entender sem ler seus comentários dentro do código. Portanto, é uma boa prática usar parênteses e chaves. Lembre-se também de que isso pode depender da prática específica da sua empresa / equipe. Apenas mantenha uma abordagem e não se misture.

DesenvolvedorArnab
fonte