Escrever código morto é útil?

Você acha útil escrever código morto?

Alguns dizem "Se você tiver 2 lógicas para executar alguma operação, em vez de comentar ou remover outro código lógico, faça com que seja código morto, pois isso não afetará a operação".

Exemplo:-

if(true){
    // logic - 1
} else {
    // logic - 2  // dead code
}

É verdade?

Normalmente, não escrevo códigos mortos, apenas removo a segunda lógica.

IMO, é pior do que inútil.

Além de ser uma perda de tempo, isso dá a você (ou ao próximo cara) a ilusão de que você tem algum código que funcionará se você mudar truepara false. É apenas uma ilusão ... a menos que você a teste.

E, claro, é a confusão que torna o código mais difícil de ler.

Se você usar qualquer tipo de código morto do SCM, raramente será útil. Você deve excluí-lo e, se precisar ver o código da lógica 2, recupera-o do repositório SCM.

Editar:

Se você tiver um código morto e estiver mantendo outras partes do código, tente usar alguns códigos que podem ativar o código morto. Se alguém estiver fazendo a manutenção, talvez não conheça seu código realmente morto e, mesmo que saiba, certamente não saberá por que ele ainda está lá.

Se você achar que um método pode ser excluído, uma vez que não é usado pelo código "ativo", mas apenas pelo código morto, você deverá alterar (e provavelmente interromper) o seu código morto ou criar o próprio código morto do outro método.

No final, você certamente acabaria em algum tipo de inferno de manutenção.

Portanto, o melhor código é o código excluído, pois não pode produzir resultados errados ou distrair os mantenedores. :)

Não, isso é ruim, porque atrapalha seu código e reduz a capacidade de manutenção.

Geralmente, há um motivo claro para preferir uma das "lógicas" alternativas. Esse motivo (e a existência de uma alternativa rejeitada) deve ser documentado em um comentário de código. No caso relativamente improvável de o motivo se tornar inválido, o código alternativo pode ser recuperado do histórico do repositório (se era a solução implementada anteriormente preferida) ou aprimorado e implementado usando o conhecimento e os requisitos atuais completos (se for apenas um vago idéia).

Não afeta a operação, mas afeta a manutenção. Você deseja manter o código o mais organizado possível, para facilitar a manutenção.

Sinceramente, estou confuso com o que você está fazendo.

Em ordem decrescente de prioridade:

1. Você deve manter um registro das alterações de código em algum lugar para que, se o novo código não funcionar, você possa compará-las. Isso sempre deve estar no controle de origem. Presumo que você já faça isso. Caso contrário, faça todo o possível para obter ALGUM tipo de controle de origem. Se você absolutamente precisa ficar sem (e eu nunca ouvi falar de uma ocasião em que essa seja uma boa ideia), pelo menos faça backups regulares do estado da fonte facilmente acessíveis.

2. Supondo que você esteja executando o número 1, para recuperar o código morto, se necessário, NÃO o mantenha no código ativo a longo prazo. Será confuso, adicione complexidade extra sem valor, exija manutenção, fique fora de sincronia com o código ativo e engane as pessoas no futuro, etc., etc.

3. Dito isto, há situações específicas em que uma alternância em tempo de compilação entre dois caminhos de código é razoável. Enquanto você está desenvolvendo o novo código, e imediatamente depois, pode ser conveniente ter os dois, para que você possa alternar facilmente entre eles. Se é provável que você precise voltar ou adicionar uma opção de configuração externa, um if com base em uma constante fornece a esses um caminho de atualização razoável. Então, como muitas coisas - se estiver resolvendo um problema específico, faça-o. Caso contrário, evite-o.

A razão pela qual eu suponho que pessoas fazem isso demais é: de ter dúvidas (geralmente corretamente) de que as pessoas realmente lerão o histórico de controle de origem se tiverem um problema; de ficar com medo, o novo código não funcionará e desejar uma opção de reversão fácil. Um compromisso para tentar cumprir os dois pode ser colocar um comentário "Alterado para calcular ... em (Data). Se houver algum problema, consulte a versão antiga no controle de origem" ou similar.

