¿Puede un lenguaje de programación por diseño imponer "código limpio"? [cerrado]

Así que estoy codificando mis primeros proyectos en C ++ y parece que toma más esfuerzo hacer que el código sea "limpio", en lugar de simplemente funcionar. Es decir, parece que C ++ "permite" escribir código feo pero funcional.

Lo que me hizo pensar

¿Puede un lenguaje de programación imponer código limpio por diseño? ¿Ya hay tales idiomas?

Además, ¿cómo se incorpora esto como principios de diseño en el desarrollo / teoría del lenguaje de programación? ¿Qué tipo de medidas se utilizan?

El efecto principal que tiene el diseño del lenguaje en el "código limpio" está en el nivel sintáctico. Los idiomas con muchos shorthands y operadores oscuros (Perl / APL) se prestan a código "sucio", mientras que los idiomas con un conjunto más pequeño de elementos (por ejemplo, Python) se prestan a un código más limpio.

La semántica, sin embargo, es un animal muy diferente. No hay forma de exigir que la semántica de un idioma se use de manera limpia, particularmente porque no puede, como compilador, saber qué está tratando de lograr el usuario del idioma. Una herramienta poderosa es simplemente eso: una herramienta poderosa, para bien o para mal.

Al final del día, la semántica es más importante que la sintaxis. También es la parte que es más difícil de entender como desarrollador de mantenimiento (por ejemplo, "¿qué significa realmente este código? Veo lo que hace ...").

En consecuencia, diría que no existe un diseño para imponer un código limpio, pero puede escribir una sintaxis simple con una semántica limpia que lo haga más fácil. Para bien o para mal, el código limpio es principalmente una cuestión de conocimiento del desarrollador, motivación, disciplina y habilidad.

Los lenguajes pueden forzar o alentar a los programadores a abordar ciertas clases de errores, lo cual es parte de la definición de código limpio. Por ejemplo, varios idiomas hacen un trabajo relativamente decente al abordar:

• Excepciones de puntero nulo.
• Errores de estado compartidos.
• Problemas de concurrencia.
• Excepciones no verificadas.

Sin embargo, eso solo lo lleva a una parte del camino, porque el código limpio se trata principalmente de la comunicación de persona a persona. Los lenguajes de programación realmente solo tienen una palanca para ayudar en esto, y ese es su poder expresivo . Es un término realmente difícil de definir, pero básicamente es más fácil para los buenos programadores escribir código más limpio en lenguajes más expresivos. Tienen más herramientas disponibles para expresar fácilmente un algoritmo en términos que se comuniquen bien con otros humanos. No me malinterpretes, puedes escribir código limpio en ( casi ) cualquier lenguaje de programación. Solo algunos idiomas lo hacen más fácil y tienen un mejor resultado relativo.

Sin embargo, no puede simplemente marcar la expresividad y mágicamente las personas comenzarán a escribir un mejor código. Con la mayoría de los programadores, les das más botones para activar su idioma, y ​​no sabrán cómo usarlos correctamente, por lo que su código termina peor. Se necesita disciplina y buena orientación para mejorar la calidad de su código. No hay balas de plata.

Hasta cierto punto. Muchos idiomas están diseñados deliberadamente para fomentar algunas formas de código limpio de acuerdo con los ideales de los diseñadores de idiomas. Ciertamente es posible escribir código feo e incomprensible en cualquier idioma, pero algunos idiomas hacen un mayor esfuerzo para desalentarlo.

Como ejemplo, Python te obliga a sangrar bloques de acuerdo con la estructura semántica del lenguaje, mientras que muchos otros lenguajes te permiten sangrar totalmente al azar o nada en absoluto. Este es un ejemplo de un lenguaje que fomenta activamente un cierto ideal de limpieza.

Si puede cuantificarlo, puede crear un lenguaje que pueda optimizarlo.

Si bien no conozco ningún lenguaje en particular que realmente aplique una política de "código limpio", los policías de estilo que se ejecutan en la compilación son bastante comunes.

La razón principal por la que este es un paso separado de ser incorporado al lenguaje es en gran medida una función de las prioridades. Está en el mejor interés de un lenguaje de programación para permitir la mayor flexibilidad a los programadores para obtener el nivel más amplio de adopción. Hay tantos lenguajes de programación y DSL diferentes que restringir artificialmente la base de usuarios al ser exigente y obstinado acerca de qué entrada está permitida podría obstaculizar una adopción más amplia.

Por ejemplo, no está en el mejor interés de C # forzar a las personas a escribir

if (condition)
{

en lugar de

if (condition) {

Pero los correctores de estilo pueden ser muy exigentes porque para eso están diseñados.

Entonces, para responder la pregunta

¿Puede un lenguaje de programación imponer código limpio por diseño?

_{énfasis mío}

Absolutamente, siempre que proporcione una definición sólida de lo que significa "código limpio".

Por ejemplo, podría definir "código limpio" para significar:

• longitud de línea no mayor de 80 caracteres
• funciones compuestas de no más de 100 líneas
• sangría debe ser dos espacios
• las llaves abiertas deben seguir al final de la línea precedidas por exactamente un espacio
• no más de dos operadores por línea

y es posible que no esté de acuerdo con algunas o todas estas convenciones, pero al final del día son cuantificables y pueden aplicarse mediante programación.

No, no en el sentido que usted describe. ¡La detección de "fealdad" no se puede hacer automáticamente!

Sin embargo, los diseñadores de idiomas pueden hacer cosas para fomentar un buen código (no quiero decir "limpio" porque a veces el código bueno y seguro también es largo y "feo"). Por ejemplo, los diseñadores del lenguaje Rust observaron las cosas que los programadores disciplinados de C ++ tienden a hacer (como dar a los valores asignados en un montón un solo "propietario"), y facilitaron hacer algunas de esas cosas. Esto incluye proporcionar un comprobador de tipos que puede usar para verificar que no cometió ciertos errores comunes.

Yo diría que un buen diseño de lenguaje a menudo es reactivo: los diseñadores observan lo que hacen los buenos programadores y tratan de hacerlo más fácil y "más bonito".