O código comentado realmente é ruim? [duplicado]

O benefício do # ifdef ao invés de comentá-lo, é que (em grandes projetos) você pode ter as definições listadas em um arquivo make ou config - e por isso não precisa ir manualmente para descompactar coisas, construir, e depois re-comentar se for em muitos lugares. A desvantagem disso é que alterar o DEFINE do projeto geralmente significa reescrever a coisa toda, não apenas os arquivos alterados.

Embora ... eu acho que o "código comentado é uma coisa ruim" realmente se refere a código morto que as pessoas simplesmente não queriam apagar por qualquer motivo (medo de jogar fora algo que gastou tempo em talvez?). Não é realmente sobre a situação que você tem para você.

Se ele for comentado, ele pode apodrecer: quando você de repente decide que precisa dele novamente, percebe que ele não compila mais, ou precisa ser reescrito para se adequar a outras coisas que mudaram nesse meio tempo.

Se você deixar o código, mas de tal forma que o compilador pode otimizá-lo se não for necessário, então você se beneficia de manter o código atualizado e não tendo que sofrer o tamanho binário adicionado ou o desempenho do tempo de execução.

Por exemplo, em C, isso está em risco de apodrecer:

/*
doSomeDebugStuff();
*/

E assim é:

#if 0
doSomeDebugStuff();
#endif

Mas isso é bom, já que ele sempre é verificado quanto à validade pelo compilador, mas provavelmente será otimizado:

if (0)
{
  doSomeDebugStuff();
}

Editar: como outros indicam, usar um símbolo significativo em vez de 0 para o teste é ainda melhor.

Acho que é necessário fazer uma distinção entre o código com comentários obsoletos e o código usado apenas em uma compilação de depuração (ou outra compilação "especial", compilada condicionalmente). Este último é uma prática comum, e nada está errado com isso.

O primeiro não deve estar presente em uma base de origem, já que o sistema de controle de versão mantém o controle das coisas obsoletas, caso você queira recuperá-lo.

// The problem with commented out code is that it can hide what you're actually
// trying to say in a wall of text.  Syntax highlighting may help, but you're 
// still left with this huge ginormous wall of text in front of you, searching
// through it for what the actual answer is. You'd think that mentally it'd be 
// really easy to disregard the comments, but in actual usage, it's a lot harder
// than a one word answer that can tell you what you're looking for. It's tough.
/* Sometimes they'll even through you off with different comments. */ Yes.
// It's really tough to deal with people that don't like to use source control, 
// that would rather comment lines and lines of code instead of deleting the 
// code and checking in revision.  Cue irrelevant paragraph about the reason why 
// I wrote this instead of just deleting the entire block and replacing it 
// with my intention. Maybe I was hedging my bets? Cue misspelled wrod.  

Quase não há "sempre" na codificação :) Se você sabe o suficiente sobre as razões por trás de uma diretriz e tem uma boa razão para quebrá-la, faça isso.

Por exemplo, eu comento o código quando faço "refatoração kamikaze" e preciso de um lembrete visual para adicionar as coisas de volta ou lembrar como o código antigo funcionou por algum tempo. É crucial em casos como este que você irá apagar os comentários mais tarde, caso contrário, eles simplesmente irão confundir seu código.

Às vezes, você coloca o código em seus comentários para mostrar como usar uma classe - isso é muito diferente do código de comentários que costumava ser executado.

Eu faço muitas revisões de código e descubro que não há desculpa real para o código comentado, independentemente do motivo. Se você estiver usando o código comentado para fins de depuração, poderá criar um mecanismo de rastreamento que esteja desativado no modo de liberação ou tenha níveis de rastreio (sempre é bom poder rastrear em uma versão) ou simplesmente usar um depurador.

O código comentado é ruim porque quando outras pessoas lêem o código - especialmente quando você está estressado tentando corrigir um bug quando o autor original está ausente em férias - é muito confuso ler o código, especialmente se o erro for de um errado colocado // no início da linha ... mesmo usando / * você pode por acidente comentar algo que deveria estar lá - ou não.

Para manter seu código limpo e mais legível, remova o código comentado, já é difícil ler os programas como estão, sem precisar ler código que pode ou não ser significativo.

Sim, é.

