Solo por curiosidad, comencé a preguntarme si un lenguaje que no permite comentarios generaría un código más legible, ya que se habría visto obligado a escribir un código de auto comentario.

Por otra parte, podría escribir un código tan malo como antes porque simplemente no le importa. ¿Pero cuál es tu opinión?

Creo que los programadores encontrarían otra forma de agregar comentarios ...

string aComment = "This is a kludge.";

No creo que sea tan simple:

Incluso en un código bien documentado y autodocumentado, hay situaciones legítimas en las que debe escribir comentarios.

Supongamos que eres un programador perfecto (que no lo eres, pero supongamos) ...

Hay muchos efectos no obvios que pueden ocurrir en el código cuando interactúas con cosas que no escribiste. Por ejemplo, puede haber fallas de diseño en la biblioteca de otra persona o (si es un desarrollador de kernel) en el hardware de otra persona. Tener comentarios para explicar por qué usó kludge en particular en un lugar en particular puede ser esencial para comprender el código y asegurarse de que no se elimine (romper cosas).

Me resulta difícil comprender la idea de que eliminar opciones de un idioma mejoraría de alguna manera los programas escritos en dicho idioma. Los comentarios no son obligatorios, y escribir código autodocumentado tampoco lo es.

No hay sustituto para las buenas prácticas de desarrollo.

En teoría, COBOL se diseñó originalmente de tal manera que debía documentarse lo suficiente como para que incluso los no desarrolladores (es decir, los supervisores) pudieran revisar el código escrito y determinar lo que estaba sucediendo. Sin embargo, en la práctica, a medida que un programa se vuelve más complejo, es difícil entender todo lo que sucede únicamente a través del código.

Mientras que la eliminación de los comentarios podría obligar a algunos desarrolladores a escribir código que es mejor en la documentación del mismo, todavía hay desarrolladores que hay que escribir código pobremente documentada (es decir, los nombres de variables de a, b, c, etc.) y son esos hábitos que las personas necesitan ser entrenados a cabo de de. En esos casos, eliminar comentarios no afectaría a esos desarrolladores y podría obstaculizar los esfuerzos de otros desarrolladores para explicar piezas complejas de código.

Cada programa se escribe para implementar requisitos funcionales que están fuera del programa, ya sea escritos o simplemente en la cabeza de alguien.

Creo que la función más esencial de los comentarios es establecer un mapeo entre los requisitos y el código. La razón por la que se necesita el mapeo es para permitir cambios incrementales. Cuando se produce un cambio en los requisitos, es necesario realizar los cambios correspondientes en el código, para que el código siga siendo una solución a los requisitos. Los comentarios sirven como una hoja de ruta para los cambios.

Si el lenguaje es un lenguaje específico de dominio (DSL) ideal perfectamente adaptado al problema que se está resolviendo, entonces el mapeo debería ser un simple isomorfismo y no serían necesarios comentarios. El código fuente simplemente indicaría el problema, y ​​no sería necesario decir nada más. La solución del problema estaría enterrada en la implementación del lenguaje.

Dado que los idiomas en los que trabajamos no son DSL, y lo seguirán siendo durante algún tiempo, aún necesitamos comentarios . Es una cuestión de grado. A veces, el problema es una buena coincidencia con el idioma en cuestión, pero generalmente no.

Ver también...

Trabajo en un lugar que no permite comentarios en línea (es decir, solo puede tener comentarios en la parte superior de las funciones). No, no hace que el código sea más fácil de leer. Lo hace peor en órdenes de magnitud.

Evito comentar código, y funciona.

Evito todos los comentarios en código (en línea o en secuencia) a favor de docblock + valores significativos + programación espartana , y funciona.

Y sí, sé que los docblocks son técnicamente comentarios, aún así, en realidad son complementarios al código, no intrusivos y "estandarizados" ... todo lo que un comentario común no es.

Lo que creo que podría funcionar como un sustituto de los comentarios: un lenguaje / sintaxis / modismo estandarizado de docblock, algo así como anotaciones en java.

No solo no afectaría la calidad, como otros han observado, en realidad sería realmente molesto.

Estoy seguro de que la mayoría de nosotros hemos hecho algo como esto de vez en cuando:

foreach ( myObject obj in SomeList )
 {
    Debug.Writeline( obj.Name );
//  for some reason this isn't working
//  obj.SetArielPotency( setting );
//  obj.DoSomeProcess();       
 }

¿Qué tan irritante sería si no pudieras comentar algunas líneas de código para averiguar de dónde proviene ese error?

Independientemente de los comentarios sobre cómo funciona el código, cosas prácticas simples como eso o dejar una TODOnota conveniente son cosas que hacen que sea más fácil solucionar problemas menores y recordar lo que estábamos haciendo cuando comenzamos a escribir el código.