Não, não é útil. Esse elsebloco não cumpre nenhum propósito. Se você não tiver certeza de qual implementação usar, comente-a, crie classes separadas ou salve-a em outro lugar. Além disso, na maioria das vezes você tem - ou pelo menos deveria ter - um histórico local ou remoto de seus arquivos de origem.

O código morto deve ser removido pelo compilador se a condição depender de uma constante de tempo de compilação, portanto, tecnicamente, não faria mal mantê-lo. No entanto, prefiro comentar isso, pois isso melhora a legibilidade do código.

Se você deseja alternar rapidamente entre duas alternativas de código, pode usar a seguinte construção de comentário conveniente:

//*
alternative 1 is active
/*/
alternative 2 is commented out
//*/

se você remover apenas o primeiro /na primeira linha de comentário, ele se tornará:

/*
alternative 1 is commented out
/*/
alternative 2 is active
//*/

Com isso, você pode alternar entre as alternativas apenas adicionando ou removendo uma única /no código.

Isso pode parecer um pouco estranho no começo, mas quando você se acostumar, você o reconhecerá facilmente como algum tipo de padrão.

Você pode até encadear isso e, assim, alternar vários blocos ao mesmo tempo com um único caractere:

//*
first block of code for alternative 1
/*/
first block of code for alternative 2
/*/
second block of code for alternative 1
/*/
second block of code for alternative 2
//*/

Eu não usaria dessa maneira, mas funciona.

Há ocasiões muito raras em que o código antigo e o fato de ter sido substituído devem permanecer no código-fonte, para que futuros programadores sejam avisados ​​sobre algo contra-intuitivo. Nesse caso, também é necessário algum tipo de comentário explicando por que ele ainda está lá e o que aconteceu.

Como sempre, escrever programas fáceis de manter tem a ver com tornar as coisas mais claras, e não apenas seguir regras rígidas e rápidas. Se deixar o código inoperante facilitar a compreensão do que está acontecendo, deixe-o dentro. Caso contrário, retire-o.

Será ignorado pelo compilador. No entanto, eu concordo com você e apenas removeria a declaração else. Supondo que você esteja usando o controle de versão, ainda poderá ver o código antigo exibindo o histórico do arquivo.

Essa é provavelmente uma opinião pessoal, mas acho que o código morto é perturbador ao manter um pedaço de código. Para qualquer tarefa, você sempre tem mais de uma maneira de realizá-la e, portanto, precisa escolher uma. Faça sua pesquisa, avalie os algoritmos e escolha um. Depois disso, o código não precisa conter nenhum método alternativo dentro dele.

Se houver dois candidatos muito fortes, escreva uma pequena nota sobre a alternativa e cole-a no wiki do projeto ou em algum outro lugar que contenha documentação do projeto. Se desejar, você pode colocar um comentário de uma linha que se refere a este documento e descreve por que você pode querer lê-lo.

Não consigo pensar imediatamente em uma situação em que achei útil escrever código morto. Se houver algoritmos alternativos, então:

• ou você mantém o mais útil e elimina o outro,
• ou os algoritmos são aplicáveis ​​a diferentes circunstâncias, e você mantém os dois e o condicional identifica as circunstâncias ao usar o primeiro algoritmo.

Em ambos os casos, você acaba sem código morto.

Se você não excluir ou comentar seu código morto, será necessário mantê-lo para evitar erros do compilador. É tempo perdido. Apenas exclua-o se você tiver um SCM.

NÃO

Alguns programadores usam esse estilo como uma alternativa aos comentários e o acham elegante.

if (1 == 0) 
{
    std::cout <<"I am a dead code capable of resurrection, once a programmer changes the condition!";
}

A resposta simples é um simples não. O código morto atrai confusão e oportunidades para a ocorrência de erros. Assim que você digita um caractere no código, há um risco. Portanto, não adicione mais do que você precisa.

A única vez que tive que escrever algo semelhante foi como uma solução alternativa para um bug do compilador, e até foi recomendado pelo fornecedor do compilador para usar essa solução.

Você testa código morto que escreve? Faça alguma coisa para confirmar que provavelmente é bom? Caso contrário, livre-se disso.

