sirve settitle que para java comments curly-braces

settitle - Comentario de Java al final de la llave/bloque



para que sirve settitle en java (6)

Depende de qué tan complicado sea el método o la función. Al igual que si tiene algo que pueda leerse y entenderse fácilmente, no tendría sentido terminar CADA línea con un comentario que explique que la parte ha finalizado. Para eso sirven las sangrías y los saltos de línea. Sin embargo, si tiene algo que es verdaderamente complejo y afecta una parte importante de su código, debe indicar dónde termina ese código y qué hace esa sección.

¿Es una práctica aceptada en el lenguaje de programación Java finalizar un refuerzo para un bloque de código con un comentario que explica brevemente qué bloque de código cierra el corsé? Personalmente, creo que son comentarios inútiles que complican la legibilidad del código, pero quizás podría estar equivocado. Por ejemplo:

public void myMethod(int foo) { // some code if (foo == 2) { for (int i = 0; i < myMax; i++) { while (true) { // some more code } // end while } // end for } // end if } // end myMethod(int)

¿Es la práctica de comentar bloques de código de manera similar una práctica aceptada?


Esto no es exactamente una mala práctica, ¡pero es un efecto secundario mortal de la pobre práctica de codificación orientada a objetos!

Además, esto viola las pautas de estilo y los principios del "código de auto-documentación" . Nunca debe tener tantos corchetes o un método lo suficientemente largo como para confundir al lector acerca de la ubicación del bracket, sino que debe encapsular esa funcionalidad en otro método que esté bien documentado.

Los corchetes implican bucles o cadenas lógicas if-else complejas, una buena práctica de programación es hacer que un método haga exactamente una cosa y hacerlo bien, luego construya su programa a partir de estos métodos más pequeños y atomizados. Leería la pieza seminal de Butler Lampson "Sugerencias para el diseño de sistemas informáticos" . Va en algunos de los detalles sobre cómo diseñar un buen software.

Así que esencialmente, no hagas comentarios como este porque:

  1. Viola las pautas de estilo
  2. Muestra una pobre programación orientada a objetos: atomiza tu funcionalidad.
  3. Es un efecto secundario mortal de la práctica de codificación que va en contra de los conceptos subyacentes de por qué se creó Java: encapsulación, específicamente ocultamiento de información
  4. Viola el concepto de código de auto-documentación
  5. Otros programadores se burlarán de ti.

IMO, no ayuda mucho. El código dentro de un bucle o una declaración if no debe ser demasiado grande. Hubiera ayudado si hubiera 500 líneas dentro del circuito.


Mi opinión es que, por regla general, NO es una buena práctica. Como siempre con las reglas, podría haber excepciones pero muy raras.

No es una buena práctica porque

  1. Los editores modernos resaltan el corchete de apertura cuando coloca el cursor en el de cierre y viceversa.
  2. Lo más importante: si existe la posibilidad de no ver el comienzo de la cláusula, significa que el método es enorme (más de media página), lo cual es una mala práctica.
  3. Agrega ruido al código que confundirá a los lectores que están acostumbrados al estilo de codificación Java más convencional.
  4. Incorporación de LordScree-Joachim Sauer comentario : Estos comentarios serán un dolor en el cuello para mantener. Por lo tanto, lo más probable es que no se mantenga y la información generalmente no estará sincronizada con la realidad.

Si hay bloques anidados del mismo tipo, puede ser confuso en lugar de hacer el bien. Supongamos que tiene 4 o 5 declaraciones anidadas si (tenga en cuenta que esto es solo un ejemplo para demostrar la situación, independientemente de "oh debe separar esas" o "hacer un método" sugerencias) en ese caso tendrá 4 o 5 diferente // final si está secuenciado. Después de un tiempo, te hace confundir qué "fin si" es para qué enunciado, te hace gastar un esfuerzo extra inconscientemente para ver a través del código / enunciados reales porque no siempre es tan limpio / corto como tu ejemplo.


Solo hago esto cuando hay un lugar en el código que tiene muchas llaves de cierre una detrás de otra. Pero no para cada llave. Principalmente, parece que lo uso para bucles para que pueda ver fácilmente lo que es un bloque de código repetido.

Algo que se parece a esto:

// ... file.Close(); } } } } } }

Luego, ayuda agregar algunos comentarios:

// ... file.Close(); } } } }//for: each file } }