A sintaxe para desativar o código é diferente da dos comentários normais?

8

Por várias razões durante o desenvolvimento, às vezes comento código. Como sou caótico e às vezes com pressa, alguns deles chegam ao controle de origem.

Também uso comentários para esclarecer blocos de código.

Por exemplo:

MyClass MyFunction()
{
    (...)
    // return null; // TODO: dummy for now
    return obj;
}

Mesmo que "funcione" e muitas pessoas o façam dessa maneira, me incomoda que você não consiga distinguir automaticamente o código comentado dos comentários "reais" que esclarecem o código:

adiciona ruído ao tentar ler o código
você não pode procurar código comentado, por exemplo, um gancho de confirmação no controle de origem.

Algumas linguagens suportam vários estilos de comentário de linha única - por exemplo, no PHP, você pode usar //ou #para um comentário de linha única - e os desenvolvedores podem concordar em usar um destes para o código comentado:

# return null; // TODO: dummy for now
return obj;

Outros idiomas - como o C # que estou usando hoje - têm um estilo para comentários de linha única (certo? Eu queria estar errado). Também vi exemplos de código "comentando" usando diretivas do compilador, o que é ótimo para grandes blocos de código, mas um pouco exagerado para linhas únicas, pois duas novas linhas são necessárias para a diretiva:

#if compile_commented_out
    return null; // TODO: dummy for now
#endif
return obj;

Assim, como o código de comentário ocorre em todos os idiomas (?), O "código desativado" não deve ter sua própria sintaxe nas especificações de idioma? Os profissionais (separação de comentários / código desativado, editores / controle de origem agindo sobre eles) são bons o suficiente e os contras ("não devem comentar de qualquer maneira", não são uma parte funcional de uma linguagem, um possível atraso no IDE (obrigado Thomas )) vale a pena sacrificar?

Editar

Percebo que o exemplo que usei é bobo; o código fictício pode ser facilmente removido, pois é substituído pelo código real.

comments syntax

— deltreme
fonte

Não vejo nada de errado nisso - comentar e descomentar pequenos blocos de código às vezes é uma tática útil para depurar bugs muito específicos em grandes bases de código herdadas. Acho que isso me ajuda a diminuir os problemas (além de usar um depurador adequado, é claro). Eu não me importaria de ver um tipo especial de comentário, talvez /# ... #/que gostaria de destacar de forma diferente no IDE (para sugestões visuais) e talvez gerar um compilador aviso que passaria então a ser preso e relatados em pelo nightly build se alguém se verificar tais alterações de volta no controle de origem.

— FrustratedWithFormsDesigner

18

Primeiro de tudo, no seu exemplo, existem comentários "TODO". Esses tipos de comentários são especiais de certa forma porque são detectados pelos IDEs (pelo menos Eclipse e Visual Studio) como um marcador para "tarefas". Mas tenho certeza que você sabe disso desde que você usa o thme, e suponho que você não esteja se referindo a eles quando usa o termo "código desabilitado".

Quanto ao código desativado, minha opinião é que ele polui o código. Eu uso outro mecanismo para acompanhar o que havia antes: o repositório de origem . Exceto quando estou no modo código / teste / código / teste ..., não comento código não utilizado, removo-o. E quando é o caso, comentar as linhas X é apenas uma questão de um atalho de teclado.

Edit: então sim, esqueci de responder sua pergunta explícita, acho que não é útil ter comentários especiais para código desativado. Se você realmente deseja manter o código, mas diz "não usá-lo", sempre pode marcá-lo como @ obsoleto, mas esse não foi o ponto da sua pergunta.

— Jalayn
fonte

Eu costumava escrever código sujo e tinha orgulho de usar "hacks" e correções rápidas, hoje em dia eu aprecio a estrutura - talvez eu possa me acostumar com isso também.

— Deltreme 22/08/11

2

TLDR; Use o controle de origem.

— Chris

1

@ deltreme Admito que estava fazendo a mesma coisa (mostre como "aprimorei" o código!) antes de começar a usar seriamente um repositório de origem em um ambiente profissional. Desde então, aprecio ter que ler o menor número de linhas de códigos que devo ler todos os dias.

— Jalayn

Use o controle de origem e examine os diffs antes de confirmar.

— UncleZeiv

1

Infelizmente, o foco das respostas está em como não comprometer o código desabilitado, não em quão tolo é o termo "comentar". Eu esperava mais de uma mistura. Aceitando esta resposta, como eu estava pedindo uma opinião, e você tem o apoio da comunidade: P

— deltreme

5

Por várias razões durante o desenvolvimento, às vezes comento código. Como sou caótico e às vezes com pressa, alguns deles chegam ao controle de origem.

Eu acho que essa é a raiz do problema. Ser caótico e apressado apenas introduzirá problemas. Descobrir por que seu desenvolvimento está sendo acelerado e não é bem controlado deve ser o primeiro passo, não tentando encontrar o código comentado.

Assim, como o código de comentário ocorre em todos os idiomas (?), O "código desativado" não deve ter sua própria sintaxe nas especificações de idioma? Os profissionais (separação de comentários / código desativado, editores / controle de origem agindo sobre eles) são bons o suficiente e os contras ("não devem comentar de qualquer maneira", não é uma parte funcional de um idioma) merecem ser sacrificados?

Acho que não. O código comentado é uma prática ruim e acho que os idiomas não devem incentivar ninguém a usá-lo. Sim, as pessoas fazem e eu já vi, mas me recuso a fazer o check-in do meu código comentado. Dar às pessoas a capacidade de gerenciar facilmente códigos antigos não utilizados está além do escopo de um idioma e é algo que pertence ao domínio do controle de versão.

