El estilo de programación , también conocido como estilo de codificación , se refiere a las convenciones y patrones utilizados en la escritura del código fuente , lo que da como resultado una base de código coherente y legible . Estas convenciones a menudo abarcan aspectos como la sangría , las convenciones de nomenclatura , el uso de mayúsculas y los comentarios . El estilo de programación coherente generalmente se considera beneficioso para la legibilidad y el mantenimiento del código , en particular en entornos colaborativos.
Mantener un estilo coherente en toda la base de código puede mejorar la legibilidad y la facilidad de mantenimiento del software. Permite a los desarrolladores comprender rápidamente el código escrito por otros y reduce la probabilidad de errores durante las modificaciones. Adherirse a pautas de codificación estandarizadas garantiza que los equipos sigan un enfoque uniforme, lo que hace que la base de código sea más fácil de administrar y escalar. Muchas organizaciones y proyectos de código abierto adoptan estándares de codificación específicos para facilitar la colaboración y reducir la carga cognitiva.
Las pautas de estilo se pueden formalizar en documentos conocidos como convenciones de codificación , que dictan reglas específicas de formato y nomenclatura. Estas convenciones pueden estar prescritas por estándares oficiales para un lenguaje de programación o pueden desarrollarse internamente dentro de un equipo o proyecto. Por ejemplo, PEP 8 de Python es una guía de estilo ampliamente reconocida que describe las mejores prácticas para escribir código Python. Por el contrario, lenguajes como C o Java pueden tener estándares de la industria que están documentados formalmente o se respetan por convención.
El cumplimiento del estilo de codificación se puede hacer cumplir mediante herramientas automatizadas que formatean el código según pautas predefinidas. Estas herramientas reducen el esfuerzo manual necesario para mantener la coherencia del estilo, lo que permite a los programadores centrarse en la lógica y la funcionalidad. Por ejemplo, herramientas como BlackPython y clang-formatC++ reformatean automáticamente el código para cumplir con los estándares de codificación especificados.
Los elementos comunes del estilo de codificación incluyen:
El estilo de sangría puede ayudar al lector de diversas maneras, entre ellas: identificar el flujo de control y los bloques de código. En algunos lenguajes de programación, la sangría se utiliza para delimitar bloques de código y, por lo tanto, no es una cuestión de estilo. En lenguajes que ignoran los espacios en blanco, la sangría puede afectar la legibilidad.
Por ejemplo, formateado en un estilo comúnmente utilizado:
si ( horas < 24 && minutos < 60 && segundos < 60 ) { devuelve verdadero ; } de lo contrario { devuelve falso ; } Podría decirse que está mal formateado:
si ( horas < 24 && minutos < 60 && segundos < 60 ) { devuelve verdadero ;} de lo contrario { devuelve falso ;} El estilo de sangría cero de ModuLiq agrupa por línea vacía en lugar de sangría.
Ejemplo:
si ( horas < 24 && minutos < 60 && segundos < 60 ) devuelve verdadero ; de lo contrario devuelve falso ; Lua no utiliza las tradicionales llaves o paréntesis ; en su lugar, la expresión en una declaración condicional debe ir seguida de then, y el bloque debe cerrarse con end.
Si las horas < 24 y los minutos < 60 y los segundos < 60 entonces devuelve verdadero; de lo contrario, devuelve falso. Fin.La sangría es opcional en Lua. and, or, y notfuncionan como operadores lógicos.
Python se basa en la regla off-side , que utiliza sangrías para indicar e implementar la estructura de control, eliminando así la necesidad de corchetes (es decir, {y }). Sin embargo, copiar y pegar código sangrado puede causar problemas, porque el nivel de sangría del código pegado puede no ser el mismo que el nivel de sangría de la línea de destino. Este tipo de reformateo manual es tedioso y propenso a errores, pero algunos editores de texto y entornos de desarrollo integrados (IDE) tienen funciones para hacerlo automáticamente. También hay problemas cuando el código sangrado se vuelve inutilizable cuando se publica en un foro o página web que elimina los espacios en blanco, aunque este problema se puede evitar donde es posible encerrar el código en etiquetas que preservan los espacios en blanco como "<pre> ... </pre>" (para HTML ), "[code]" ... "[/code]" (para bbcode ), etc.
si horas < 24 y minutos < 60 y segundos < 60 : devuelve Verdadero de lo contrario : devuelve FalsoPython comienza un bloque con dos puntos ( :).
Los programadores de Python tienden a seguir una guía de estilo comúnmente acordada conocida como PEP8. [1] Existen herramientas diseñadas para automatizar el cumplimiento de PEP8.
Haskell , al igual que Python, tiene la regla del lado opuesto . Tiene una sintaxis bidimensional en la que la sangría tiene sentido para definir bloques (aunque una sintaxis alternativa utiliza llaves y punto y coma).
Haskell es un lenguaje declarativo, hay declaraciones, pero declaraciones dentro de un script Haskell.
Ejemplo:
sea c_1 = 1 c_2 = 2 en f x y = c_1 * x + c_2 * y Puede escribirse en una línea como:
sea { c_1 = 1 ; c_2 = 2 } en f x y = c_1 * x + c_2 * y Haskell fomenta el uso de programación literaria , donde el texto extendido explica la génesis del código. En los scripts literarios de Haskell (nombrados con la lhsextensión), todo es un comentario excepto los bloques marcados como código. El programa puede estar escrito en LaTeX , en cuyo caso el codeentorno marca lo que es código. Además, cada párrafo de código activo puede marcarse precediéndolo y finalizándolo con una línea vacía, y comenzando cada línea de código con un signo mayor que y un espacio. Aquí hay un ejemplo usando marcado LaTeX:
La función \ verb + isValidDate + prueba si la fecha es válida \ begin { código } isValidDate :: Date -> Bool isValidDate fecha = hh >= 0 && mm >= 0 && ss >= 0 && hh < 24 && mm < 60 && ss < 60 donde ( hh , mm , ss ) = fromDate fecha \ end { código } observe que en este caso la función sobrecargada es \ verb + fromDate :: Date -> ( Int , Int , Int ) +. Y un ejemplo usando texto simple:
La función isValidDate prueba si la fecha es válida > isValidDate :: Fecha -> Bool > isValidDate fecha = hh >= 0 && mm >= 0 && ss >= 0 > && hh < 24 && mm < 60 && ss < 60 > donde ( hh , mm , ss ) = fromDate fecha observe que en este caso la función sobrecargada es fromDate :: Date -> ( Int , Int , Int ) . Algunos programadores consideran que es valioso alinear elementos similares verticalmente (como en una tabla, en columnas), argumentando que puede hacer que los errores tipográficos sean más obvios.
Por ejemplo, sin alinear:
$búsqueda = matriz ( 'a' , 'b' , 'c' , 'd' , 'e' ); $reemplazo = matriz ( 'foo' , 'bar' , 'baz' , 'quux' );$valor = 0 ; $otrovalor = 1 ; $todavíaotrovalor = 2 ;alineado:
$búsqueda = matriz ( 'a' , 'b' , 'c' , 'd' , 'e' ); $reemplazo = matriz ( 'foo' , 'bar' , 'baz' , 'quux' );$valor = 0 ; $otrovalor = 1 ; $todavíaotrovalor = 2 ;A diferencia del código no alineado, el código alineado implica que los valores de búsqueda y reemplazo están relacionados, ya que tienen elementos correspondientes. Como hay un valor más para la búsqueda que para el reemplazo, si se trata de un error, es más probable que se detecte mediante una inspección visual.
Las desventajas citadas de la alineación vertical incluyen:
El mantenimiento de la alineación se puede aliviar con una herramienta que proporcione soporte (por ejemplo, topes de pestaña elásticos ), aunque eso crea una dependencia de dichas herramientas.
A modo de ejemplo, las operaciones de refactorización simples para cambiar el nombre de "$replacement" a "$r" y "$anothervalue" a "$a" dan como resultado:
$búsqueda = matriz ( 'a' , 'b' , 'c' , 'd' , 'e' ); $r = matriz ( 'foo' , 'bar' , 'baz' , 'quux' );$valor = 0 ; $a = 1 ; $todavíaotrovalor = 2 ;Con un formato no alineado, estos cambios no tienen un efecto tan dramático, inconsistente o indeseable:
$búsqueda = matriz ( 'a' , 'b' , 'c' , 'd' , 'e' ); $r = matriz ( 'foo' , 'bar' , 'baz' , 'quux' );$valor = 0 ; $a = 1 ; $todavíaotrovalor = 2 ;Un lenguaje de formato libre ignora los caracteres en blanco : espacios, tabulaciones y nuevas líneas, por lo que el programador tiene la libertad de aplicar estilos al código de distintas maneras sin afectar el significado del mismo. Generalmente, el programador utiliza estilos que se consideran que mejoran la legibilidad .
Los dos fragmentos de código a continuación son lógicamente iguales, pero difieren en los espacios en blanco.
int i ; para ( i = 0 ; i < 10 ; ++ i ){ printf ( "%d" , i * i + i ); } versus
int i ; para ( i = 0 ; i < 10 ; ++ i ) { printf ( "%d" , i * i + i ); } El uso de tabulaciones para los espacios en blanco es discutible. Los problemas de alineación surgen debido a las diferentes posiciones de tabulación en diferentes entornos y al uso combinado de tabulaciones y espacios.
A modo de ejemplo, un programador prefiere tabulaciones de cuatro y tiene su conjunto de herramientas configurado de esta manera, y las utiliza para formatear su código.
int ix ; // Índice para escanear la matriz long sum ; // Acumulador para la suma Otro programador prefiere tabulaciones de ocho, y su conjunto de herramientas está configurado de esta manera. Cuando otra persona examine el código de la persona original, es posible que le resulte difícil de leer.
int ix ; // Índice para escanear la matriz long sum ; // Acumulador para la suma Una solución muy utilizada para este problema puede consistir en prohibir el uso de tabulaciones para la alineación o establecer reglas sobre cómo deben configurarse las tabulaciones. Tenga en cuenta que las tabulaciones funcionan bien siempre que se utilicen de forma coherente, se limiten a la sangría lógica y no se utilicen para la alineación:
clase MyClass { int foobar ( int qux , // primer parámetro int quux ); // segundo parámetro int foobar2 ( int qux , // primer parámetro int quux , // segundo parámetro int quuux ); // tercer parámetro };