O problema com o aninhamento de ternários em JavaScript

Durante anos, os desenvolvedores discutiram sobre a maneira mais legível de aninhar ternários. O operador condicional ternário é uma alternativa às instruções if/else que tomam decisões com base em uma condição. Como o operador condicional é uma expressão que retorna seu resultado, é tentador aninhar outras expressões nas ramificações.

Recentemente, a popular solução de formatação JavaScript, Prettier, lançou uma nova maneira de formatar esses ternários aninhados sob um sinalizador experimental, e essa solução está ganhando força.

No entanto, a realidade é que os ternários não deveriam ser aninhados. Existem opções melhores que não apenas realizam o trabalho, mas também de uma forma que prioriza código limpo: código que é consistente, intencional, adaptável e responsável. Todos os desenvolvedores escrevem código com esse objetivo em mente (ou, pelo menos, deveriam).

Então, por que o aninhamento de ternários é um problema tão grande? E o que os desenvolvedores podem fazer para eliminar a prática e garantir que o código que está sendo escrito siga os princípios do código limpo tanto quanto possível para produzir software de alta qualidade? Vamos cavar.

Código complicado de ternários aninhados

Não me interpretem mal, Prettier é uma ferramenta muito importante para o ecossistema JavaScript, ajudando-nos a escrever código formatado de forma consistente, que se adapta bem ao princípio da consistência: uma das quatro propriedades do código limpo que todos os desenvolvedores devem se esforçar para escrever .

Mas centenas de comentários em torno da formatação de ternários aninhados de Prettier deixam claro que nunca haverá consenso sobre a melhor forma de usar ternários aninhados. Aqui está a solução: elimine-os completamente.

Os ternários aninhados servem apenas para confundir o código e funcionam diretamente contra outra propriedade do código limpo: o código deve ser claro e direto. Ternários aninhados raramente são uma dessas coisas e, na verdade, exigem que os codificadores escolham pontos de interrogação e dois pontos para determinar o significado de uma expressão. Por outro lado, as declarações if/else explicam o significado com muito mais clareza.

Não estou sozinho neste pensamento. Por exemplo, SonarQube, SonarCloud e SonarLint impõem a regra de que os operadores ternários não devem ser aninhados como parte do perfil Sonar way, para garantir a qualidade e clareza do código.

Então, o que os desenvolvedores deveriam fazer?

Existem melhores opções

Primeiro, vejamos um exemplo dos ternários aninhados de Prettier:

A maneira mais fácil de substituir um ternário aninhado aqui é transformá-lo em condicional. Para fazer isso, você precisa configurar uma variável para atribuir na instrução condicional. Inicie a variável com seu valor padrão para salvar uma cláusula else. Em seguida, aplique a mesma lógica do exemplo original, mas com blocos if/else. Será assim:

Alguns desenvolvedores argumentam contra esse estilo por causa do uso do let variável. Aqui, um operador ternário tem a vantagem de ser uma expressão – portanto, ele retorna um valor, enquanto as instruções if/then não retornam nada, o que significa que você precisa alterar uma variável ou usar return.

Se isso não parecer certo, você pode refatorar a instrução em sua própria função e usar retornos antecipados. Isso significa que você pode testar a funcionalidade de forma independente para ter certeza de que está correta e não pode quebrar involuntariamente. Como bônus, você também pode eliminar a atribuição de variável extra.

Agora removemos os ternários, mas o aninhamento permanece. Independentemente da sintaxe, quanto mais você aninha o código, mais complexo será o seu entendimento. A melhor coisa a fazer é reduzir ao máximo a quantidade de aninhamento. Neste exemplo de código, podemos agora pegar nossa função e refatorar o aninhamento.

O ato de remover operadores ternários e refatorar o aninhamento resultou em um código mais curto, mais testável e, em última análise, mais claro.

Por que aninhar ternários?

Com clareza em mente, é fácil imaginar por que os desenvolvedores escrevem ternários aninhados. Alguns especialistas apontam a diferença entre afirmações e expressões, observando que as expressões nos encorajam a evitar efeitos colaterais e mutações. Isso pode ser feito por meio de “ternários encadeados”, nos quais você executa operações nas condições para garantir que só poderá encadear no else cláusula do ternário.

Aqui está o ponto: usar uma instrução if/else no lugar de uma expressão significa que você precisa escrever um código que cause efeitos colaterais. Mas se você reduzir uma condicional ao código que pode ser escrito como um ternário aninhado, poderá evitar esses efeitos colaterais e mutações reescrevendo-o como uma função com retornos, como fizemos acima. Mas como nada impede você de escrever mutações e efeitos colaterais em um ternário, o argumento parece inútil.

Esses desenvolvedores do campo dos ternários aninhados também argumentam que a sintaxe de uma instrução if/else cria confusão e ocupa memória, causando interferência e deixando mais espaço para bugs. Intercâmbio ifs e elses para pontos de interrogação e dois pontos certamente ainda deixa espaço para bugs também. Mesmo que os ternários aninhados usem menos caracteres do que a alternativa, eles ainda podem criar confusão e falta de clareza no código que as instruções if/else evitam. Para muitos desenvolvedores, ter que traduzir a sintaxe ternária torna mais difícil detectar bugs durante a manutenção do que usar código mais detalhado.

Parte disso pode se resumir à preferência pessoal e à maneira como cada desenvolvedor pensa. Além disso, os usuários de JSX sabem que não é possível usar instruções if/else diretamente em JSX. Isso exige o uso de operadores ternários para tomar decisões, o que leva ao aninhamento quando você está renderizando componentes condicionalmente e incluindo atributos condicionais.

No final das contas, ainda é do interesse do desenvolvedor minimizar ternários aninhados sempre que possível para escrever o código mais claro, legível e consistente possível.

Clareza em vez de Brevidade

O problema com o aninhamento é a complexidade que ele introduz inatamente ao código, onde devemos sempre buscar simplicidade e clareza. Ao ver um ternário aninhado, a primeira coisa que você precisa fazer é refatorar o aninhamento o máximo que puder e, em seguida, usar os padrões que mencionei para remover completamente os ternários aninhados.

É verdade que as alternativas usam mais caracteres e exigem que o desenvolvedor digite mais, mas criam um produto final muito melhor e de leitura mais fácil. Como lemos código com mais frequência do que o escrevemos, é especialmente importante manter essa experiência em mente durante o processo de codificação.

Não dê ouvidos ao exagero que chama essas declarações if/else de “feias” – a aparência não importa tanto quanto um resultado claro e legível que é mais fácil para todos entenderem e mudarem ao longo do tempo, independentemente de o desenvolvedor original estar fazendo isso. as modificações ou não. Afinal, escrever código que seja legível e compreensível para o maior número de desenvolvedores é a chave para a criação de software de alta qualidade que beneficiará uma empresa nos próximos anos.

A postagem O problema com o aninhamento de ternários em JavaScript apareceu pela primeira vez em The New Stack.