¿Un programador experimentado desarrolla el hábito de comentar más líneas de código mientras programa?

Ah, el tema irritante del código de comentarios.

Un comentario no debe especificar el “cómo” de lo que hizo, sino el “por qué”.

¿Qué significa esto en la práctica? Un programador de computadoras crea una instancia de una solución cuando escribe código. El código es una implementación del algoritmo elegido, una abstracción que puede escribirse en pseudocódigo, cuyos ejemplos abundan. Mis propios favoritos se pueden encontrar en Introducción a los algoritmos: Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest, Clifford Stein: 9780262033848: Amazon.com: Libros.

El programador con savoir faire no intentará ser demasiado original demasiado tiempo. Después de todo, ¿para qué son los profesores de informática, si no para escribir libros sobre algoritmos?

El programador se encargará de escribir el código de tal manera que se documente, asegurando así que el comentario explique la elección y no el propósito.

Por supuesto, eso no es lo que sucede todo el tiempo. Una última reflexión: un comentario que no se actualiza cuando se cambia el código es peor que inútil, ¡casi el pecado capital de la programación!

Escribiendo código para dinero desde 1979, para el diablo desde 1976.

Obtuve la religión de “comentar el código, maldita sea” hace unos 10 años en mi carrera cuando volví a leer un código que había escrito unos años antes y no podía entenderlo. Sabía lo que estaba haciendo el código y cómo lo hacía, pero había olvidado por qué las cosas se escribieron de la manera en que se escribieron.

Lo que me di cuenta es que el código no puede responder a todas las preguntas. Puede responder “qué” y “cómo” y “cuándo” la mayor parte del tiempo. Pero el código no puede responder “¿Por qué? No, no, en serio, ¿por qué escribiste esto de esta manera? ¿Por qué haces esto en absoluto?

Estoy 100% de acuerdo con todas las quejas sobre demasiados comentarios y comentarios completamente inútiles, y los comentarios de “Perdí mi llamado como programador de COBOL”.

Mi herramienta favorita para administrar los comentarios es doxygen, y cuando escribo Java me aseguro de utilizar los comentarios Javadocs tanto como sea posible.

Pero, por favor, si todo lo que puede escribir es “Inicializar foo a bar tiempos murmura”, no se moleste. Averigua por qué foo se está inicializando para silenciar los tiempos de bar y explica eso. Además, use los formatos de comentarios BLOCK para que cuando el código se refactorice inevitablemente, la persona que lo haga no tenga que eliminar todos los comentarios de fin de línea. Necesitan ser prohibidos.

Solía. Pero luego cambié a comentar menos.

Lo que cambió mi opinión, sobre esto y muchas otras cosas, fue el libro Refactorización de Martin Fowler [1]

Un comentario a menudo puede ser un indicador clave de que su código no es fácil de entender.

Si este es el caso, como

  // Escribe 'string' para registrar la salida 
 void qr_dis (String string) {
   lgr.info (cadena); 
 } 

entonces es mejor refactorizar el comentario en un nombre de método

  void outputToLog (String descriptiveText) {
   logger.info (descriptiveText);
 }

Nunca antes había visto comentarios a esa luz. Tan pronto como lo hice, tenía sentido.

Más allá de la legibilidad, el objetivo es obtener la información del comentario en el código, de modo que a medida que el código se cambie más tarde, el comentario no se desactualice.

Esto no quiere decir que todos los comentarios sean malos.

Los más útiles incluyen:

• Resumen de módulos
• Descripciones de interfaz / API
• Explicación de por qué se utilizó este enfoque y por qué se descubrió que otros más obvios no funcionan

Pero incluso para los dos primeros, un caso de prueba con un ejemplo de trabajo suele ser mejor y se mantiene actualizado.

Notas al pie

[1] Refactorización: Mejora del diseño de código existente (serie de tecnología de objetos): Amazon.co.uk: Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts: 9780201485677: Libros

En mi opinión, hay tres tipos de comentarios.

Comentarios como documentación en línea que describe en ‘lenguaje humano’ lo que hace el código.

Los comentarios de Gotcha describen un truco no trivial que tuvo que ser implementado por varias razones (por ejemplo, me viene a la mente la incompatibilidad del navegador, aunque es difícil descartar la inexperiencia).

Comentarios que dividen largos tramos de código.