Los comentarios son como un resumen del libro. Claro, puedes entender todo leyendo el código, pero ¿por qué quieres leer una página completa cuando se puede resumir en una línea comentada?

Si bien estoy de acuerdo con las otras respuestas de que incluso el código autodocumentado necesita comentarios, eso solo es relevante para los idiomas actuales .

Creo que la verdadera pregunta es: "¿Es posible diseñar un nuevo lenguaje de programación que no necesite comentarios?" Tendría que ser bastante alto nivel con una gran cantidad de abstracción. Cada declaración y función se vería obligada a ser legible a través de la sintaxis del lenguaje.

Los programadores indisciplinados escribirán código incorrecto, sin importar el idioma.

La intriga de ese pitón, que solo tiene un aspecto privado por convención (prefijo _), no hace ningún esfuerzo por controlar esto, y todavía se está escribiendo mucho código fino.

Rant: A veces creo que los lenguajes más permisivos obligarían a más personas a aprender a codificar correctamente, en lugar de lo contrario (es decir, el unidireccional y condenado de Java si quieres pensar en las funciones como objetos de primera clase).

Adivinaré: probablemente no. ¿Por qué? Porque tendrías que codificar "por qué" como formalismo en el lenguaje y porque "por qué", ya sea codificado en lenguaje o comentario en lenguaje, los programadores subutilizan de todos modos.

Ciertamente, el código puede hacerse comentarios al explicar lo que está haciendo, pero no siempre es posible que el código explique por qué lo está haciendo. Ahí es donde más se necesitan comentarios.

Si, por ejemplo, se necesita una sección de código para cumplir con una regulación específica, ¿cómo se explica eso sin un comentario? Si el algoritmo utilizado por un código en particular se describe en un artículo escrito en 1998 por M. Matsumoto y T. Nishimura, ¿cómo lo explica sin un comentario? Si un algoritmo no proporciona exactamente la funcionalidad óptima pero hace un compromiso justificado muy específico que puede causar problemas futuros si se cambia otro código, ¿cómo explica eso sin un comentario?

¿Qué sucede si una sección del código fue auditada por un auditor independiente, por lo que no puede modificarse sin invalidar esa auditoría y el código se utiliza para construir un producto cuyo cumplimiento con esa auditoría es requerido por sus clientes? ¿Cómo indicas eso sin un comentario?

Siempre he pensado que sería bueno tener un comentario de una palabra para que si prefijas una palabra con un símbolo (digamos dos puntos), esa palabra sea ignorada. De esa forma, podría haber dicho un ceceo que solo permitía comentarios de una palabra dentro de una expresión-s. Por ejemplo, podrías convertir esto:

(if (= x y)
    x
    y)

...dentro de esto:

(if (= x y)
    :then x
    :else y)

Si es absolutamente necesario, puede encadenar múltiples comentarios de una palabra para formar un comentario en línea:

(if x :Remember, :x :could :be :nil!
    ...)

Por supuesto, esto es un dolor de escribir. De hecho, ese es el punto. Lo alienta a usar los comentarios en línea con moderación y mantenerlos cortos y al grano. Pero tengo la sensación de que me resultaría difícil convencer a alguien de que use el lenguaje.

Esto es doble o nada. Algunos programadores no hacen nada para que el código sea legible. No permitir comentarios reforzará esto. Algunos programadores escriben buenos comentarios, incluso si serían aún mejores si estuvieran refactorizando el código en lugar de los comentarios; eliminar los comentarios puede obligarlos a mejorar la refactorización.

Razones por las cuales esta es una buena idea: - Ninguna

Razones por las cuales esta es una mala idea: - Hay muchos más programadores atroces que programadores buenos pero no buenos - Casi siempre debería haber algunos comentarios para extraños trucos, resúmenes, etc. - Incluso si evita los comentarios, probablemente usará comentarios como una etapa en el camino: agregue un comentario cuando esté escribiendo algo, y luego regrese y refactorícelo. Pero no siempre puedes hacerlo bien de inmediato porque todavía estás aprendiendo. - Alentará a las personas a trabajar en torno a él - ¿Quién lo usaría? Las personas que escriben códigos ilegibles y quieren una excusa (mala) y las personas que ya están enamoradas de la idea (que simplemente pueden "no escribir comentarios" para empezar). Si esto es lo que desea, simplemente escriba un estándar de codificación que muestre cómo desea que lo hagan las personas.

Razones en las que esto puede ser relevante: donde podría ser útil es como parte de un sistema para mejorar "no hacer comentarios", por ejemplo. un idioma o IDE que tiene un buen soporte para algo mejor que comentarios y como parte de su discurso, evita los comentarios. No sé cómo funcionaría, pero es un buen punto en el que vale la pena pensar al menos.