Também estou preocupado com limitações técnicas. Para que isso funcione, você precisará analisar os comentários e determinar se eles estão comentados na fonte ou no texto ou adicionar um novo token ao idioma. Dependendo da complexidade atual do idioma, não tenho certeza de que impacto isso teria na compilação (identificando se uma linha é ou não um código válido a ser compilado). Além disso, as pessoas esperam que os IDEs gerenciem isso em tempo real (existe uma relação entre a complexidade da sintaxe de uma linguagem e a capacidade de resposta do IDE para encontrar e destacar várias construções e erros).

— Thomas Owens
fonte

Estou tentando gerenciar meu caos e pressa, e concordo totalmente que é onde tudo começa. No entanto, atualmente isso acontece e tenho certeza de que, assim que eu estiver livre do código de comentários, alguém substituirá o meu lugar. Talvez eu esteja apenas incomodando. No final, não é grande coisa. Quanto aos aspectos técnicos: os IDEs podem até tratá-los como comentários regulares, usar uma cor ou ocultá-los - muitos IDEs já suportam isso para outros elementos de sintaxe.

— Deltreme

@ deltreme Eu não me importo como os IDEs os apoiariam na superfície. Como os IDEs os encontram e processam de maneira precisa e mantém a capacidade de resposta? A adição de tokens a um idioma ou o processamento de texto pode retardar a análise ou gerar resultados imprecisos.

— Thomas Owens

Não achei que a discussão fosse desse modo :) E não acho que a adição de outro token (quantos IDE modernos reconhecem hoje em dia?) Resultaria em um editor com pouca resposta. Se você a vê como uma ameaça em potencial, mesmo na fase de pesquisa deste "projeto", você teria uma estimativa de qual seria a% de perda de desempenho? Digamos que adicionamos um token e queremos uma cor para ele em um IDE.

— Deltreme

@ deltreme Eu não acho que isso acrescentaria muito tempo para a maioria dos projetos, mas em termos de tempo agregado / valor agregado, a proporção é muito baixa. Se você tivesse que adicionar alguns microssegundos adicionais a dezenas de milhares de arquivos de origem, você adicionaria milissegundos a tudo que analisa um arquivo de origem, toda vez que analisa um arquivo de origem. Para um IDE, isso geralmente seria sempre que você salva. Também seria para suas compilações pós-confirmação e / ou diárias. Combine esses milissegundos e rapidamente se torna mensurável em minutos ao longo da vida útil de um projeto para lidar com um recurso que não agrega valor.

— Thomas Owens

1

@deltreme Absolutamente não. Se você desabilitou o código do seu projeto que entrou no controle de origem, está fazendo errado. Ocasionalmente, se estou reescrevendo um método, posso comentar o método antigo e reimplementá-lo, mas assim que tiver certeza de que o novo código passa nos testes e funciona conforme o esperado, removo o código desabilitado e faço o check-in. na verdade, verificar o código desabilitado ou confiar nele de alguma forma, é um sinal de problemas maiores no projeto que precisam ser abordados.

— Thomas Owens

4

Mesmo se houver apenas uma sintaxe de comentário no idioma que você está usando, você ainda pode adicionar seu próprio sabor a ele, trabalhei em projetos nos quais // denotava uma linha desativada e // - indicava um comentário. Não é tão bom quanto incorporá-lo, mas a maioria dos IDEs não sabe que você usou as sintaxes diferentes para diferentes propósitos; portanto, às vezes, a maneira antiga de observar os olhos para ver a diferença funciona melhor.

— Nicholas Smith
fonte

Se a equipe dedicar a esse sabor, certamente seria uma boa solução alternativa. É até "on-commit-hook", e se você esquecer os caracteres extras para algo que pretende comentar, isso também alertará.

— Deltreme 22/08/11

1

Em oposição às respostas, responderei com um "SIM, deve haver sintaxe diferente!"

Eu desafiaria qualquer desenvolvedor a dizer que eles passam pelo mesmo dia de codificação sem comentar o código. Fazer isso não significa que alguém não conhece o controle da fonte ou é preguiçoso. Mesmo como Thomas Owens diz em sua resposta dissidente: " Exceto quando estou no modo código / teste / código / teste ..., não comento código não utilizado " .

Quanto do seu tempo é gasto no modo código / teste / código / teste? Para mim, isso representa pelo menos 90% do trabalho! No momento, estou convertendo um grande projeto OSX para iOS, e o primeiro passo foi desativar todo o código que estava quebrando até que eu tivesse um esboço que funcionasse. Nas próximas semanas, vou lentamente descomentando e corrigindo o código à medida que o trabalho funcionar.

Existem muitos outros casos também. E quando você usa um código de exemplo, onde frequentemente encontra instruções como "Descomente o seguinte para Windows" ou "Descomente esta linha para aplicativos somente para iPhone"?

Sim, eu vou usar o controle de origem o tempo todo. Mas também SIM, eu adoraria que houvesse uma maneira de distinguir o código desativado dos comentários reais.

Em resumo: qualquer programador que disser que não usa comentários para desativar o código está mentindo. Há muito mais na codificação do que os arquivos polidos que você confirma no HEAD. Há muitos motivos válidos para o código desativado.

Sim, seria bom se houvesse uma sintaxe (ou pelo menos uma convenção) para distinguir os comentários verdadeiros do código desativado.

— Stan James
fonte