El primero es posiblemente el menos útil. Si realmente desea documentar su API, creo que un archivo de documentación separado es un lugar mucho mejor para ello. Si escribe documentos dentro de su código, se verá obligado a corregir los documentos cuando cambie su código, por lo que se convierte en una carga de mantenimiento. Llegué a la conclusión de que no vale la pena.

El segundo tipo me parece muy útil. Incluso en mi propia base de código, puedo encontrarme con un código que parece que no pertenece allí, hace algo que no es obvio y siento la necesidad de arrancarlo. Ahí es donde un recordatorio amistoso sobre su propósito puede ser útil. Ahora, puede argumentar hasta la muerte que dicho código no debería existir en primer lugar, pero la realidad es que no se nos paga para escribir código elegante, sino para hacer el trabajo con las habilidades que tengamos.

El tercer tipo de comentario es probablemente un poco controvertido. Hay programadores que sin duda señalarán que (a) no debería tener largos tramos de código y (b) debería dividir dicho código en varias funciones con nombre. Antes de discutir sobre estos puntos, déjame mostrarte un ejemplo:

  función foo () {
   // Analiza la entrada
   ... bla, bla, 10 líneas de código ...
  
   // Realizar consulta
   ... bla, bla, 20 líneas de código ...

   // Preparar y devolver salida
   ... bla bla bla 5 líneas de código ...
 }

Ahora los programadores que piensan que esto es una tontería pueden hacer algo como esto:

  función foo () {
    parseInput ()
    performQuery ()
    return prepareOutput ()
 }

En la superficie, puede verse todo limpio y ordenado, y corto. Pero ahora te enfrentas a otro problema. Debe ubicar el código para las tres funciones en algún lugar de la base del código para descubrir qué hace foo() . Otro problema con este tipo de ‘código de autodocumentación’ (y no estoy diciendo que esto es lo que debería llamarse código de autodocumentación) es que las tres funciones rara vez son genéricas. En otras palabras, rara vez merecen ser funciones. Entonces (a) si el código tiene sentido, y está haciendo lo que se supone que debe hacer (y nada más que eso), no hace ninguna diferencia qué longitud tiene, y (b) romper cosas por nombrar secciones de código hace que el código sea más difícil de leer. En cambio, solo uso comentarios.

Al principio sí, luego todo lo contrario. Hace mucho leí en alguna parte, algo así como:

• El novato no comenta nada, porque no sabe de tal cosa.
• El oficial comenta todo, para asegurarse de que esté claro.
• El maestro aclara el código y solo comenta para explicar por qué usó esa lógica.
• El gurú solo comenta por qué no usó otra lógica.

No, diría que en realidad es lo contrario.

Mientras que sé de algunos programadores mediocres que evitarían cualquier comentario y llamarían a cada variable con una letra, etc., la mayoría sería bastante generosa con sus comentarios.

Sin embargo, las cosas cambian, la gente cambia.

En mi caso personal, comencé:

• siguiendo patrones de diseño (no religiosamente pero aún así …)
• escribir código “autodirigido”, con nombres de variables / funciones / clases decentemente descriptivos.
• Más espaciado (tanto vertical como entre operadores, etc.), con sangría agradable y consistente. Para los desarrolladores de PHP, recomiendo aprender a codificar conforme a los estándares PSR [1]. La mayoría de los otros idiomas también obtienen sus “estándares de codificación / formato mejor aceptados”.
• Menos funciones de aspecto de “muro de ladrillo”, reemplazadas lentamente por funciones de “una / pocas tareas”.
• Menos “programación defensiva” (típica del nuevo desarrollador), a favor de la responsabilidad asignada con mucha precisión a capas específicas de código. Por ejemplo, realice comprobaciones completas del usuario final en el “controlador frontal” (si usa un paradygm de desarrollo de patrones MVC), mientras que su modelo (o “funciones de back-end”) tienen pequeñas comprobaciones y simplemente hace lo que se les pasa.
• Macrobloques más estructurados y consistentes. Por ejemplo, el uso de MVC proporciona una buena separación de preocupaciones (de código). MVC es solo una de las muchas soluciones de trabajo, siempre y cuando una solución ayude a estructurar el código, está bien.
• Más inyección de dependencia, menos clases de “hacerlo todo por sí mismo”. También ayuda a crear pruebas unitarias más fáciles y mejores.
• Cree API / interfaces cuando den claridad a porciones de código.
• Utilice PHPDoc / JavaDoc o cualquier otro documento o estándar. No se trata solo de crear documentos bastante automatizados, sino de enseñar disciplina para crear documentación consistente y bien formateada. Menos cantidad, más calidad en la documentación es una base para un código bien hecho y fácilmente compartido. Con el beneficio adicional de necesitar menos comentarios.