Para futuras alterações de código, você verificará se o código morto ainda funciona? Caso contrário, livre-se disso.

Você não deseja código ruim em seus programas, mesmo que não seja usado. Tê-lo lá sugere que ele pode ser usado. Você geralmente não deseja manter duas versões de código se não usar as duas, porque é um trabalho extra e, uma vez que parece inútil a maioria das pessoas não fará um bom trabalho com o código morto.

Pode haver razões para manter o código comentado (ou, em C ou C ++, #ifdefcódigo editado), mas isso deve ser acompanhado de comentários sobre por que ele ainda está lá e para que finalidade serve.

Observe que em Java, o seguinte nem será compilado devido ao código inacessível:

int someFunc() {
    return 10;
    int x = 12;
    return x;
}

Idealmente, se houver algo errado com o seu código, você deseja encontrá-lo o mais cedo possível, em vez de deixá-lo ir para produção e ser encontrado pelos usuários.

Se uma classe de erro puder ser encontrada pelo seu compilador, deixe-o encontrá-lo. O IMHO, o que alguém está fazendo escrevendo código morto da maneira que você descreve, está tentando contornar esse erro do compilador, permitindo que quaisquer problemas que possam causar sejam descobertos em tempo de execução.

Você pode argumentar que o código morto não pode ser alcançado, portanto, não pode causar problemas, mas algo pode dar errado nos comentários, nos preparando e na indentação que pode fazer isso acontecer.

A razão pela qual as pessoas comentam alguma lógica antiga é porque têm medo de fazer grandes alterações no código. E, de fato, perceber uma semana depois que o código antigo estava realmente correto e agora você precisa escrevê-lo do zero é uma droga. Mas é para isso que serve o controle de origem. Se você decidir mudar alguma lógica, não tenha medo de perder o código atual que está funcionando. Remova-o e deixe seu SVN / Git / TFS cuidar da versão para você.

Se não for o caso, e você acabou de produzir duas peças diferentes de lógica para fazer algo porque não se importa com YAGNI ou DRY, certifique-se de colocá-lo em algum lugar onde as pessoas possam usá-lo. Talvez jogue um padrão de estratégia lá, se lhe apetecer. Apenas não faça essas coisas "se .. mais", é um design ruim e uma dor de manter. Se você realmente acha que existe algum código certo, certifique-se de poder usá-lo.

Outro aspecto é que basicamente a maioria dos programadores profissionais concorda que o tamanho do código é o inimigo. Dê uma olhada nessas postagens do blog: O melhor código não é código de Jeff Atwood, o pior inimigo de Code de Steve Yegge, você pode encontrar muito mais.

As pessoas estão fazendo muitas coisas para manter seu código conciso e impedir que a base de código se torne grande demais, geralmente sacrificando o desempenho (onde isso não importa muito). Então, você realmente acha que 100 linhas de código morto podem ser uma coisa boa?

O único lugar em que vi isso útil é nos casos em que você deseja desativar rapidamente algo e testar / preencher (o programa Say executa as etapas A, B, C - tudo leva muito tempo. Durante o preenchimento, você pode optar por desativar B e C por enquanto, para acelerar, se você souber que não é necessário).
Mas a verdade é que em todos os casos isso é muito hacky. E se você vir um uso a longo prazo para o seu código de aterro, escreva-o de forma que ele use o config para escolher uma opção em vez de usar esses hacks.
Minha regra geral é que nunca se registra esse tipo de código. Se você precisar de um controle de entrada / versão, isso significa que você poderá voltar a isso em breve, e isso é sempre uma coisa ruim à luz das mudanças nos requisitos.

Na verdade, é útil ter um código "inoperante": quando você deseja que seu programa gere uma grande exceção, pois atingiu algo que nunca deveria ter acontecido. Isso seria um erro do compilador ou se alguém na linha alterasse a lógica no teste que você está usando e estragasse tudo. De qualquer maneira, o seu "outro" envia fogos de artifício. Nesse caso, você gostaria de defini-lo para lançamento.

É de vital importância que a mensagem de erro indique algo como "Pânico: nunca devemos estar aqui na linha% d no arquivo% s" ...