Estilo de programación - Programming style

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 de computadora . A menudo se afirma que seguir un estilo de programación en 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 que se considera 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; las 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 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 (hours < 24 && minutes < 60 && seconds < 60) {
    return true;
} else {
    return false;
}

o

if (hours < 24 && minutes < 60 && seconds < 60)
{
    return true;
}
else
{
    return false;
}

con algo como

if  ( hours   < 24
   && minutes < 60
   && seconds < 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 trabaja con 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:

if (hours < 24 && minutes < 60 && seconds < 60)
return true;

else
return false;

Lua

Lua no usa las llaves tradicionales o los paréntesis . Las declaraciones if / else solo requieren que la expresión sea seguida de theny cerrar la declaración if / else con end.

if hours < 24 and minutes < 60 and seconds < 60 then
  return true
else
  return false
end

La sangría es opcional. and, or, notSe utilizan en entre las declaraciones de verdadero / falso.

Son declaraciones verdaderas / falsas, como

print(not true)

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 colocar corchetes con llaves (es decir, {y }). Por otro lado, copiar y pegar código Python puede ocasionar 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 existen 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 "<pre> .. . </pre> "(para HTML )," [código] "..." [/ código] "(para bbcode ), etc.

if hours < 24 and minutes < 60 and seconds < 60:
    return True
else:
    return 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. Existen herramientas diseñadas para automatizar el cumplimiento de PEP8.

Haskell

Haskell tiene de manera similar 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:

let c_1 = 1
    c_2 = 2
in
    f x y = c_1 * x + c_2 * y

se puede escribir en una línea como:

let {c_1=1;c_2=2} in 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 literarios de Haskell (nombrados con la lhsextensión), todo es un comentario excepto los bloques marcados como código. El programa se puede escribir en LaTeX , en tal caso el codeentorno 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:

The function \verb+isValidDate+ test if date is valid
\begin{code}
isValidDate :: Date -> Bool
isValidDate date = hh>=0  && mm>=0 && ss>=0
                 && hh<24 && mm<60 && ss<60
 where (hh,mm,ss) = fromDate date
\end{code}
observe that in this case the overloaded function is \verb+fromDate :: Date -> (Int,Int,Int)+.

Y un ejemplo usando texto sin formato:

The function isValidDate test if date is valid

> isValidDate :: Date -> Bool
> isValidDate date = hh>=0  && mm>=0 && ss>=0
>                  && hh<24 && mm<60 && ss<60
>  where (hh,mm,ss) = fromDate date

observe that in this case the overloaded function is 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:

$search = array('a', 'b', 'c', 'd', 'e');
$replacement = array('foo', 'bar', 'baz', 'quux');

// Another example:

$value = 0;
$anothervalue = 1;
$yetanothervalue = 2;

con:

$search      = array('a',   'b',   'c',   'd',   'e');
$replacement = array('foo', 'bar', 'baz', 'quux');

// Another example:

$value           = 0;
$anothervalue    = 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 correctamente 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 simples de refactorización, 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 hacer un cambio beneficioso, como agregar, corregir o mejorar el nombre de un identificador, porque estropeará el formato.
  • Confianza en 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í:

$search      = array('a',   'b',   'c',   'd',   'e');
$r = array('foo', 'bar', 'baz', 'quux');

// Another example:

$value           = 0;
$a    = 1;
$yetanothervalue = 2;

El formato secuencial original aún se verá bien después de dicho cambio:

$search = array('a', 'b', 'c', 'd', 'e');
$r = array('foo', 'bar', 'baz', 'quux');

// Another example:
 
$value = 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 los espacios 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;
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);
}

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;     // Index to scan array
long    sum;    // Accumulator for sum

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;             // Index to scan array
long    sum;    // Accumulator for sum

Una solución ampliamente utilizada para 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, // first parameter
		int quux); // second parameter
	int foobar2(
		int qux, // first parameter
		int quux, // second parameter
		int quuux); // third parameter
};

Ver también

Referencias

enlaces externos