El resultado final de este crecimiento personal: su código se convierte en su documentación.

Lo que escribí anteriormente parece casi obvio, pero tiene que hacerse “realmente suyo”, una actitud mental. No viene en un mes, ni en un año. Pero es tan bueno cuando sucede, es uno de esos: “¡DING! ¡Nuevo nivel de desarrollador de Nirvana alcanzado! ”Momentos!

Notas al pie

[1] Recomendaciones de estándares PHP

Sí, creo que los comentarios son una señal de un programador experimentado. No hay comentarios en cada línea de código. Eso llevaría mucho tiempo y gran parte sería inútil, pero creo firmemente en comentar a nivel de clase y método. Un método debe tener una descripción básica, así como una descripción de los parámetros y sus tipos, así como el tipo que devuelve. (y lo que representa ese valor). También se requieren comentarios a nivel de módulo.

Muchos IDEs en realidad tienen características para facilitar esto también. Los productos JetBrains son un gran ejemplo. Cuando estoy en PyCharm, tan pronto como escribo tres comillas y presiono intro cuando estoy justo debajo de la definición de un método, agrega la repetitiva para comentarios, por lo que puedo comentar un método en menos de 30 segundos. Eso puede ser muy útil para alguien que viene después de mí, o incluso para mí 6 meses después. WebStorm tiene una característica similar.

Me resulta frustrante entrar en un código que carece de comentarios. Por supuesto, siempre debe usar nombres descriptivos también, pero no creo que los comentarios puedan reemplazarse totalmente con eso personalmente. Por un lado, ‘descriptivo’ es algo subjetivo. Además, observa que muchas personas que abogan por nombres descriptivos EN LUGAR de comentarios mencionan que comenzaron a hacer esto después de convertirse en desarrolladores experimentados. Claro, estoy de acuerdo en que usted mismo requiere comentarios menos cuanto más experiencia tenga, pero siempre habrá desarrolladores junior, y ellos necesitan esos comentarios. No solo estás comentando por ti mismo. De hecho, es principalmente para aquellos que ingresan al código después de usted. Sé amable y déjalos una o dos palabras para que no tengan que perseguir sus historias.

Además, si eres uno de esos desarrolladores junior, comentar realmente puede ayudarte a aprender. Intenta comentar un método ANTES de escribirlo. Eso lo mantendrá enfocado en lo que se supone que debe hacer ese bloque y no permitirá que crezca fuera de su alcance previsto. (es decir, la definición de alcance tradicional, no OO)

Nombres descriptivos y comentarios, es el enfoque más profesional en mi opinión.

Como con la mayoría de los otros que ya han respondido esta pregunta, estoy en el campo de “menos pero mejores comentarios”. La práctica en la que participo y que animo a todos a hacer es escribir un código de “autodocumentación” o de “autoevaluación”. Esto significa escribir código que sea en sí mismo legible para los humanos (de todos modos, en el mejor grado posible) y organizado lo suficientemente bien como para que incluso un programador novato pueda al menos tener una idea de lo que el código está tratando de hacer.

Los programadores avanzados generalmente escriben comentarios suficientes para guiar a otros (compañeros de equipo, consumidores, etc.) a través de un problema complejo, pero no solo usan nombres descriptivos para sus variables y nombres de métodos, sino que también dividen su código en bloques más pequeños para que puedan escriba sus métodos públicos más como esquemas que como implementaciones completas. Este proceso a veces se denomina “Esquemas, no ensayos”, y la técnica de factorización asociada se conoce como SECO – “No te repitas”.

Pero incluso entonces, es posible que no pueda escapar sin escribir algunos comentarios para describir lo que está haciendo. Por lo general, escribo comentarios que explican por qué elegí un enfoque particular, para aclarar cosas que son oscuras (por ejemplo, expresiones regulares y formatos de cadena), para aclarar qué espera una función como entrada (por ejemplo, una cadena CSV entrante: aclarar cómo funciona la cadena será interpretado), etc. Cosas que no son inherentemente obvias en la implementación pero que son importantes para que alguien las conozca, especialmente cuando espero que alguien más interactúe con mi código.

