El estilo de programación , también conocido como estilo de código , es un conjunto de reglas o pautas que se utilizan al escribir el código fuente de un programa informático . A menudo se afirma que seguir un estilo de programación particular ayudará a los programadores a leer y comprender el código fuente que se ajuste al estilo, y ayudará a evitar la introducción de errores.
Un trabajo clásico sobre el tema fue The Elements of Programming Style , escrito en la década de 1970 e ilustrado con ejemplos de los lenguajes Fortran y PL / I predominantes en ese momento.
El estilo de programación utilizado en un programa en particular puede derivarse de las convenciones de codificación de una empresa u otra organización informática, así como de las preferencias del autor del código. Los estilos de programación a menudo se diseñan para un lenguaje de programación específico (o familia de lenguajes): el estilo considerado bueno en el código fuente C puede no ser apropiado para el código fuente BASIC , etc. Sin embargo, algunas reglas se aplican comúnmente a muchos lenguajes.
Elementos de buen estilo
El buen estilo es un asunto subjetivo y difícil de definir. Sin embargo, hay varios elementos comunes a una gran cantidad de estilos de programación. Los problemas que generalmente se consideran parte del estilo de programación incluyen el diseño del código fuente, incluida la sangría ; el uso de espacios en blanco alrededor de operadores y palabras clave; el uso de mayúsculas o no de palabras clave y nombres de variables; el estilo y la ortografía de los identificadores definidos por el usuario, como los nombres de funciones, procedimientos y variables; y el uso y estilo de los comentarios .
Apariencia del código
Los estilos de programación normalmente se ocupan de la apariencia visual del código fuente, con el objetivo de mejorar la legibilidad. Hace mucho tiempo que se dispone de software que formatea el código fuente automáticamente, lo que deja a los codificadores concentrarse en la nomenclatura, la lógica y técnicas superiores. Como punto práctico, usar una computadora para formatear el código fuente ahorra tiempo y luego es posible hacer cumplir los estándares de toda la empresa sin debates .
Sangría
Los estilos de sangría ayudan a identificar el flujo de control y los bloques de código. En algunos lenguajes de programación, la sangría se usa para delimitar bloques lógicos de código; la sangría correcta en estos casos es más que una cuestión de estilo. En otros lenguajes, la sangría y los espacios en blanco no afectan la función, aunque la sangría lógica y coherente hace que el código sea más legible. Comparar:
if ( horas < 24 && minutos < 60 && segundos < 60 ) { return true ; } else { devolver falso ; }
o
if ( horas < 24 && minutos < 60 && segundos < 60 ) { return true ; } else { devolver falso ; }
con algo como
if ( horas < 24 && minutos < 60 && segundos < 60 ) { return true ;} else { return false ;}
Los dos primeros ejemplos son probablemente mucho más fáciles de leer porque están sangrados de una manera establecida (un estilo de "párrafo colgante"). Este estilo de sangría es especialmente útil cuando se trata de múltiples construcciones anidadas.
ModuLiq
Los grupos de estilo ModuLiq Zero Indentation con retornos de carro en lugar de indentaciones. Compare todo lo anterior con:
si ( horas < 24 && minutos < 60 && segundos < 60 ) devuelve verdadero ;si no devuelve falso ;
Lua
Lua no usa las llaves tradicionales o los paréntesis . Las sentencias if / else solo requieren que la expresión sea seguida de then
, y cerrar la sentencia if / else con end
.
si las horas < 24 y los minutos < 60 y los segundos < 60 , devuelve verdadero; de lo contrario, devuelve falso final
La sangría es opcional. and
, or
, not
Se utilizan en entre las declaraciones de verdadero / falso.
Son declaraciones verdaderas / falsas, como
imprimir ( no es cierto )
significaría falso.
Pitón
Python usa sangría para indicar estructuras de control, por lo que se requiere una sangría correcta . Al hacer esto, se elimina la necesidad de usar corchetes con llaves (es decir, {
y }
). Por otro lado, copiar y pegar código Python puede generar 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 actual. Este reformateo puede resultar tedioso a mano, pero algunos editores de texto e IDE tienen funciones para hacerlo automáticamente. También hay problemas cuando el código Python 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 cuando es posible incluir código en etiquetas que preservan los espacios en blanco, como "
.. ."(para HTML )," [código] "..." [/ código] "(para bbcode ), etc.
si las horas < 24 y los minutos < 60 y los segundos < 60 : devuelve True else : devuelve False
Tenga en cuenta que Python no usa llaves, sino dos puntos regulares (p else:
. Ej .).
Muchos 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
De manera similar, Haskell tiene la regla de fuera de juego , es decir, tiene una sintaxis de dos dimensiones donde la sangría es significativa para definir bloques (aunque, una sintaxis alternativa usa llaves y punto y coma). Haskell es un lenguaje declarativo, hay declaraciones, pero declaraciones dentro de un script de Haskell. Ejemplo:
sea c_1 = 1 c_2 = 2 en f x y = c_1 * x + c_2 * y
se puede escribir 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 alfabetizada , donde el texto extendido explica la génesis del código. En los scripts de Haskell alfabetizados (nombrados con la lhs
extensión), todo es un comentario excepto los bloques marcados como código. El programa se puede escribir en LaTeX , en tal caso el code
entorno marca lo que es código. Además, cada párrafo de código activo se puede marcar 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í un ejemplo usando marcado 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 sin formato:
La función isValidDate prueba si la fecha es válida> isValidDate :: Date -> Bool > isValidDate date = 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 ) .
Alineamiento vertical
A menudo es útil alinear elementos similares verticalmente para hacer más obvios los errores generados por errores tipográficos. Comparar:
$ búsqueda = matriz ( 'a' , 'b' , 'c' , 'd' , 'e' ); $ reemplazo = matriz ( 'foo' , 'bar' , 'baz' , 'quux' );// Otro ejemplo:$ valor = 0 ; $ otro valor = 1 ; $ yetanothervalue = 2 ;
con:
$ búsqueda = matriz ( 'a' , 'b' , 'c' , 'd' , 'e' ); $ reemplazo = matriz ( 'foo' , 'bar' , 'baz' , 'quux' );// Otro ejemplo:$ valor = 0 ; $ otro valor = 1 ; $ yetanothervalue = 2 ;
El último ejemplo deja dos cosas intuitivamente claras que no estaban claras en el primero:
- los términos de búsqueda y reemplazo están relacionados y coinciden: no son variables discretas;
- hay un término de búsqueda más que términos de reemplazo. Si se trata de un error, ahora es más probable que se detecte.
Sin embargo, tenga en cuenta que existen argumentos en contra de la alineación vertical:
- Dependencias falsas entre líneas ; el formato tabular crea dependencias entre líneas. Por ejemplo, si se agrega un identificador con un nombre largo a un diseño tabular, es posible que deba aumentarse el ancho de la columna para acomodarlo. Esto obliga a un cambio en el código fuente más grande de lo necesario, y el cambio esencial puede perderse en el ruido. Esto es perjudicial para el control de revisiones, donde es esencial inspeccionar las diferencias entre las versiones.
- Fragilidad ; si un programador no formatea cuidadosamente la tabla al hacer un cambio, quizás legítimamente teniendo en cuenta el punto anterior, el resultado se convierte en un desastre que se deteriora con más cambios de este tipo. Las operaciones de refactorización simples, como buscar y reemplazar, también pueden romper el formato.
- Resistencia a la modificación ; el formato tabular requiere más esfuerzo de mantenimiento. Esto puede disuadir a un programador de realizar un cambio beneficioso, como agregar, corregir o mejorar el nombre de un identificador, porque estropeará el formato.
- Dependencia de la fuente monoespaciada ; El formato tabular asume que el editor usa una fuente de ancho fijo. Muchos editores de código modernos admiten fuentes proporcionales y el programador puede preferir utilizar una fuente proporcional para facilitar la lectura.
- Dependencia de herramientas ; parte del esfuerzo de mantener la alineación puede aliviarse con herramientas (por ejemplo, un editor de código fuente que admita tabstops elásticas ), aunque eso crea una dependencia de tales herramientas.
Por ejemplo, si se realiza una operación de refactorización simple en el código anterior, cambiando el nombre de las variables "$ reemplazo" a "$ r" y "$ otro valor" a "$ a", el código resultante se verá así:
$ búsqueda = matriz ( 'a' , 'b' , 'c' , 'd' , 'e' ); $ r = matriz ( 'foo' , 'bar' , 'baz' , 'quux' );// Otro ejemplo:$ valor = 0 ; $ a = 1 ; $ yetanothervalue = 2 ;
El formato secuencial original aún se verá bien después de dicho cambio:
$ búsqueda = matriz ( 'a' , 'b' , 'c' , 'd' , 'e' ); $ r = matriz ( 'foo' , 'bar' , 'baz' , 'quux' );// Otro ejemplo: $ valor = 0 ; $ a = 1 ; $ yetanothervalue = 2 ;
Espacios
En aquellas situaciones en las que se requiere algo de espacio en blanco , las gramáticas de la mayoría de los lenguajes de formato libre no se preocupan por la cantidad que aparece. El estilo relacionado con el espacio en blanco se usa comúnmente para mejorar la legibilidad . Actualmente no se conocen hechos concretos (conclusiones de estudios) sobre cuál de los estilos de espacios en blanco tiene la mejor legibilidad.
Por ejemplo, compare los siguientes ejemplos sintácticamente equivalentes de código C:
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 ); }
Pestañas
El uso de pestañas para crear espacios en blanco presenta problemas particulares cuando no se tiene suficiente cuidado porque la ubicación del punto de tabulación puede ser diferente según las herramientas que se utilicen e incluso las preferencias del usuario.
Como ejemplo, un programador prefiere tabulaciones de cuatro y tiene su conjunto de herramientas configurado de esta manera, y las usa para formatear su código.
int ix ; // Índice para escanear matriz de suma larga ; // Acumulador por suma
Otro programador prefiere tabulaciones de ocho, y su conjunto de herramientas está configurado de esta manera. Cuando alguien más examina el código de la persona original, es posible que le resulte difícil leerlo.
int ix ; // Índice para escanear matriz de suma larga ; // Acumulador por suma
Una solución ampliamente utilizada a este problema puede implicar prohibir el uso de pestañas para la alineación o reglas sobre cómo se deben establecer las tabulaciones. Tenga en cuenta que las pestañas funcionan bien siempre que se utilicen de forma coherente, se restrinjan a la sangría lógica y no se utilicen para la alineación:
class 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 };
Ver también
Referencias
- ^ "PEP 0008 - Guía de estilo para código Python" . python.org.