En programación informática , el estilo de sangría es una convención , también conocida como estilo , que rige la sangría de bloques de código fuente . Un estilo de sangría generalmente implica un ancho constante de espacio en blanco (tamaño de sangría) antes de cada línea de un bloque, de modo que las líneas de código parezcan estar relacionadas y dicta si se deben usar espacios o caracteres de tabulación para el espacio en blanco de sangría.
Este artículo aborda principalmente estilos para lenguajes de programación de formato libre . Como su nombre lo indica, dicho código de idioma no necesita seguir un estilo de sangría. La sangría es una notación secundaria que a menudo tiene como objetivo reducir la carga cognitiva para que un programador comprenda la estructura del código. La sangría puede aclarar la separación entre el código ejecutado en función del flujo de control .
Los lenguajes estructurados, como Python y occam , utilizan sangría para determinar la estructura en lugar de utilizar llaves o palabras clave; esto se denomina regla del fuera de juego . En dichos lenguajes, la sangría es significativa para el procesador del lenguaje (como el compilador o el intérprete ). Un programador debe cumplir con las reglas de sangría del lenguaje, aunque puede tener la libertad de elegir el tamaño de sangría.
Este artículo se centra en los lenguajes entre llaves (que delimitan bloques con llaves, también conocidos como llaves, también conocidos como llaves ) y en particular en los lenguajes de la familia C , pero una convención utilizada para un idioma se puede adaptar a otro idioma. Por ejemplo, un lenguaje que utiliza palabras clave BEGIN
y END
en lugar de llaves se puede adaptar tratándolo BEGIN
como la llave abierta, etc.
El estilo de sangría solo se aplica a idiomas basados en texto. Los lenguajes de programación visual no tienen sangría.
A pesar del uso omnipresente de estilos de sangría, se han realizado pocas investigaciones sobre su valor. Los primeros experimentos realizados por Weissman en 1974 no mostraron ningún efecto. [1]
En 2023, un experimento de Morzeck et al. [2] mostró un efecto positivo significativo para if
las declaraciones anidadas donde el código sin sangría requirió en promedio un 179% más de tiempo para leer que el código con sangría.
La siguiente tabla incluye ejemplos de código de varios estilos de sangría. Para mantener la coherencia, el tamaño de la sangría, por ejemplo, en el código, es de 4 espacios, aunque varía según la convención de codificación.
Los atributos de C , C++ y otros estilos de codificación de lenguajes de programación con llaves incluyen, entre otros:
else if
construcción y un do{}while
bloque).El estilo Kernighan & Ritchie (K&R) se usa comúnmente para código C y C++ y es la base de muchos estilos derivados. Se utiliza en el kernel Unix original, en el libro de Kernighan y Ritchie The C Programming Language , así como en el libro de Kernighan y Plauger The Elements of Programming Style .
Aunque el lenguaje de programación C no define explícitamente este estilo, lo sigue de manera consistente. Del libro:
La posición de los frenillos es menos importante, aunque la gente tiene creencias apasionadas. Hemos elegido uno de varios estilos populares. Elija un estilo que se adapte a sus necesidades y luego úselo de manera constante.
En este estilo, una función tiene sus llaves de apertura y cierre en sus propias líneas y con la misma sangría que la declaración, y con declaraciones con sangría de un nivel adicional que la declaración. Sin embargo, un bloque de instrucciones múltiples dentro de una función tiene su llave de apertura en la misma línea que su cláusula de control, mientras que la llave de cierre permanece en su propia línea a menos que vaya seguida de una palabra clave como else
o while
.
Código de ejemplo:
int main ( int argc , char * argv []) { while ( x == y ) { hacer_algo (); hacer algo más (); si ( algún_error ) fix_issue (); // bloque de declaración única sin llaves else continue_as_usual (); } cosa_final (); }
Los tirantes no alineados de los bloques de varias líneas reciben el sobrenombre de "tirantes egipcios" (o "corchetes egipcios") por su parecido con los brazos en algunas poses extravagantes de los antiguos egipcios. [3] [4] [5]
Un bloque de una sola declaración no tiene llaves, lo que es una causa de errores fáciles de pasar por alto, como el error goto fail .
El estilo One True Brace [6] (abreviado 1TBS u OTBS [7] ) es como el estilo K&R, pero las funciones tienen el formato de bloques de instrucciones múltiples con la llave de apertura en la misma línea que la declaración, y las llaves no se omiten para un bloque de una sola declaración. [8]
bool is_negative ( int x ) { if ( x < 0 ) { return true ; } más { return false ; } }
Aunque no es necesario en lenguajes como C/C++, el uso de llaves para bloques de una sola declaración garantiza que la inserción de una declaración no dé como resultado un flujo de control que no esté de acuerdo con la sangría, como se ve, por ejemplo, en el infame error goto fail de Apple .
Las ventajas citadas incluyen un código más corto (que K&R), ya que la llave inicial no necesita línea adicional y la llave final se alinea con la declaración a la que conceptualmente pertenece. Un costo de este estilo es que la llave final agrega una línea, que puede resolverse parcialmente en bloques if/else y do/ while.
Las fuentes no están de acuerdo en cuanto al significado de One True Brace Style. Algunos dicen que es la variación especificada aquí, [8] mientras que otros dicen que es "jerga hacker" para K&R. [9]
El árbol de fuentes del kernel de Linux tiene el estilo de una variante de K&R. [10] Linus Torvalds aconseja a los contribuyentes que lo sigan. Los atributos incluyen:
switch
declaración están alineadas con el bloque circundante (solo hay un nivel de sangría)if-else
declaración requieren llaves, entonces ambas subdeclaraciones deben estar entre llaves:int potencia ( int x , int y ) { int resultado ; si ( y < 0 ) { resultado = 0 ; } más { resultado = 1 ; mientras ( y - > 0 ) resultado *= x ; } devolver resultado ; }
Una parte importante del código Java utiliza una variante del estilo K&R en el que la llave de apertura está en la misma línea no sólo para los bloques dentro de una función, sino también para las declaraciones de clases o métodos. Este estilo está muy extendido en gran medida porque las guías de estilo originales de Sun Microsystems [12] [13] [14] usaban esta variante de K&R y, como resultado, la mayor parte del código fuente estándar para la API de Java está escrito en este estilo. También es un estilo de sangría popular para ActionScript y JavaScript , junto con el estilo Allman.
Bjarne Stroustrup adaptó el estilo K&R para C++ en sus libros, como Programación: principios y práctica usando C++ y El lenguaje de programación C++ . [15]
A diferencia de las variantes anteriores, Stroustrup no utiliza un "otra persona abrazada". Así, Stroustrup escribiría [15]
si ( x < 0 ) { pone ( "Negativo" ); negativo ( x ); } else { puts ( "No negativo" ); no negativo ( x ); }
Stroustrup amplía el estilo K&R para las clases, escribiéndolas de la siguiente manera:
clase Vector { public : // construye un Vector Vector ( int s ) : elem ( new double [ s ]), sz ( s ) { } // acceso al elemento: subíndice doble & operador []( int i ) { return elem [ i ]; } int tamaño () { return tamaño ; } private : // puntero a los elementos double * elem ; // número de elementos int sz ; };
Stroustrup no sangra las etiquetas public:
y private:
. Además, en este estilo, mientras que la llave de apertura de una función comienza en una nueva línea, la llave de apertura de una clase está en la misma línea que el nombre de la clase.
Stroustrup permite escribir funciones cortas en una sola línea. El estilo Stroustrup es un estilo de sangría con nombre disponible en el editor Emacs . Stroustrup fomenta un diseño de estilo derivado de K&R con C++ como se indica en sus modernas Directrices básicas de C++ . [dieciséis]
Los sistemas operativos Berkeley Software Distribution (BSD) utilizan un estilo que a veces se denomina Kernel Normal Form (KNF). Aunque está destinado principalmente al código del kernel, también se utiliza ampliamente en el código del usuario . Es esencialmente una variante completamente documentada del estilo K&R tal como se usa en el código fuente Unix de las versiones 6 y 7 de Bell Labs . [17]
El kernel y el área de usuario de SunOS utilizan un estilo de sangría similar. [17] Al igual que KNF, esto también se basó en documentos de estilo AT&T y a veces se denomina Formulario normal Bill Joy. [18] La directriz SunOS se publicó en 1996; ANSI C se analiza brevemente. La exactitud de la sangría de una lista de archivos fuente se puede verificar mediante el programa cstyle escrito por Bill Shannon. [17] [18] [19]
En este estilo, el tabulador físico (ts en vi ) se mantiene en ocho columnas, mientras que un tabulador flexible a menudo también se define como auxiliar (sw en vi) y se establece en cuatro. Los tabuladores duros se utilizan para sangrar bloques de código, mientras que un tabulador suave (cuatro espacios) de sangría adicional se utiliza para todas las líneas continuas que deben dividirse en varias líneas.
Además, las llamadas a funciones no utilizan un espacio antes del paréntesis, aunque las declaraciones nativas del lenguaje C como if
, while
, do
y do (en el caso de que se utilicen con paréntesis). Las funciones que no declaran variables locales en su bloque de nivel superior también deben dejar una línea vacía después de la llave del bloque de apertura.switch
return
return
Ejemplos:
mientras ( x == y ) { algo (); algo más (); } cosa_final ();
if ( datos != NULL && res > 0 ) { if ( JS_DefineProperty ( cx , o , "datos" , STRING_TO_JSVAL ( JS_NewStringCopyN ( cx , datos , res )), NULL , NULL , JSPROP_ENUMERATE ) != 0 ) { QUEUE_EXCEPTION ( " ¡Error interno!" ); ir a errar ; } PQfreemem ( datos ); } else { if ( JS_DefineProperty ( cx , o , "datos" , OBJECT_TO_JSVAL ( NULL ), NULL , NULL , JSPROP_ENUMERATE ) ! = 0 ) { QUEUE_EXCEPTION ( "¡Error interno!" ); ir a errar ; } }
JSBool estático pgresult_constructor ( JSContext * cx , JSObject * obj , uintN argc , jsval * argv , jsval * rval ) { QUEUE_EXCEPTION ( "La clase PGresult no es instanciable por el usuario" ); retorno ( JS_FALSE ); }
El estilo Allman lleva el nombre de Eric Allman . A veces también se le denomina estilo BSD ya que Allman escribió muchas de las utilidades para BSD Unix (aunque esto no debe confundirse con el diferente "estilo BSD KNF"; ver arriba).
Este estilo coloca la llave asociada con una declaración de control en la línea siguiente, con sangría al mismo nivel que la declaración de control. Las declaraciones entre llaves tienen sangría al siguiente nivel. [9]
mientras ( x == y ) { algo (); algo más (); } cosa_final ();
Este estilo es similar a la sangría estándar utilizada por los lenguajes Pascal y Transact-SQL , donde las llaves equivalen a las palabras clave begin
y end
.
(* Ejemplo de estilo de sangría de código Allman en Pascal *) procedimiento hacer algo ( x , y : entero ) ; comenzar mientras x = y comenzar algo ( ) ; algo más () ; fin ; fin ;
Las consecuencias de este estilo son que el código sangrado se distingue claramente de la declaración que lo contiene mediante líneas que son casi todas espacios en blanco y la llave de cierre se alinea en la misma columna que la llave de apertura. Algunas personas sienten que esto hace que sea más fácil encontrar aparatos ortopédicos compatibles. El estilo de bloqueo también delimita el bloque de código de la declaración de control asociada. Es menos probable que comentar o eliminar una declaración de control o un bloque de código, o la refactorización de código , introduzca errores de sintaxis debido a llaves colgantes o faltantes. Además, es coherente con la colocación de aparatos ortopédicos para el bloque de función exterior.
Por ejemplo, lo siguiente sigue siendo correcto sintácticamente:
// mientras (x == y) { algo (); algo más (); }
Como es esto:
// for (int i=0; i < x; i++) // while (x == y) if ( x == y ) { algo (); algo más (); }
Incluso así, con compilación condicional:
intc ; #ifdef HAS_GETCH mientras (( c = getch ()) != EOF ) #else while (( c = getchar ()) != EOF ) #endif { hacer_algo ( c ); }
Una variante popular para su uso en educación, [ cita necesaria ] Allman-8 utiliza las pestañas de sangría de 8 espacios y el límite de 80 columnas de la variante del kernel de Linux de K&R. El estilo supuestamente ayuda a mejorar la legibilidad en los proyectores. Además, el tamaño de sangría y la restricción de columnas ayudan a crear una señal visual para identificar el anidamiento excesivo de bloques de código. Estas ventajas se combinan para ayudar a proporcionar a los nuevos desarrolladores y estudiantes una guía implícita para gestionar la complejidad del código. [ cita necesaria ]
El estilo Whitesmiths, también denominado a veces estilo Wishart, se utilizó originalmente en la documentación del primer compilador comercial de C, el Whitesmiths Compiler. También fue popular en los primeros días de Windows, ya que se usó en tres influyentes libros de programación de Windows, la Guía del programador de Windows de Durant, Carlson & Yao, la Programación de Windows de Petzold y las Técnicas de programación energética de Windows 3.0 de Norton & Yao.
El Jargon File afirmó en 1991 que Whitesmiths, junto con Allman, eran los estilos de refuerzo más comunes , con aproximadamente la misma popularidad en ese momento. [9] [20]
Este estilo coloca la llave asociada con una declaración de control en la siguiente línea, con sangría. Las declaraciones dentro de las llaves tienen sangría al mismo nivel que las llaves.
Al igual que el estilo Ratliff, la llave de cierre tiene la misma sangría que las declaraciones dentro de las llaves. [21]
mientras ( x == y ) { algo (); algo más (); } cosa_final ();
Las ventajas de este estilo son similares a las del estilo Allman. Los bloques están claramente diferenciados de las declaraciones de control. La alineación de las llaves con el bloque enfatiza que el bloque completo es conceptual y programáticamente una declaración compuesta. La sangría de las llaves enfatiza que están subordinadas a la declaración de control. La llave final ya no se alinea con la declaración, sino con la llave inicial.
Un ejemplo:
if ( datos != NULL && res > 0 ) { if ( ! JS_DefineProperty ( cx , o , "datos" , STRING_TO_JSVAL ( JS_NewStringCopyN ( cx , datos , res )), NULL , NULL , JSPROP_ENUMERATE )) { QUEUE_EXCEPTION ( "Error interno !" ); ir a errar ; } PQfreemem ( datos ); } else if ( ! JS_DefineProperty ( cx , o , "datos" , OBJECT_TO_JSVAL ( NULL ), NULL , NULL , JSPROP_ENUMERATE )) { QUEUE_EXCEPTION ( "¡Error interno!" ); ir a errar ; }
else if
se tratan como declaraciones, muy parecidas a las #elif
declaraciones del preprocesador.
Al igual que los estilos Allman y Whitesmiths, el estilo GNU coloca llaves en una línea por sí mismas, con sangría de dos espacios, excepto cuando se abre una definición de función, donde no tienen sangría. [22] En cualquier caso, el código contenido tiene una sangría de dos espacios a partir de las llaves.
Popularizado por Richard Stallman , el diseño puede estar influenciado por su experiencia en la escritura de código Lisp . [23] En Lisp, el equivalente a un bloque (un programa) es una entidad de datos de primera clase, y darle su propio nivel de sangría ayuda a enfatizar eso, mientras que en C, un bloque es solo sintaxis. Este estilo también se puede encontrar en algunos libros de texto de lenguajes de programación ALGOL y XPL de las décadas de 1960 y 1970. [24] [25] [ discutir ]
Aunque no es una sangría per se, el estilo de codificación GNU también incluye un espacio después del nombre de una función, antes del paréntesis izquierdo de una lista de argumentos. [22]
char * s2 estático ( char * s1 , char * s2 ) { while ( x == y ) { algo (); algo más (); } cosa_final (); }
Este estilo combina las ventajas de Allman y Whitesmiths, eliminando así la posible desventaja de Whitesmiths de que los frenillos no sobresalgan del bloque. Una desventaja es que la llave final ya no se alinea con la declaración a la que pertenece conceptualmente. Otra posible desventaja es que se podría desperdiciar espacio al usar dos niveles visuales de sangría para un nivel conceptual, pero en realidad esto es poco probable porque, en sistemas con sangría de un solo nivel, cada nivel suele tener al menos 4 espacios, lo mismo que 2 * 2 espacios al estilo GNU.
Los estándares de codificación GNU recomiendan este estilo y casi todos los mantenedores de software de proyectos GNU lo utilizan. [ cita necesaria ]
El editor de texto GNU Emacs y el comando de sangría de los sistemas GNU reformatearán el código de acuerdo con este estilo de forma predeterminada. [26] Aquellos que no usan GNU Emacs, o editores extensibles/personalizables similares, pueden encontrar que la configuración de sangría automática de su editor no es útil para este estilo. Sin embargo, muchos editores que utilizan de forma predeterminada el estilo KNF se adaptan bien al estilo GNU cuando el ancho de la pestaña se establece en dos espacios; Asimismo, GNU Emacs se adapta bien al estilo KNF simplemente estableciendo el ancho de la pestaña en ocho espacios. En ambos casos, el reformateo automático destruye el espaciado original, pero la sangría de línea automática funcionará correctamente.
Steve McConnell , en su libro Code Complete , desaconseja el uso de este estilo: marca un ejemplo de código que lo utiliza con un icono "Coding Horror", que simboliza un código especialmente peligroso, y afirma que impide la legibilidad. [21] La documentación sobre el estilo de codificación del kernel de Linux también desaconseja este estilo, instando a los lectores a grabar una copia de los estándares de codificación GNU como un "gran gesto simbólico". [27]
La edición de 1997 de Computing Concepts with C++ Essentials de Cay S. Horstmann adapta a Allman colocando la primera declaración de un bloque en la misma línea que la llave de apertura. Este estilo también se utiliza en ejemplos del Informe y manual del usuario de Pascal de Jensen y Wirth . [28]
mientras ( x == y ) { algo (); algo más (); //... si ( x < 0 ) { printf ( "Negativo" ); negativo ( x ); } else { printf ( "No negativo" ); no negativo ( x ); } } cosa_final ();
Este estilo combina las ventajas de Allman al mantener la alineación vertical de los tirantes para facilitar la lectura e identificar los bloques fácilmente, con el ahorro de una línea del estilo K&R. Sin embargo, la edición de 2003 utiliza ahora el estilo Allman en todas partes. [29]
Este es el estilo más utilizado en el lenguaje Pico por sus diseñadores. Pico carece de declaraciones de retorno y utiliza punto y coma como separadores de declaraciones en lugar de terminadores. Produce esta sintaxis: [30]
cosas(n):{ x: 3 * n; y: hacer_cosas(x); y+x}
Las ventajas y desventajas son similares a las de guardar el espacio en pantalla con el estilo K&R. Una ventaja adicional es que las llaves de inicio y cierre son consistentes en la aplicación (ambas comparten espacio con una línea de código), en relación con el estilo K&R, donde una llave comparte espacio con una línea de código y una llave tiene una línea sola.
En el libro Programmers at Work , [31] C. Wayne Ratliff, el programador original detrás de los populares lenguajes de programación de cuarta generación dBase -II y -III , analizó un estilo que es como 1TBS pero la llave de cierre se alinea con la sangría de el bloque anidado. Indicó que el estilo fue documentado originalmente en material de Digital Research Inc. Este estilo a veces se ha denominado estilo pancarta , [32] posiblemente por el parecido con una pancarta que cuelga de un poste. En este estilo, que es para Whitesmiths lo que K&R es para Allman, el control de cierre tiene la misma sangría que el último elemento de la lista (y por lo tanto pierde prominencia) [21] El estilo puede facilitar el escaneo visual para algunos, ya que el los encabezados de cualquier bloque son lo único que se extiende a ese nivel (la teoría es que el control de cierre del bloque anterior interfiere con el flujo visual del encabezado del siguiente bloque en los estilos K&R y Allman). Kernighan y Plauger utilizan este estilo en el código Ratfor en Herramientas de software . [33]
// En C for ( i = 0 ; i < 10 ; i ++ ) { if ( i % 2 == 0 ) { hacer_algo ( i ); } más { hacer_algo_más ( yo ); } }
Los siguientes estilos son comunes para varios lenguajes derivados de C que son significativamente similares y diferentes. Y también se pueden adaptar a C. Se podrían aplicar al código C escrito como parte de un proyecto escrito principalmente en uno de estos otros lenguajes, donde mantener una apariencia consistente en el código central del proyecto anula las consideraciones de usar un estilo C más convencional.
Si bien el estilo GNU a veces se caracteriza como código C sangrado por un programador Lisp, uno podría incluso ir tan lejos como para insertar llaves de cierre juntas en la última línea de un bloque. Este estilo hace que la sangría sea la única forma de distinguir bloques de código, pero tiene la ventaja de no contener líneas que no contengan información. Esto podría denominarse fácilmente estilo Lisp porque este estilo es muy común en el código Lisp. En Lisp, la agrupación de llaves idénticas al final de los árboles de expresión pretende significar que no es trabajo del usuario rastrear visualmente los niveles de anidamiento, solo comprender la estructura del árbol.
La variante Lisp tradicional de este estilo prefiere niveles de sangría extremadamente estrechos (típicamente dos espacios) porque el código Lisp generalmente anida muy profundamente ya que Lisp presenta solo expresiones , sin ninguna clase distinta de declaraciones ; Los argumentos de función en su mayoría tienen sangría al mismo nivel para ilustrar su estado compartido dentro de la expresión adjunta. Esto también se debe a que, dejando de lado las llaves, Lisp es convencionalmente un lenguaje muy conciso, que omite incluso formas comunes de código repetitivo simple por no ser informativas, como la else
palabra clave en un if : then | else
bloque, y en su lugar lo representa uniformemente como (if expr1 expr2 expr3)
.
// C para ( i = 0 ; i < 10 ; i ++ ) { if ( i % 2 == 0 ) { hacer_algo ( i );} else { hacer_algo_otro ( i ); hacer_tercera_cosa ( yo );}}
;; Lisp ( dotimes ( i 10 ) ( if ( = ( rem i 2 ) 0 ) ( hacer algo i ) ( progn ( hacer algo más i ) ( hacer una tercera cosa i ))))
Nota: progn
es un procedimiento para evaluar múltiples subexpresiones secuencialmente para efectos , mientras se descarta todo excepto el valor de retorno final (enésimo). Si se desean todos los valores de retorno, values
se utilizaría el procedimiento.
El diseño de Haskell puede hacer que la colocación de llaves sea opcional, aunque en el idioma se permiten llaves y punto y coma. [34] Los dos segmentos siguientes son igualmente aceptables para el compilador:
braceless = do text <- getContents let firstWord = head $ palabras text bigWord = map toUpper firstWord putStrLn bigWord braceful = hacer { texto < -getContents ; let { primeraPalabra = encabezado $ palabras texto ; palabra grande = asignar a la primera palabra superior } ; putStrLn palabra grande }
En Haskell, el diseño puede reemplazar las llaves. Generalmente se omiten las llaves y el punto y coma para las secciones de procedimiento do
y el texto del programa en general, pero el estilo se usa comúnmente para listas, registros y otros elementos sintácticos compuestos por algún par de paréntesis o llaves, que se separan con comas o punto y coma. [35] Si el código que sigue a las palabras clave where
, let
u of
omite llaves y punto y coma, entonces la sangría es significativa. [36]
Para ver un ejemplo de cuán conciso suele ser APL, aquí está la implementación de la función de paso para Game of Life:
vida ← { ⊃ 1 ⍵ ∨ . ∧ 3 4 =+ / + ⌿ ¯1 0 1 ∘. ⊖ ¯1 0 1 ⌽ ¨ ⊂ ⍵ }
El estilo C de APL se parece al estilo conciso del código APL y se usa comúnmente en sus implementaciones. [37] Este estilo fue iniciado por Arthur Whitney y se utiliza mucho en la implementación de K , el propio proyecto de Arthur. El lenguaje de programación J también se implementa con este estilo. En particular, no todas las implementaciones de APL utilizan este estilo de C, a saber: GNU APL y Dyalog APL.
Además de la sangría C estilo APL, normalmente los nombres se acortan a caracteres simples o dobles: para reducir la cantidad de sangría y expresiones que abarcan varias líneas. [ cita necesaria ]
Python no usa llaves. La sangría define los bloques en lo que se llama la regla del fuera de juego .
para i en el rango ( 10 ): si i % 2 == 0 : hacer_algo ( i ) más : hacer_algo_más ( i ) hacer_tercera_cosa ( i )
Convencionalmente, la sangría es de cuatro espacios. También son posibles las pestañas. [38]
Normalmente, los programadores utilizan el mismo ancho de espacio en blanco para sangrar cada bloque de código con anchos de uso común que varían de 1 a 4 espacios.
Un experimento realizado con código PASCAL en 1983 encontró que el tamaño de la sangría afectaba significativamente la comprensibilidad. Los tamaños de sangría entre 2 y 4 caracteres resultaron óptimos. [39] Para Ruby , muchos lenguajes de scripting de shell y algunas formas de formato HTML , generalmente se utilizan dos espacios por nivel de sangría. [ cita necesaria ]
Aunque ambos afectan el diseño general del código, el tamaño de la sangría es independiente del estilo de sangría que se analiza aquí.
Normalmente, un programador utiliza un editor de texto que proporciona tabulaciones a intervalos fijos (una cantidad de espacios), para ayudar a mantener los espacios en blanco de acuerdo con un estilo. El intervalo se llama ancho de pestaña . A veces, el programador almacena el código con caracteres de tabulación: uno por cada tecla de tabulación que se presiona o almacena una secuencia de espacios igual en número al ancho de la pestaña.
Almacenar caracteres de tabulación en el código puede causar una desalineación visual cuando se ve en diferentes contextos, lo que contrarresta el valor del estilo de sangría.
Los programadores carecen de consenso sobre el almacenamiento de caracteres de tabulación. Los defensores del almacenamiento de caracteres de tabulación citan la facilidad de escritura y archivos de texto más pequeños, ya que un solo carácter de tabulación sirve para múltiples espacios. Los oponentes, como Jamie Zawinski , afirman que el uso de espacios aumenta la portabilidad multiplataforma . [40] Otros, como los autores de los estándares de codificación de WordPress , afirman lo contrario: que las pestañas duras aumentan la portabilidad. [41] Una encuesta de los 400.000 repositorios principales en GitHub encontró que los espacios son más comunes. [42]
Muchos editores de texto, incluidos Notepad++ , TextEdit , Emacs , vi y nano , se pueden configurar para almacenar caracteres de tabulación cuando se ingresan mediante la tecla tab o para convertirlos en espacios (según el ancho de tabulación configurado) para que los caracteres de tabulación no se muestren. agregado al archivo cuando se presiona la tecla tab. Algunos editores pueden convertir tabulaciones en caracteres de espacio y viceversa.
Algunos buscapersonas de archivos de texto , como less , se pueden configurar para un ancho de pestaña. Algunas herramientas, como expandir / desexpandir, pueden realizar conversiones sobre la marcha mediante filtros.
Una herramienta puede automatizar el formato del código según un estilo de sangría, por ejemplo, el comando Unix . indent
Emacs proporciona comandos para modificar la sangría, incluido presionar Tab
una línea determinada. M-x indent-region
código de sangría.
Tabulaciones elásticas es un estilo de tabulación que requiere soporte del editor de texto, donde bloques enteros de texto se mantienen alineados automáticamente cuando cambia la longitud de una línea en el bloque.
En códigos más complicados, el programador puede perder la noción de los límites de los bloques mientras lee el código. Esto suele ocurrir en grandes secciones de código que contienen muchas declaraciones compuestas anidadas en muchos niveles de sangría. A medida que el programador se desplaza hasta el final de un enorme conjunto de declaraciones anidadas, puede perder la noción del contexto, como la estructura de control en la parte superior del bloque.
Las declaraciones compuestas largas pueden ser un código que huele a una complejidad excesiva que puede resolverse mediante la refactorización .
Los programadores que dependen del recuento de llaves de apertura pueden tener dificultades con estilos de sangría como K&R, donde la llave inicial no está visualmente separada de su declaración de control . Los programadores que dependen más de las sangrías obtendrán más beneficios de los estilos que son verticalmente compactos, como K&R, porque los bloques son más cortos.
Para evitar perder la pista de declaraciones de control como for
, se puede utilizar una sangría grande, como una pestaña dura de 8 unidades de ancho, además de dividir funciones grandes en funciones más pequeñas y más legibles. Linux se hace de esta manera, utilizando el estilo K&R.
Algunos editores de texto permiten al programador saltar entre las dos llaves correspondientes de un bloque. Por ejemplo, vi salta a la llave que encierra el mismo bloque que el que está debajo del cursor al presionar la %
tecla. Dado que la tecla del cursor de texto next
(es decir, la n
tecla) retenía información de posicionamiento direccional (ya sea que se presionara anteriormente la tecla up
o ), la macro de puntos (la tecla) podría usarse para colocar el cursor de texto en la siguiente llave, [43] dado un estilo de codificación adecuado. En su lugar, se puede utilizar la inspección de los límites del bloque utilizando la clave para hacer cumplir un estándar de codificación.down
.
%
Otra forma de mantener el conocimiento del bloque es utilizar comentarios después de la llave de cierre. Por ejemplo:
para ( int i = 0 ; i < total ; i ++ ) { foo (); } //para (i)
si ( x < 0 ) { barra (); } //si (x < 0)
Una desventaja es mantener el mismo código en varias ubicaciones, encima y debajo del bloque.
Algunos editores brindan soporte para mantener el conocimiento de los bloques. Un editor de plegado puede ocultar (plegar) y revelar (desplegar) bloques por nivel de sangría. Algunos editores resaltan las llaves coincidentes cuando el cursor se coloca al lado de una.
El estilo K&R evita el error común causado al insertar una línea de código después de una declaración de control, antes de la llave de apertura. La línea insertada hace que el bloque se desasocia de la declaración de control.
Dado este código inicial:
para ( int i = 0 ; i < 10 ; i ++ ) { hacer_algo (); } //para (yo)
do_something
Será llamado 10 veces. Luego, se modifica añadiendo una nueva segunda línea:
para ( int i = 0 ; i < 10 ; i ++ ) hacer algo más ();{ hacer algo (); // ¡llamé una vez! } //para (i)
El bloque original (líneas 3 a 5) ya no es el cuerpo del for
bucle y se ejecuta solo una vez. Además, el comentario de la línea 5 resulta incorrecto.
El estilo K&R evita este problema manteniendo la declaración de control y la llave de apertura en la misma línea.
Original:
para ( int yo = 0 ; yo < 10 ; yo ++ ) { hacer algo ();} //para (i)
Agregar una nueva segunda línea no afecta la cantidad de veces do_something
que se llama ni la validez del comentario final.
para ( int yo = 0 ; yo < 10 ; yo ++ ) { hacer algo más (); hacer algo ();} //para (i)
Es aceptable usar llaves "egipcias" o llaves estilo C
Un término humorístico [
sic
] para el estilo de sangría de K&R, que se refiere a la pose de "una mano arriba, otra abajo".
Las llaves siguen el estilo de Kernighan y Ritchie ("corchetes egipcios") para bloques no vacíos y construcciones similares a bloques.
emacs --no-init-file
.