Hay un buen equilibrio.

Los programadores principiantes tienden a escribir comentarios no suficientes o demasiados, y generalmente el tipo incorrecto de comentarios. Por ejemplo:

  def first_element_of_list (mi_lista):
     "" "Función que devuelve el primer elemento de la lista" ""
	 return my_list [0] # devuelve el primer elemento de la lista

La función extremadamente trivial anterior, que devuelve el primer elemento de una lista (si tiene una, es decir), en caso de que aún no se haya dado cuenta, no necesita ningún comentario, especialmente debido al nombre descriptivo de la función que hace que el comentario obsoleto y la descripción del código en sí. Los comentarios no agregan nada; por el contrario, distraen del código ya legible.

La cantidad de comentarios requeridos disminuye a medida que aumenta la calidad de su código, ya que el código en sí debería haberse vuelto más legible. Por ejemplo, pasar de grandes fragmentos de código a descomponer el código en diferentes funciones que hacen una cosa hace que el código sea mucho más legible.

La calidad de los comentarios en sí también cambiará con el tiempo. Un buen comentario dice por qué estás haciendo algo, no lo que estás haciendo. Esto último debería ser obvio por el código mismo.

En conclusión, los buenos programadores no usarán tantos comentarios, ya que su código está bien escrito y desglosado en fragmentos legibles, mientras que también usan nombres descriptivos que pueden reemplazar los comentarios. Sin embargo, utilizarán comentarios selectivamente para indicar por qué están haciendo algo.

Sin embargo, solía comentar más, como se indicó anteriormente; El código limpio es un código legible. Lo que significa más no es que puedes leerlo sino también; puedes entenderlo

Ahora uso los comentarios más como valores de búsqueda de palabras clave que conducen a la función, clase u otro. De esta manera, permite a otros desarrolladores realizar una búsqueda rápida en el código y encontrar palabras clave en relación con lo que están buscando. Es como una función de búsqueda de puerta trasera integrada en el código fuente, sin tener que escribir una función de búsqueda.

Si estoy usando escape o funciones dentro de funciones, comentaré qué opciones están disponibles. Si es un constructor, clase, etc; Voy a comentar qué variables (globales) están disponibles para usar / aprobar / buscar en el código.

Los comentarios deben mantenerse al mínimo. Su primer objetivo es un código limpio, legible y entendido. Segunda razón por la cual mantener los comentarios mínimos, aunque está comentado; aún se leerá (par se). Por lo tanto, reducir el número de valores ignorados es óptimo para el procesamiento.

Al final deberías minifundir tu código. El código final “a producción” en evaluaciones como JavaScript, JS e incluso PHP no debería tener comentarios en la fuente. Intento asegurar esto por dos razones.

1. Motivos de propiedad intelectual (propiedad intelectual). En un solo desarrollador para cliente, código base; No quiero facilitar que alguien simplemente copie algo que construí desde cero. Incluso iré tan lejos como para ofuscar (sp) el código para hacerlo aún más difícil. Quiero intentar hacerlo para que alguien tenga que preguntarme la fuente. Entonces puedo asegurar el soporte de actualizaciones o mejoras al código original. También me permite hacer un seguimiento de dónde vive el código. El único comentario que intento dejar en mi código es la primera línea “correo electrónico: [correo electrónico protegido] con preguntas, comentarios o fuente original.
2. En un mundo corporativo, se aplican las mismas reglas de psuedo. No hay una compañía que no esté tratando de mantener el código propietario en la empresa y que no se levante fácilmente. Aunque un buen desarrollador puede descifrar cualquier código, el código minimizado hace que sea más difícil de descifrar fácilmente si se extrae, descarga o descarta de un sitio web.

Sugiero mantener una biblioteca de desarrollo para que pueda comentar para un uso / comprensión más fácil más tarde, pero SIEMPRE, minimice todo en la salida. La omisión se puede perder varias veces, pero es más fácil agregar este paso adicional para minimizar con una ubicación completamente comentada que embellecer y comprender. El tiempo ganado con dos bibliotecas de activos separadas les ahorrará a todos tiempo suficiente para tratar de comprender lo que está sucediendo. Especialmente en casa en un entorno multi-dev.

Tal vez.

Es bastante simple en realidad, si el tiempo toma … “entender el código (X)”> “entender el comentario que explica el código (Y)”.

