El estilo de programación , también conocido como estilo de codificación , se refiere a las convenciones y patrones utilizados al escribir código fuente , lo que da como resultado un código base coherente y legible . Estas convenciones suelen abarcar aspectos como la indentación , las convenciones de nomenclatura , el uso de mayúsculas y los comentarios . Un estilo de programación coherente se considera generalmente beneficioso para la legibilidad y el mantenimiento del código , especialmente en entornos colaborativos.
Mantener un estilo coherente en todo el código fuente mejora la legibilidad y facilita el 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. Seguir las directrices de codificación estandarizadas garantiza que los equipos adopten un enfoque uniforme, lo que facilita la gestión y la escalabilidad del código fuente. 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 directrices 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 desarrollarse internamente dentro de un equipo o proyecto. Por ejemplo, la PEP 8 de Python es una guía de estilo ampliamente reconocida que describe las mejores prácticas para escribir código Python. En cambio, lenguajes como C o Java pueden tener estándares de la industria que están documentados formalmente o que se siguen por convención.
Automatización
El cumplimiento de los estilos de codificación se puede garantizar mediante herramientas automatizadas, conocidas como linters , que formatean el código según directrices 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 CSSLint para CSS, Black para Python, clang-format para C++, PHP-CS-Fixer para PHP y ESLint para JavaScript reformatean automáticamente el código para que cumpla con los estándares de estilo de codificación especificados.
Guía de estilo
Los elementos comunes del estilo de codificación incluyen:
- El uso de sangría y espacios en blanco garantiza estructuras de bloques consistentes y mejora la legibilidad.
- Convenciones de nomenclatura : estandarizan la forma en que se nombran las variables , las funciones y las clases , siguiendo normalmente los formatos camelCase , snake case o Pascal Case, según el lenguaje de programación.
- Uso de mayúsculas : determina si las palabras clave y los identificadores se escriben con mayúscula o minúscula, de acuerdo con la sintaxis del idioma.
- Uso de comentarios : Proporcionan contexto y explicaciones dentro del código sin afectar su ejecución.
Sangría
El estilo de sangría puede ayudar al lector de diversas maneras, como por ejemplo, a 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 con un estilo de uso común:
Si ( horas < 24 && minutos < 60 && segundos < 60 ) { return true ; } else { return false ; }Podría decirse que tiene un formato deficiente:
Si ( horas < 24 && minutos < 60 && segundos < 60 ) { devolver verdadero ; } de lo contrario { devolver falso ; }Estilos de sangría notables
ModuLiq
El estilo de sangría cero de ModuLiq agrupa por línea vacía en lugar de sangrar.
Ejemplo:
Si ( horas < 24 && minutos < 60 && segundos < 60 ) devolver verdadero ;de lo contrario, devolver falso ;Lua
Lua no utiliza las llaves o paréntesis tradicionales ; en cambio, la expresión en una instrucción condicional debe ir seguida de then, y el bloque debe cerrarse con end.
Si horas < 24 y minutos < 60 y segundos < 60 entonces devolver verdadero, de lo contrario devolver falso .La indentación es opcional en Lua. and, or, y notfuncionan como operadores lógicos.
Pitón
Python se basa en la regla de sangría , utilizando la indentación para indicar e implementar la estructura de control, eliminando así la necesidad de corchetes (es decir, {y }). Sin embargo, copiar y pegar código indentado puede causar problemas, porque el nivel de indentación del código pegado puede no ser el mismo que el nivel de indentación de la línea de destino. Este 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 indentado se vuelve inutilizable al publicarse en un foro o página web que elimina los espacios en blanco, aunque este problema se puede evitar cuando es posible encerrar el código en etiquetas que conservan los espacios en blanco como " < pre > ... < /pre > " (para HTML ), "[code]" ... "[/code]" (para bbcode ), etc.
Si horas < 24 y minutos < 60 y segundos < 60 : devolver Verdadero; de lo contrario : devolver FalsoPython comienza un bloque con dos puntos ( :).
Los programadores de Python tienden a seguir una guía de estilo comúnmente aceptada conocida como PEP8. [ 1 ] Hay herramientas diseñadas para automatizar el cumplimiento de PEP8.
Haskell
Haskell, al igual que Python, tiene la regla del lado opuesto . Tiene una sintaxis bidimensional donde la indentación es significativa para definir bloques (aunque existe una sintaxis alternativa que utiliza llaves y punto y coma).
Haskell es un lenguaje declarativo; existen sentencias, pero dentro de un script de Haskell se utilizan declaraciones.
Ejemplo:
Sea c_1 = 1 y c_2 = 2 en f x y = c_1 * x + c_2 * ypuede escribirse en una sola línea como:
sea { c_1 = 1 ; c_2 = 2 } en f x y = c_1 * x + c_2 * yHaskell fomenta el uso de la programación literaria , donde un texto extenso explica el origen del código. En los scripts literarios de Haskell (con la lhsextensión .htm), todo es un comentario excepto los bloques marcados como código. El programa puede escribirse en LaTeX ; en ese caso, el codeentorno marca qué es código. Además, cada párrafo de código activo puede marcarse precediéndolo y terminándolo con una línea en blanco, y comenzando cada línea de código con un signo de mayor que y un espacio. Aquí un ejemplo usando el marcado de LaTeX:
La función \ verb + isValidDate + prueba si la fecha es válida \ begin { code } isValidDate :: Date -> Bool isValidDate date = hh >= 0 && mm >= 0 && ss >= 0 && hh < 24 && mm < 60 && ss < 60 donde ( hh , mm , ss ) = fromDate date \ end { code } observe que en este caso la función sobrecargada es \ verb + fromDate :: Date -> ( Int , Int , Int ) +.Y un ejemplo usando texto plano :
La función isValidDate comprueba si la fecha es válida.> isValidDate :: Date -> Bool > isValidDate fecha = hh >= 0 && mm >= 0 && ss >= 0 > && hh < 24 && mm < 60 && ss < 60 > donde ( hh , mm , ss ) = fromDate fechaobserve que en este caso la función sobrecargada es fromDate :: Date -> ( Int , Int , Int ) .Alineación vertical
Algunos programadores consideran valioso alinear verticalmente los elementos similares (como en una tabla, en columnas), argumentando que esto puede hacer más evidentes los errores tipográficos.
Por ejemplo, no alineado:
$search = array ( 'a' , 'b' , 'c' , 'd' , 'e' ); $replacement = array ( 'foo' , 'bar' , 'baz' , 'quux' );$valor = 0 ; $otrovalor = 1 ; $otrovalor adicional = 2 ;alineado:
$search = array ( 'a' , 'b' , 'c' , 'd' , 'e' ); $replacement = array ( 'foo' , 'bar' , 'baz' , 'quux' );$valor = 0 ; $otrovalor = 1 ; $otrovalor adicional = 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. Dado que 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.
Entre las desventajas citadas de la alineación vertical se incluyen:
- Dependencias entre líneas que generan carga de mantenimiento. Por ejemplo, si se agrega un valor de columna largo que requiere una columna más ancha, entonces todas las líneas de la tabla deben modificarse (para mantener el formato tabular), lo que es un cambio mayor que conlleva más esfuerzo para revisar y comprender el cambio posteriormente.
- Fragilidad: si un programador no formatea correctamente la tabla al realizar un cambio, el resultado es un código visualmente desordenado y más difícil de leer que un código sin alinear. Operaciones de refactorización sencillas, como cambiar el nombre de las variables, pueden dañar el formato.
- El mayor esfuerzo de mantenimiento puede desalentar a un programador a realizar un cambio beneficioso, como mejorar el nombre de un identificador, ya que hacerlo requeriría un esfuerzo de formato significativo.
- Requisito de utilizar fuentes de ancho fijo, no fuentes proporcionales.
Mantener la alineación puede facilitarse mediante una herramienta que proporcione soporte (por ejemplo, para tabulaciones elásticas ), aunque esto crea una dependencia de dichas herramientas.
Como ejemplo, operaciones de refactorización simples para cambiar el nombre de "$replacement" a "$r" y de "$anothervalue" a "$a" dan como resultado:
$search = array ( 'a' , 'b' , 'c' , 'd' , 'e' ); $r = array ( 'foo' , 'bar' , 'baz' , 'quux' );$valor = 0 ; $a = 1 ; $otrovalor = 2 ;Con un formato no alineado, estos cambios no tienen un efecto tan drástico, inconsistente o indeseable:
$search = array ( 'a' , 'b' , 'c' , 'd' , 'e' ); $r = array ( 'foo' , 'bar' , 'baz' , 'quux' );$valor = 0 ; $a = 1 ; $otrovalor = 2 ;Espacio en blanco
Un lenguaje de formato libre ignora los caracteres de espacio en blanco : espacios, tabulaciones y saltos de línea, por lo que el programador puede dar estilo al código de diferentes maneras sin afectar su significado. Generalmente, el programador utiliza un estilo que se considera que mejora la legibilidad .
Los dos fragmentos de código que aparecen a continuación son lógicamente iguales, pero difieren en los espacios en blanco.
int i ; for ( i = 0 ; i < 10 ; ++ i ){ printf ( "%d" , i * i + i ); }versus
int i ; for ( 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 distintos entornos y al uso combinado de tabulaciones y espacios.
Por ejemplo, un programador prefiere usar cuatro tabulaciones y tiene su conjunto de herramientas configurado de esta manera, y las usa para dar formato a su código.
int ix ; // Índice para escanear el array long sum ; // Acumulador para sumOtro programador prefiere usar tabulaciones de ocho, y su conjunto de herramientas está configurado de esta manera. Cuando alguien más examine el código de la persona original, es muy probable que le resulte difícil de leer.
int ix ; // Índice para escanear el array long sum ; // Acumulador para sumUna solución común a este problema podría consistir en prohibir el uso de tabulaciones para la alineación o establecer reglas sobre cómo deben configurarse las tabulaciones. Cabe destacar que las tabulaciones funcionan correctamente siempre que se utilicen de forma coherente, se restrinjan a la indentación 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 };Véase también
- Ofuscación de código : creación deliberada de código difícil de entender. Páginas que muestran descripciones breves de los destinos de redireccionamiento.
- MISRA C – Estándar de desarrollo de software para el lenguaje de programación C
- Convención de nomenclatura (programación) : conjunto de reglas para nombrar entidades en el código fuente y la documentación.
Referencias
- ↑ "PEP 0008: Guía de estilo para código Python" . python.org.
- Código fuente
- Comparación de lenguajes de programación