C # comenta sobre el cierre {}

Question

¡He estado trabajando un poco con DevExpress CodeRush y Refactor! Pro esta semana, y recogí un complemento de comentarista que generará automáticamente comentarios a medida que escribes código.

No quiero analizar qué tan bueno es el trabajo de elegir el significado básico (bastante bueno, en realidad), pero su implementación predeterminada plantea una pregunta.

De forma predeterminada, al escribir un carácter} para cerrar un bloque, el complemento agregará un comentario como el siguiente ...

using(MyType myType = new MyType())
{
    myType.doWork();
} // using

(es decir, agregar un comentario al etiquetado de llaves de cierre donde se abrió)

Si bien puedo ver que hay casos en los que este comportamiento puede ser de gran utilidad, creo que el código resultante se ve muy desordenado con todos los comentarios adicionales.

Me preguntaba qué otras personas tomarían este tipo de comentario. No solo desde un punto de vista académico, sino que si recibo una buena cantidad de comentarios negativos sobre ellos, puedo decidir si los inflijo a mis compañeros de trabajo o los despojo.

Answer 1

Creo que comentarios como ese son inútiles, a menos que, por supuesto, el código sea horrible. Con el formato adecuado del código, no es difícil ver dónde comienza un bloque y dónde termina un bloque porque generalmente esos bloques están sangrados.

Editar: Si un procedimiento es tan grande que no es evidente qué bloque de código se está cerrando con una llave, entonces ya debería haber comentarios más descriptivos que describan el procedimiento de todos modos y estos comentarios serían simplemente desordenados.

Answer 2

La idea de un complemento que genera comentarios del código me parece bastante inútil. Si puede ser inferido por la máquina, entonces también puede ser inferido por cualquiera que lo lea. Es muy probable que los comentarios sean totalmente redundantes.

Siento que los comentarios de cierre de llaves son desordenados, brindan información que el IDE proporciona mejor directamente si la persona lo desea.

Answer 3

IMO cada comentario que describe lo que el código ya le está diciendo es innecesario.

Si realmente tienes bloques de código que son tan largos que tienes que desplazarte mucho para comenzar, has hecho algo mal y puedes considerar dividir el código.

Answer 4

Estilo de comentario incorrecto incorrecto: introduce una sobrecarga de mantenimiento en la base de código.

He conocido a ex codificadores de VB que encontraron que los rastros de } s en el código de sintaxis C eran confusos, pero en este escenario la solución real es refactorizar su código para evitar el anidamiento profundo y funciones y / o bloques de código excesivamente largos.

Answer 5

Tal vez sea útil si el bloque de uso se extiende sobre una página en el IDE, pero luego tiene otros problemas de los que preocuparse. En este caso, me las arreglo con una sangría adecuada y un IDE que resalta la llave correspondiente cuando selecciono uno.

Le doy un pulgar hacia abajo en general, pero con un uso potencial cuando no puede evitar un bloqueo largo de lo contrario.

Answer 6

A veces obtendrás bloques de código muy grandes, o muchos bloques anidados que se cierran juntos. A veces uso este estilo en casos como este, pero definitivamente no todo el tiempo. Tampoco lo restrinjo al código: HTML puede beneficiarse enormemente de este estilo de "comentarios cercanos":

<div id="content">
    <div id="columns">
        <div class="column">

            <!-- .. snip a lot of lines .. -->

        </div> <!-- .column -->
    </div> <!-- #columns -->
</div> <!-- #content -->

Answer 7

Este tipo de comentarios solo son útiles en bloques de código muy largos donde tiene muchos bloques anidados. Pero dicho esto no debería ser el caso en primer lugar, ya que muchos bloques anidados y métodos largos requieren una refactorización. Así que no me gusta para nada, ya que el lector obviamente puede ver qué bloque de código es.

Answer 8

Creo que más útil que los comentarios sería una función IDE para resaltar no solo pares de llaves coincidentes, sino también mostrar la línea de apertura en una información sobre herramientas, de modo que si se cernía sobre la llave de cierre en su ejemplo, aparecería " utilizando (MyType myType = new MyType ()) " en una información sobre herramientas.

Esto le permitiría comprender fácilmente las llaves anidadas complejas para funciones grandes sin proporcionar un desorden visual constante.

Answer 9

Siempre me parece útil recordar esto ...

El código claro y bien escrito proporcionará una explicación suficiente de lo que está haciendo el código para que un programador competente lo detecte.

Deben dejarse comentarios en el código para explicar por qué el código lo está haciendo

En otras palabras, use comentarios para ayudar al lector de su código a comprender el algoritmo, o lo que se supone que el código debe lograr , ¡no cómo lo está logrando!

Es posible que desee consulte esta publicación de Jeff Atwood .

Answer 10

No lo hagas, simplemente agrega ruido si se usa por todas partes, y además de la sangría adecuada debería resolver el problema de legibilidad.

Answer 11

Lo mantendría apagado. Solo veo un punto en usar esto cuando tienes varios bloques que terminan en el mismo lugar (bloques más largos o más cortos). Los he usado yo mismo en algunos casos como estos. Sin embargo, si se usan, sería mejor agregarlos manualmente, en lugares cuidadosamente seleccionados en lugar de tener alguna herramienta automatizada que los agregue.

Answer 12

Si tiene que considerar si un cierto tipo de comentario es utilizable o no, lo más probable es que sea este último.

Los comentarios son para explicar ciertos bloques de código o una entidad en su conjunto, para facilitar la comprensión; no para que el formato sea más fácil de leer.

Tener un complemento siempre conforme a este comportamiento es a la vez obeso y feo.

Answer 13

Estoy de acuerdo en que hay formas mucho mejores de describir lo que está haciendo un código.

Si tiene un largo cuerpo de código precedido por un solo comentario informativo como // Arreglar el elemento de trabajo, puede tomar ese código y refactorizarlo como su propio método. Luego use el comentario como el nombre del nuevo método, FixWorkItem (). Hacer esto es una forma rápida de hacer que su código sea más autodocumentado e incluso podría revelar algunas características de diseño que no notó antes.

Esté atento a los comentarios de una línea como esos posibles refactores, que el IDE puede manejar automáticamente. El código que documenta en sí mismo es mejor que incluso los comentarios independientes mejor escritos, excepto, por supuesto, cuando se describe la intención.