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

string aComment = "This is a kludge.";

No creo que sea tan simple:

Incluso en un código bien autodocumentado y bien escrito, existen situaciones legítimas en las que deberías escribir comentarios.

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

Hay muchos efectos no obvios que pueden ocurrir en el código cuando estás interactuando con cosas que no escribiste. Por ejemplo, puede haber fallas de diseño en la biblioteca de otra persona o (si eres 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 entender el código y asegurarse de que no se elimine el kludge (romper cosas).

Es difícil para mí envolver mi mente en torno a la idea de que eliminar opciones de un idioma de alguna manera haría que los programas escritos en dicho idioma sean mejores. Los comentarios no son obligatorios, y la escritura del código de auto-documentación tampoco lo es.

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

En teoría, COBOL se diseñó originalmente de tal manera que estaba destinado a ser auto-documentado lo suficiente como para que incluso los desarrolladores (es decir, los supervisores) podían revisar el código escrito y determinar qué estaba pasando. 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.

Aunque la eliminación de comentarios podría obligar a algunos desarrolladores a escribir código que sea mejor en la auto documentación, todavía hay desarrolladores que escriben código mal documentado (es decir, nombres de variables de a , b , c , etc.) y son esos hábitos que las personas necesitan para ser entrenados. En esos casos, la eliminación de 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 escrito 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 la asignación es para permitir cambios incrementales. Cuando se produce un cambio en los requisitos, es necesario realizar los cambios correspondientes en el código, si el código debe seguir siendo una solución a los requisitos. Los comentarios sirven como una hoja de ruta para los cambios.

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

Dado que los idiomas en los que trabajamos no son tales DSL, y seguirán siéndolo durante algún tiempo, todavía 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.

Vea también ...

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

Evito comentar código, y funciona.

Evito todos los comentarios en el código (en línea o en línea) a favor de docblock + varables significativos + < a href="http://www.codinghorror.com/blog/2008/07/spartan-programming.html"> 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 son intrusivos y están "estandarizados" ... todo lo que un comentario común no es.

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

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

Estoy seguro de que la mayoría de nosotros hemos hecho algo así 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 viene ese error?

Independientemente de los comentarios sobre cómo funciona el código, las cosas simples y prácticas como eso o la colocación de una nota conveniente de TODO son cosas que facilitan la solución de problemas menores y recuerdan lo que estábamos haciendo cuando comenzamos a escribir el código. p>     

Los comentarios son como un resumen de un libro. Claro, puedes entenderlo todo leyendo el código, pero ¿por qué demonios quieres leer una página completa cuando podría resumirse en una línea comentada?

Aunque estoy de acuerdo con las otras respuestas de que incluso el código de auto-documentación 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 de un nivel bastante alto Con mucha abstracción. Cada declaración y función se vería obligada a ser legible a través de la sintaxis del idioma.

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

Intrigando a Python, que solo tiene privado por convención (_-prefix), no hace ningún esfuerzo para vigilar esto, y todavía se está escribiendo mucho código fino.

Rant: A veces pienso que los lenguajes más permisivos obligarían a más a las personas a aprender a codificar correctamente, en lugar de a la inversa (es decir, Java es una única opción y maldito seas si quieres pensar en las funciones como objetos de primera clase).

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

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

Si, por ejemplo, se necesita una sección de código para cumplir con una regulación específica, ¿cómo explica eso sin un comentario? Si el algoritmo utilizado por una determinada pieza de código se describe en un documento escrito en 1998 por M. Matsumoto y T. Nishimura, ¿cómo explica eso 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 modifica otro código, ¿cómo explica eso sin un comentario?

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

Siempre he pensado que sería bueno tener un comentario de una sola palabra, de modo que si prefijabas una palabra con un símbolo (digamos dos puntos), esa palabra se ignoraría. De esa manera, podría haber dicho que solo permitía comentarios de una palabra dentro de una s-expresión. Por ejemplo, podrías convertir esto:

(if (= x y)
    x
    y)

... en esto:

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

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

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

Por supuesto, esto es un dolor para escribir. De hecho, ese es el punto. Le anima a utilizar los comentarios en línea con moderación y mantenerlos cortos y al punto. Pero tengo la sensación de que me costaría mucho convencer a cualquiera de que use el idioma.

Esto es doble o nada. Algunos programadores no hacen nada para hacer que el código sea legible. No permitir comentarios reforzará esto. Algunos programadores escriben buenos comentarios, incluso si serían aún mejores si fueran refactorización de código en lugar de comentarios: la eliminación de comentarios puede obligarlos a hacer la refactorización mejor.

Razones por las que esta es una buena idea:  - Ninguno

Razones por las que esta es una mala idea:  - Hay muchos más programadores atroces que programadores buenos pero no excelentes.  - Casi siempre debería haber algunos comentarios para errores extraños, resúmenes, etc.  - Incluso si evita los comentarios, es probable que use los 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 inmediatamente porque todavía estás aprendiendo.  - Animará a la gente a trabajar alrededor de él.  - ¿Quién lo usaría? Las personas que escriben código ilegible y quieren una excusa (mala) y las personas que ya están enamoradas de la idea (que pueden simplemente "no escribir comentarios" para comenzar). Si esto es lo que quieres, solo escribe un estándar de codificación que muestre cómo quieres que la gente lo haga.

Razones por las que esto puede ser relevante  - Donde podría ser útil es como parte de un sistema para mejorar "no comentar", por ejemplo. un idioma o IDE que tiene un buen soporte para algo mejor que los 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.