Mas isso não é importante, por que ta funcionando!

Da lista de respostas incômodas, essa está na top 3. Por que funciona!

Ela é normalmente ouvida em resposta a perguntas feitas sobre um trecho de código com bad smell, mas que “roda”, como quando você encontra 3 for-loop  alinhados, ou o nome do banco de dados é galinha-pintadinha, ou a variável chama $opaloompa.

Bad smell é um negócio interessante por que só quem teve de agir como pai, cuidando de um software, como manager, sabe quando. A criança está cagada. Os outros apenas desconfiam.

E ai vem a resposta por que sim. Eu tenho me esforçado para pensar que o por que sim não é fruto de maldade, que ele vem da simples falta de reflexão sobre o problema-objetivo, a saber.

Querido programador, o código é escrito para outro programador, não para o bendito do computador.

Então, não é e nunca será a mesma coisa escrever

Function __pegaoValorqueQuero($x, $y)
{
  if ($x < 42 && $y > 0)
    return true;
}
return false;

}

E

Function ehRespostaValida($tentativa)
{
  $respostaCorreta = 42;
  if ($tentativa == $repostaCorreta)
    return true;
  return repostaAceitavel($respsotaCorreta, $tentativa); 
}

function respostaAceitavel($absoluta, $tentativa)
{
  $sejaPositivo = 0;
  return ($tentaviva < $absoluta && $tentativa > $sejaPositivo);

}

Agora vamos a outros detalhes:

Bons programadores simplesmente não conseguem avançar na codificação se não conseguirem nomear corretamente o que estão fazendo por que percebem que se ainda não são capazes de dar nome ao que estão fazendo.

Nomes das coisas
Nomear é uma das coisas mais difíceis no ato de programar, chego a dizer que bons programadores simplesmente não conseguem avançar na codificação se não conseguirem nomear corretamente o que estão fazendo por que percebem que se ainda não são capazes de dar nome ao que estão fazendo, é muito provável que ainda não saibam o que fazer e voltam para a análise. Nomes não são frescura, se fosse, eu podia dizer que… Deixa pra lá.

Código duplicado
Você olha o código e vê o mesmo trecho de linhas escrito em dois métodos.
Pior, você vê dois métodos idênticos mas um deles está sufixado com um 2[ metodo($x), metodo2($x,$y) ],  e tem um parâmetro a mais.

Querido diário, hoje eu matei uma pessoa quando ela me disse “o outro método estava funcionando e eu não quis mexer”.

Métodos longos
Aqui tem uma boa, um passarinho me disse que já viu um método cujo nome tinha uns 200 caracteres, parece que a justificativa do programador foi que o gerente falou para ser bem descritivo em todo código que escrevesse.

Se o método faz duas coisas ele está fazendo uma coisa a mais do que deveria.

Então, se ele chama
IncrementaVarisvelESalvaNoBanco
Ele está gritando que faz duas coisas, gritando!!!

Por fim, eu te pergunto, se até beber por beber perde a graça e faz mal, por que programar por programar?

Por causa de métricas? Seu chefe conta o número de linhas que você adiciona no código todo dia? Apague linhas e adicione funcionalidades refatorando o que achar importante e prove que ele não está certo.

Quando você escreve menos de 50 linhas por dia sua consciência pesa? Veja quanto de funcionalidade e efeito colateral você entrega com 50 linhas e se comprometa com 10 linhas para o mesmo entregavel e sem efeito colateral algum e durma melhor, sem precisar de valium.

Por que Deus quis? deuses não programam, eles usam a biblioteca chamada Chuck Norris e comando de voz/Siri para poder dizer: faça-se a luz!(e algum arduíno acender uma luz via ip do outro lado da sala).

Não confunda produtividade com efetividade.

Os melhores programadores nao produzem código, eles produzem soluções e de preferência sem escrever uma linha sequer. Eles são profissionais em resolver problemas.

Agora, se você quiser continuar programando no estilo Steve Wonder, saiba que sempre vai existir a indústria da manutenção de software. Eu até já ouvi uma vez de um gerente que podia entregar assim mesmo que depois o cliente pagava pela manutenção.

Nesse caso amigo, vou vai arder no mármore do inferno.