C # comentários sobre fechamento {}
https://stackoverflow.com/questions/323837
-
11-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPergunta
Eu tenho trabalhado um pouco com DevExpress CodeRush e Refactor! Pro esta semana, e eu peguei um plug-in commentor que irá gerar automaticamente comentários enquanto você digita o código.
Eu não quero entrar em quão bom um trabalho que ele faz de escolher significado básico (muito bom, na verdade), mas de implementação padrão faz levantar uma questão.
Por padrão, digitando um caractere} para fechar um bloco irá resultar no plugin adiciona um comentário como o seguinte ...
using(MyType myType = new MyType())
{
myType.doWork();
} // using
(i. Adicionar um comentário à rotulagem fechamento cinta onde foi aberto.)
Enquanto eu posso ver que há casos em que esse comportamento pode ser de grande utilidade, sinto que os olhares de código resultantes muito desarrumado com todo o adicional de comentar.
Eu queria saber o que outras pessoas; 's opinião sobre este tipo de comentário foi. Não apenas do ponto de vista acadêmico, mas se eu conseguir um bom número de comentários negativos sobre eles eu posso decidir se a infligir-lhes sobre os meus colegas de trabalho ou tira-los.
Solução
Eu acho que comentários como esse são inúteis, a menos que o código é horrível. Com a formatação adequada do código não é difícil ver onde um bloco começa e onde um bloco termina, porque normalmente esses blocos são recuados.
Edit: Se um procedimento é tão grande que não é facilmente perceptível o bloco de código está sendo fechado por uma cinta, em seguida, já deve ser mais comentários descritivos que descrevem o procedimento de qualquer maneira e estes comentários seria apenas desordem.
Outras dicas
Acho que a idéia de um plugin que genrates comentários de código bastante inútil. Se pode-se inferir pela máquina, em seguida, ele também pode ser inferida por ninguém lê-lo. Os comentários são extremamente provável que seja totalmente redundante.
Eu sinto que aqueles comentário fechamento cinta é confuso, ele dá a informação que é melhor fornecida diretamente pelo IDE se o indivíduo quer.
IMO cada comentário que está descrevendo o que o código já está lhe dizendo é desnecessário.
Se você realmente tem blocos de código que são tanto tempo que você tem para se deslocar muito para ver lá começando você tenha feito algo errado e pode considerar dividir o código-se.
Bad estilo de comentário ruim -. Introduz uma sobrecarga de manutenção na base de código
Eu conheço codificadores ex-VB que encontraram rastros de }s em código C-sintaxe para ser confuso, mas, neste cenário, a correção real é refatorar seu código para evitar profunda nidificação e funções excessivamente longos e / ou blocos de código .
Talvez útil se o bloco usando estende-se por uma página no IDE, mas então você tem outros problemas para se preocupar. Neste caso, eu consigo com recuo adequada e um IDE que destaca a cinta de correspondência quando eu selecionar um.
Dou-lhe os polegares para baixo em geral, mas com potencial de uso em que você não pode evitar um bloco longo de outra forma.
Às vezes, você vai ficar muito grandes blocos de código, ou um monte de blocos aninhados fechar juntos. Às vezes eu usar este estilo em casos como este, mas definitivamente não o tempo todo. Eu não restringi-la ao código seja: HTML pode beneficiar muito com este estilo de "fechar comentando":
<div id="content">
<div id="columns">
<div class="column">
<!-- .. snip a lot of lines .. -->
</div> <!-- .column -->
</div> <!-- #columns -->
</div> <!-- #content -->
Este tipo de comentários são útil somente em longos blocos de código onde você tem muitos blocos aninhados. Mas disse que isso não deve ser o caso, em primeiro lugar como muitos blocos aninhados e métodos longos chamar para refatoração. Então, eu não gosto deste em tudo, como o leitor, obviamente, pode ver o bloco de código que é.
Eu acho mais útil do que comentários seria uma característica IDE, não só para destacar pares de chaves de correspondência, mas também exibir a linha openining em uma dica de ferramenta, de modo que se você pairou sobre a chave de fechamento no seu exemplo que viria com "usando (MyType myType = new MyType ())" numa dica.
Isso permitirá que você facilmente fazer sentido de chaves aninhadas complexas para grandes funções sem fornecer confusão visual constante.
Eu sempre achar útil lembrar disso ...
Limpar, código bem escrito irá fornecer o suficiente de uma explicação de o o código está fazendo para um programador competente para buscá-lo.
Os comentários devem ser deixados no código para explicar por o código está fazendo isso!
Em outras palavras, usar os comentários para ajudar o leitor do seu código entender o algoritmo, ou o que o código é suposto alcançar , não como é consegui-lo!
Você pode querer confira este post por Jeff Atwood .
Não faça isso, ele simplesmente acrescenta ruído se usado em todo o lugar e, além disso recuo adequada deve resolver o problema legibilidade.
Gostaria de mantê-lo desligado. Eu só vejo um ponto em usar isso quando você tem vários blocos que terminam no mesmo lugar (blocos mais longos ou mais curtos) - Eu usei-me em alguns casos como estes. No entanto, se eles são usados, seria melhor para adicioná-los manualmente, em locais cuidadosamente selecionados em vez de ter alguma ferramenta automatizada de adicioná-los.
Se você tem que considerar ou não um certo tipo de comentário é utilizável ou não, é mais provável que o último.
Os comentários são para explicar certos blocos de código ou uma entidade no seu todo, para aliviar-se na compreensão; não para fazer a formatação mais fácil de ler.
Ter um plug-in sempre estar de acordo com este comportamento é tanto obesos e feio.
Eu concordo que há maneiras muito melhores para descrever o que um código está fazendo.
Se você tem um longo corpo de código precedida por um único comentário informativo como // Fix item de trabalho, você poderia tomar esse código e refatorar-lo como seu próprio método. Em seguida, use o comentário como o nome do novo método, FixWorkItem (). Fazer isso é uma maneira rápida de fazer seu código mais auto-documentado e pode mesmo revelar algumas características de design que você não percebeu antes.
Mantenha-se atento para comentários de uma linha como essa como potenciais refatora, que podem ser manipulados automaticamente pelo IDE. Código que os documentos em si é melhor do que até mesmo os melhores escrito observações independentes, exceto, claro, quando se descreve intenção.