Después de leer tanto código hecho por otros que está en todas las variedades, desde el horror antiguo hasta el espagueti, para limpiar los copos de nieve. Con el tiempo, da la oportunidad de comprender cuánto valor hubiera tenido si el programador anterior hubiera “escrito esta simple oración aquí”. Lo que cultiva la mente para hacerlo al escribir el propio código.

Por lo tanto, hay cierto incentivo que se reintroduce una y otra vez para que la mente de un programador experimentado desarrolle este hábito, pero no garantiza que suceda.

Me encontré con ambos casos “X> Null” y “X

Quizás mis comentarios no sean mucho mejores. Pero la experiencia acumula la comprensión “¿Qué tipo de comentario aquí ayudaría a alguien más a entender este código?”, Como si estuviera viendo el código la primera vez y qué tipo de oración me daría una gran ventaja en la comprensión del código.

Es una capacidad similar a poder salir por la puerta de casa y ver todo con nuevos ojos como si me hubiera despertado en un hotel de un país extranjero donde llegué anoche en la oscuridad, y todo lo que veo es algo que nunca antes había visto. . Mire su propio código como si nunca lo hubiera visto antes, lea el código para comprenderlo y piense “¿Qué oración hubiera ayudado mucho?”

Muchas respuestas dan ejemplos prácticos como “No comentes X> Y por // Si X es mayor que Y” más o menos. Cuando practicas ver tu código por primera vez, tus ojos simplemente pasan esa simplicidad y pasas el tiempo luchando por separar la complejidad para la que sería el comentario. Si no hay complejidad, realmente no hay necesidad de comentarios.

¿Necesario? No.

Pero en la práctica, los comentarios, cuando se usan correctamente, hacen que el código sea más fácil de mantener. Tómese un momento y piense para quién son los comentarios. El compilador no se preocupa por ellos. La persona que escribe el código no los necesita ya que, supuestamente, ya saben lo que se supone que debe hacer el código que están escribiendo.

Hay comentarios para mantenimiento . Cuando usted u otro desarrollador abre un archivo seis semanas o seis años después de que se escribió por primera vez, no tendrá la misma comprensión del código que cuando lo escribió. Así es como funciona la mayoría de los cerebros.

Los comentarios le permiten orientarse rápidamente. Úsalos sabiamente, y en el futuro te agradecerá presentarte por agregarlos.

En mi opinión, debemos reescribir el código para que NO NECESITE comentar, y solo si no podemos hacerlo deberíamos dejar comentarios en el código.

Comente sobre el método pero intente hacer que el código sea legible en lugar de dejar comentarios. No deje comentarios para el código que es obvio porque debe mantenerse con el código: el código siempre es la fuente de la verdad, pero los comentarios pueden volverse inexactos, por lo que son un ‘riesgo’ para la deuda técnica a medida que el código cambia.

Descargo de responsabilidad: esta respuesta representa mis puntos de vista personales, y podría no ser aplicable a los programadores estrella.

Creo que los programadores experimentados tienden a comentar mejor los códigos. Hay dos extremos de mal estilo de comentario:

i) Falta de comentarios: aquellos principiantes que creen que comentar es estúpido y solo es útil si alguien va a leer su código (la liga a la que pertenezco) comprenderá la importancia de comentarios breves bien escritos con el tiempo. Ese momento en el que pasas mucho tiempo extra en algo que ya pasaste un día o dos, es realmente como una revelación 🙂

ii) Comentario excesivo: muchos principiantes tienden a comentar demasiado sus códigos. Esto sucede principalmente cuando están haciendo un intento consciente de escribir comentarios. Los comentarios excesivos pueden ser buenos para un principiante, pero realmente molestan a un programador experimentado porque ahora tiene forma de filtrar lo que debe leerse.

Finalmente, cuando comienzas a ser parte de proyectos más grandes, especialmente proyectos de código abierto, aprendes muchas cosas buenas sobre escribir comentarios (y también código).

Me parece que el mejor código tiene muy pocos “comentarios”.

En cambio, tiene un buen diseño, una interfaz fácil de entender, documentación clara y completa (sobre cada función / método, clase y constante), y cumple con los estándares específicos del idioma.

Los comentarios solo deben usarse cuando el código no está haciendo algo obvio. Mejor código es más obvio y tiene menos comentarios.

