Reduzir o uso de ELSE no seu código, pode torná-lo mais limpo!

Em geral eu não gosto de artigos do tipo "não use X" ou "sempre faça Y". Muitas vezes eles usam apenas exemplos em que o uso (ou não-uso) é a melhor solução, e raramente mencionam os casos opostos (em que "quebrar a regra" seria benéfico). Ou só mencionam por cima que existem "exceções".

Não me entenda mal, eu acho importante saber sobre complexidade ciclomática, mas da forma que foi apresentado, um monte de iniciantes pode ler e achar que else é "do mal", ficar com medo de usar ou achar que tem algo errado em usá-lo, e acabar deixando o código pior só pra evitá-lo.

Sendo que existem casos legítimos para usar else, e nem sempre fica melhor tentar eliminá-lo a todo custo. Aliás, praticamente tudo em computação é assim, pra todo recurso e tecnologia existem casos de uso legítimos e situações em que existem soluções melhores. E também tem casos em que tanto faz.

Por exemplo, o early return:

function fazAlgo() {
    if (condicao)
        return;
    // Faz o resto
}

Nesse caso é OK, a condição indica uma situação na qual a função deve ser encerrada.

Mas e se tiver algo assim:

function fazAlgo() {
    if (condicao) {
        // Faz algumas coisas
    } else {
        // Faz outras coisas
    }
    // Faz o resto
}

Neste caso não tem como fazer o early return, pois existe um trecho que deve executar sempre depois do if/else, independente da condição ser verdadeira ou falsa.

Até daria pra argumentar que poderia quebrar em várias funções:

function cond() {
    if (condicao) {
        // Faz algumas coisas
        return;
    }
    // Faz outras coisas
}

function depoisCond() {
    // Faz o resto
}

function fazAlgo() {
    cond();
    depoisCond();
}

Mas aí precisa avaliar se vc escolheu desta forma porque faz sentido separar as funções (elas executam tarefas distintas e não faz sentido estarem juntas, por exemplo), ou se foi só pra poder evitar o else a todo custo. Se foi apenas pela segunda opção, então pra mim complicou o código à toa, pois o else na primeira versão do código não faz mal nenhum neste caso.

E na boa, independente da solução escolhida, vc continua tendo duas situações pra testar: uma na qual a condição é verdadeira, e outra na qual é falsa. O fato de eliminar o else não mudou isso.

O que acontece é que cada ferramenta pode avaliar de forma diferente cada um dos códigos e te dar a falsa impressão de um deles sempre ser "melhor". Por exemplo, algumas ferramentas (como o Sonar) consideram que cada return a mais adiciona complexidade, então o early return seria considerado "mais complexo". Outras ferramentas podem avaliar de forma diferente.

No fim, o ideal é sempre saber pra que serve e como funciona cada coisa, e usar a melhor opção de acordo com o contexto, em vez de se apegar a regrinhas ditas "universais", que dizem pra nunca (ou sempre) usar sem avaliar o que faz mais sentido.

Sim, é verdade. E pode torná-lo mais sujo. Depende do quanto a pessoa entende a computação como um todo e o quanto a pessoa só está seguindo uma receita de bolo que viu em rede social sem saber se a pessoa conhece o que está dizendo ou só repetindo o que outra falou, por isso em geral os exemplos são só em obviedades ou em caso ruim, a pessoa aprende a técncia mas não como usá-la corretamente, e é assim que ela começa treinar o erro.

Também é verdade que em muitos casos não faz muita diferença e a discussão é boba.

Algumas pessoas também pregam o single exit. E eu rebato em parte isso. Curioso como algo que era o suprassumo da programação agora é detestado e pregam o oposto. Mais uma coisa que mostra o que eu falei no primeiro parágrafo. As pessoas não adotam essas coisas porque entendem o que estão fazendo.

Eu falarei mais sobre como as coisas se tornam virais mesmo sem fundamento e sustentação. E o primeiro vídeo do meu canal falará no geral sobre isso e como estraga nossa indústria. Darei inclusive uma picelada na excrescência que é o tal do Object Calisthenics, nem tanto por ele, mas a motivação da adoação dele, e depois terá um vídeo só pra ele falando de cada um dos itens e porque você "deve" adotar ou não, mas nunca mais adotar algo porque alguém achou um título bonitinho e esse surubão viralizou.

Eu dei uma olhada por cima no original e os comentários, alguns ótimos e acrescenta algo importante que muita gente não percebe, alguns nem tanto (em geral os mais curtos), mas o mais importante é que existem casos que fica pior não usar o else e outros, mesmo que pareça ficar melhor, não expressa da maneira correta o que está se fazendo ali.

Aliás me deu a ideia de fazer algo sobre como o curto para aprendizado quase sempre é uma má ideia.

Todo artigo que mostre que tem um outro lado e não é uma "regra de ouro" merece meu positivo.

S2

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui no perfil também).

Use o comando que achar mais necessário no momento, sendo franco, acho esse tipo de discussão fruto de inexperiência ou coisa de iniciante. Não existe o certo ou o errado, mas sim o maís adequado para a diversa solução.