Mesmo que você tenha um código de depuração que não deseja em sua versão de produção, você não deve comentá-lo. Usar #ifdef é melhor, porque você pode ativar e desativar a depuração facilmente com uma macro #define ou com uma configuração de compilação separada. Isso definitivamente é melhor ter que entrar no código e comentar / descomentar cada bloco do código de depuração manualmente.

E se você precisar de flexibilidade para ativar alguns blocos de depuração, mas não para outros, agrupe os blocos de depuração em "níveis de depuração".

Uma solução melhor seria não usar o pré-processador e usar os recursos da linguagem nativa, como constantes e instruções if. Então, ao invés de

#define DEBUG0
#ifdef DEBUG0
  // debugging code
#endif

você pode ter

const bool DEBUG0 = true;
if(DEBUG0)
{
  // debugging code
}

A vantagem de fazer isso, usando o pré-processador, é que seu código de depuração sempre será verificado pelo compilador. Isso diminui a probabilidade de apodrecer quando você altera o código em torno dele.

Você não sofreria nenhum impacto no desempenho se tornasse a bandeira booleana falsa, porque os compiladores modernos otimizam o código inacessível. Na pior das hipóteses, você pode receber um aviso do compilador sobre isso.

Eu não acho que o que você está fazendo seja ruim, mas acho que no mínimo você deve ter alguns comentários reais para explicar o que está fazendo, por que e como e quando usá-lo.

Pessoalmente, eu normalmente colocaria esse tipo de coisa em algum tipo de esforço IF DebugMode = TRUE em torno do código em questão e configuraria isso como um parâmetro de linha de comando / inicialização. Para mim, é mais fácil ver que é por isso que o código está lá e como defini-lo na sua instância. Pode haver problemas de desempenho, mesmo com essa pequena comparação que você deseja evitar.

Então eu provavelmente veria o que você está fazendo como um mal necessário ao invés de sair e errar. Se você puder encontrar alguma maneira de simplificá-lo, então, obviamente, faça isso, mas eu não me critico por isso.

Acho que uma das razões pelas quais o código comentado é considerado um cheiro de código é que ele indica que o programador que o colocou lá não entende o controle de origem ou que não está usando nenhum. Qualquer um deles lança mais dúvidas sobre muitas outras coisas que eles estão fazendo também.

Se você tiver um motivo legítimo para e , deixe uma explicação do motivo pelo qual ele é legítimo, pois ele pode ser encontrado. A maioria das coisas que geralmente são consideradas más notícias também pode ser uma ferramenta útil nas mãos certas. O problema é que essas mãos são mais raras do que as pessoas que pensam tê-las.

Isso ajuda a fornecer um histórico de como a mente dos programadores estava trabalhando no momento. Mas nesses dias de controle de origem onipresente, não há motivo para deixá-lo em um corte final - as versões anteriores conterão o código mais antigo, caso você precise se referir a ele.

Eu não acho que haja absolutos aqui. Eu às vezes deixo o código comentado quando é apenas um pequeno trecho, especialmente se houver uma chance razoável de que eu o descomentei em breve. Basicamente eu deixo esses trechos desde que eles não atrapalhem a legibilidade do código real, e desde que eles não se multipliquem em todos os lugares.

O que eu absolutamente rejeito são métodos completos de código com comentários. Sim, eu já vi isso antes: WTF. Eles podem descansar no paraíso da revisão de fontes; -)

Use o comentário se o seu programa for modificado por outras pessoas ou se você estiver modificando o trabalho de outras pessoas. Você não quer que outras pessoas excluam seu código e, mais tarde, ele descobriu que seu código estava melhor. Além disso, se você enviar um programa modificado por você, que foi escrito por outro e, em seguida, o programa falhar, ore para que você tenha apenas comentado o código original pelo seu colega para que você possa reverter a alteração. Estou dizendo a situação quando a empresa não usa um sistema de controle de versão.

Você também comenta seu código se quiser referenciar seu código mais tarde, por exemplo, tentando uma abordagem diferente para o mesmo objetivo.

O comentário não afeta o desempenho da linguagem compilada ou da linguagem baseada em máquina virtual.

Se alguém achou o comentário realmente irritante, ele pode usar um IDE melhor com a função de ocultar alguns comentários selecionados.