Un programador experimentado genera más líneas de comentarios, pero no comenta más líneas de código. Escribimos comentarios en bloque al comienzo del módulo, para cada función / método externo o interno, y luego, cuando estamos a punto de hacer algo que el programador casual e inexperto no entenderá dentro de tres años cuando decida agregar un pequeño cambio al código, lo hace mal y explota todo. Si estoy haciendo otra cosa, especialmente en vacaciones, no quiero una llamada telefónica pidiendo ayuda porque alguien arruinó uno de mis viejos programas.

Si ha pasado algún tiempo pensando y se da cuenta de que su idea original no iba a funcionar, por lo que lo hace de otra manera para evitar un punto muerto o una condición de persecución, entonces definitivamente comente eso o el próximo programador “simplificará” su código. En general, los programadores experimentados pasan mucho tiempo comentando sobre lo que no hicieron y por qué no lo hicieron de esa manera, porque el código que escribió con frecuencia explica por sí mismo lo que hizo.

La diferencia entre un programador experimentado e inexperto es que si ha estado en este negocio el tiempo suficiente, ha estado recibiendo la llamada telefónica desesperada y está dispuesto a hacer un esfuerzo adicional para evitarlo en el futuro. Con el tiempo, también se familiarizará con las muchas formas en que otros programadores pueden arruinar un programa en el que alguna vez trabajó.

Una marca de código ‘junior’, que encuentro constantemente como programador de mantenimiento, es ‘sin comentarios’. Y es lo mismo en mi propia progresión; Durante los primeros 5 años más o menos como programador, no escribí muchos comentarios porque nunca se me ocurrió, es posible que no entienda mi código más tarde. Por supuesto, este es un gran error. Aprendí a escribir comentarios con el tiempo.

La dolorosa ironía es lo difícil que es mantener el código no comentado, indocumentado, no probado y básicamente terrible que a menudo tengo que mantener.

Los programadores experimentados que conozco escriben un número muy limitado de comentarios. ¿Por qué?
Porque pueden orientarse rápidamente en código largo (incluso espagueti, creado por otra persona).

¿Por qué leer pocas líneas de comentarios, cuando pueden rastrear algunas pantallas de código línea por línea y entender lo que sucede? La compensación es obvia:

15 minutos leyendo el código = 5 minutos leyendo el comentario

Un consultor incluso eliminó los comentarios del código. Menos líneas para leer, más rápido para desplazarse … ¡Sí!
Más tarde fue recontratado porque nadie quería meterse con su lógica de código retorcido … pero alguien tenía que apoyarlo.

Si tiene curiosidad sobre cuál es el% de comentarios escritos por los mejores programadores a su alrededor, use el analizador de código. Me gusta CLOC:
AlDanial / cloc

A juzgar por la tendencia en mi empresa: en el contexto correcto, sí.

En las otras respuestas, estoy notando un patrón: a todos les preocupa comentar los engranajes internos y el funcionamiento del software y cómo esto rara vez es necesario. No estoy de acuerdo en dos partes aquí, las cuales requieren comentarios porque la complejidad no puede ser tratada de otra manera: algoritmos complejos e involucrados e interfaz con bibliotecas y software externos.

Por un lado, tenemos ciertos componentes en nuestra pila de alto rendimiento que son absurdamente difíciles. Cachés basados ​​en GC sin bloqueo, por ejemplo. No es posible entender a estas bestias en un plazo razonable sin los comentarios que nuestro superior hizo sobre estas bestias. Claro, el 95% de nuestro software no necesita un nivel de comentarios cerca de esto, pero en este caso, nos salvó muchos nervios al comentar las cosas correctas. Muchos otros desarrolladores que conozco no habrían comentado estas bestias magníficas y estaríamos en muchos problemas.

Segundo, bibliotecas externas y software. Por ejemplo, estamos interactuando con munin en ciertas partes y este software requiere ciertas soluciones alternativas bastante ridículas para algunos problemas. Tuve que presionar a la gente para que comentara estas cosas extrañas que encontraron después de horas de depuración para que no sigamos adelante y eliminemos las soluciones porque nadie recuerda por qué las necesitamos.

Entonces, resumiendo, digo fácilmente: Sí. Con experiencia, un desarrollador debe desarrollar una opinión más sólida cuando comentar es innecesario y puede ser reemplazado por un mejor código, pero un desarrollador también debe desarrollar una intuición cuando la documentación bien ubicada es la única forma de darle sentido al código en cuestión, porque existe Hay factores fuera de su control para emplear la primera solución.