O 1 me lembra de criar uma palestra/vídeo/artigo chamado "Não faça testes!". Eu percebo que muitas pessoas (eu sou uma pessoa) não sabem fazer testes adequados, testando o que não precisa e deixando de testar o que é necessário, então a pessoas está só se inserindo na moda, não ajudando seu software ser melhor. POde ser que tenha algum ganho, mas não tão grande e muito mais trabalhos do que deveria. Testar é fazer código muito simples, mas exige entender muito bem o problema, a matemática e a computação. Isso falta para m uita gente. E precisa de experiência, eu não tenho ela tão boa mesmo depois de 40 anos fazendo isso, por uma razão básica, eu treinei o erro no passado, ficou difícil para mim.

O 2 muda a semântica do código e pode introduzir erros mais facilmente. Pode ser que o segundo exemplo seja realmente melhor, mas depende dos requisitos, mas aí o primeiro exemplo sequer caberia porque não atenderia os requisitos, a mudança da entrada de dados da função já indica a mudança. As pessoas confudem o que é DRY. Só com o contexto exato e concreto é que eu poderia escolher qual é o melhor.

Achar que existe uma regra de ouro é algo que iniciantes e experientes que aprenderam erraram e treinaram a vida toda assim, tornado-se teimoso, cometem muito. Eu vejo muito dessas regras nas redes sociais por aí e boa parte está pelo menos parcialmente erradas, ou seja, tem muita gente espalhando fake news apesar da boa intenção, muitas vezes ela está só reproduzindo o que ela aprendeu errado. Não é por acaso que o primeiro vídeo do meu canal se chamará "A péssima prática de seguir boas práticas".

O 3 indiretamente contém um mito muito comum no caso do laço. O exemplo mostrado é bom sim, se você puder varrer uma coleção em vez de ir lendo passo a passo, você deve fazer isso mesmo. Mas há casos que isso não é possível ou pode ser sensível na performance e precisa o método mais rápido , então o primeiro é melhor. O mito é que algumas pessoas não usaria a variável i, já vi muito falarem para usar contador ou algo do tipo. Isso não deixa mais legível, pelo contrário. Se ser verboso em vez e ser simbólico quando é universal, então COBOL seria a linguagem preferida das pessoas.Você tem que ser sompreendido, e todo mundo sabe o que é esse i , confunde até menos.

No 4 em geral as pessoas usam exemplo para evitar o if (anda bem popular fazer isso) que são simples, fáceis e realmente pode dar uma vantagem, mas ninguém mostra os casos que tentar fazer isso seria ruim. E a questão de separar em um método separado uma das ações que se faz depende de contexto para decidir se é o melhor a fazer, não é uma verdade absoluta. Não é tão comum, mas esse tipo de código pode dificultar a manutenção , quebrando em parte a coesão. Novamente, depende. Poderia ser que o if ali teria que estar dentro do aplicarDescontoVip(), masis uma vez, só dá para decidir sabwendo dos requisitos reais.

A lição é: não siga receitas de bolo, entenda o que está fazendo. Inclusive porque tem contextos que pode fazer de qualquer jeito que está bom.

Quanto mais pratica o erro, menos aceita o certo.

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).