Pergunta

Checkstyle reclama do seguinte:

return (null == a ? a : new A());

e diz que os parens são desnecessários.

Embora a afirmação certamente funcione bem sem eles, parece muito mais legível com eles presentes-caso contrário, enquanto estou lendo, costumo ver:

return null

primeiro e depois tenho que fazer uma pausa para considerar o restante

== a ? a : new A(); 

parte, já que meu cérebro já seguiu um caminho.

Além disso, eu tendem a fazer a mesma coisa em qualquer momento Eu vejo um operador ternário, a menos que esteja agrupado em Parens.

Então: Parens em torno do ternário deve ser o padrão de fato? Há alguma razão para não colocá -los lá?

Foi útil?

Solução

Bem, o estilo de verificação está certo, os parênteses são inúteis para a execução. Mas inútil para a execução não significa inútil para a boa leitura do seu código. Você deve deixá -los se fizer mais sentido ler.

Eu acho que este código não precisa de mais parênteses:

int number = (myBoolean)? 1 : 2;

Mas no seu caso o return A palavra -chave e o fato de seu booleano uma expressão pode mudar a maneira como você lê a instrução.

Outras dicas

Ao ler uma declaração de devolução, sei que tudo entre 'devolver' e ';' É o que será devolvido, então não há como ler seu exemplo de código como retorno nulo, seguido por alguns símbolos, como você afirma que o lê.

Talvez ler as técnicas de análise possa ajudá -lo a vê -lo como eu. Dito isto, eu realmente não li sobre técnicas de análise, embora eu pareça alguns analisadores ao longo dos anos.

Eu sempre removo parênteses desnecessários. Eles não ajudam na compreensão do código, pois eu conheço muito bem a precedência do operador de Java. No momento estranho, não tenho certeza, adiciono parênteses e espero para ver se a ideia me diz que eles são redundantes. Então eu os removo e tento me comprometer com a memória da regra de precedência que acabei de descobrir.

Nas bases de código que eu herdei, costumo encontrar o maior número de parênteses redundantes em áreas de código que são ruins por outros motivos, por isso associo os dois.

Não, não deve ser o padrão de fato. Eu prefiro sem parens.

Eu acho que a única razão para colocá -los lá é forçar a ordem de avaliação ou esclarecer uma linha confusa.

Ambas as opções estão corretas, use o que sua equipe usa ou o que você gosta se estiver trabalhando sozinho.

O IIRC, por padrão, o estilo de seleção usa as diretrizes de estilo da Sun (RIP); portanto, se você deseja se conformar ao estilo padrão, ouça -o e remova as parens.

No geral, não.

Parênteses são não requerido em torno de operadores ternários (também conhecidos como condicionais) ou suas seções, porque sua precedência é muito baixa na ordem das operações (logo abaixo dos operadores lógicos e das atribuições acima). Veja o link abaixo para a tabela completa.

Pode -se argumentar, portanto, que essas parens desnecessárias desordem visualmente o código, e eles revelam um Falta de compreensão por parte do programador.

Exceções que podem exigir o uso de parens dentro ou nos ternários seriam:

  • Se o seu ternário for complexo o suficiente para merecer várias linhas; Você pode então cercar sua declaração em Parens para evitar a inserção automática de semicolon.

  • Se o seu ternário estiver aninhado dentro de outro ternário.

Veja também no MDN:

Como a base da sua pergunta tem a ver com o ato de leitura, abordarei a pergunta dessa perspectiva.

Um dos princípios básicos dos chamados programas de treinamento de "leitura rápida" é que eles tentam fazer o leitor desenvolver um gestalt da linha de texto em vez de ler-o sequencialmente palavra por palavra. Você pode tentar pegar uma página do livro e dar um passo atrás do seu código- literalmente, se necessário- para ter uma noção da linha completa, em vez de tratar o ato de ler como se fosse o ato de analisar o token por token.

Como alternativa, você pode usar um editor que permite configurar estilos: você pode tornar o operador ternário uma cor diferente para que ele salte para você. O Notepad ++, por exemplo, possui vários temas internos que fazem isso, assim como muitos outros editores.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top