En programación de computadoras , 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 que tiene como objetivo dar como resultado un código que transmita estructura.
La sangría implica utilizar el mismo ancho de espacio en blanco antes de cada línea de un grupo de código para que parezcan estar relacionados. Como los espacios en blanco constan de caracteres de espacio y tabulación , un programador puede elegir cuál usar, a menudo ingresándolos mediante la tecla de espacio del teclado o la tecla de tabulación .
La sangría se aplica a un lenguaje de programación basado en texto . Este artículo aborda principalmente los lenguajes de forma libre , con especial atención a los lenguajes entre llaves (que delimitan bloques con llaves , también conocidos como llaves, también conocidos como llaves ) y, en particular, los lenguajes de la familia C.
Como su nombre lo indica, el código de lenguaje de formato libre 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 .
Algunos lenguajes gratuitos utilizan palabras clave en lugar de llaves, por ejemplo BEGINy END.
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 ); no sólo el programador.
Una convención utilizada para un idioma se puede adaptar a otro idioma.
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.
La principal diferencia entre los estilos de sangría de C/C++ que se tratan aquí es la ubicación de las llaves en relación con otros elementos del código.
La ubicación relativa a veces es diferente para el cuerpo de una función frente a una declaración compuesta ( if, while, for, ...)
El estilo Kernighan & Ritchie (K&R), y el estrechamente relacionado "estilo de llave única" en la jerga hacker [1] [2] (abreviado como 1TBS [3] ), se usan comúnmente en C, C++ y otros tipos de llaves. lenguajes de programación . Era el estilo utilizado en el kernel Unix original, el libro de Kernighan y Ritchie The C Programming Language , así como el libro de Kernighan y Plauger The Elements of Programming Style .
Al seguir K&R, cada función tiene su llave de apertura en la siguiente línea en el mismo nivel de sangría que su encabezado, las declaraciones dentro de las llaves tienen sangría y la llave de cierre al final está en el mismo nivel de sangría que el encabezado de la función. en una línea propia.
Sin embargo, los bloques de varias líneas dentro de una función tienen sus llaves de apertura en la misma línea que sus respectivas declaraciones de control; Las llaves de cierre permanecen en una línea propia, a menos que vayan seguidas de una palabra clave elseo while. Estos aparatos ortopédicos no alineados reciben el sobrenombre de "frenos egipcios" (o "brackets egipcios") por su parecido con los brazos en algunas poses extravagantes de los antiguos egipcios. [4] [5] [6] En K&R, los bloques de una sola línea no tienen llaves, lo cual es una posible fuente de errores fáciles de pasar por alto al fusionar código (por ejemplo, consulte el error goto fail ).
int main ( int argc , char * argv []) { ... mientras ( x == y ) { algo (); algo más (); si ( algún_error ) do_correct (); // En K&R un bloque de una sola declaración no tiene llaves. de lo contrario continuar_como_habitual (); } cosa_final (); ... } El libro sobre lenguaje de programación C no especifica explícitamente este estilo, aunque lo sigue de manera consistente en todo momento. 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 versiones antiguas del lenguaje C, los tipos de argumentos debían declararse en la línea siguiente (es decir, justo después del encabezado de la función):
/* Estilo C original anterior a ISO sin prototipos de funciones */ int main ( argc , argv ) int argc ; carbón * argv []; { ... } El "estilo de corsé verdadero" (abreviado como 1TBS u OTBS [3] ) es muy similar a K&R. Las dos diferencias principales son que las funciones tienen sus llaves de apertura en la misma línea separadas por un espacio, y que las llaves no se omiten para una declaración de control con una sola declaración en su alcance. [7]
En este estilo, las construcciones que permiten la inserción de nuevas líneas de código están en líneas separadas y las construcciones que prohíben las inserciones están en una línea. Este principio se amplifica al reforzar cada if, else, while, etc., incluidos los condicionales de una sola línea, de modo que la inserción de una nueva línea de código en cualquier lugar siempre sea segura (es decir, dicha inserción no hará que el flujo de ejecución no esté de acuerdo con la sangría del código fuente, como se ve, por ejemplo, en el infame error goto fail de Apple ).
Las ventajas sugeridas de este estilo son que la llave inicial no necesita una línea adicional por sí sola 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 de un bloque solo necesita una línea completa, lo que puede resolverse parcialmente en bloques if/else y do/ while:
bool is_negative ( x ) { si ( x < 0 ) { devuelve verdadero ; } más { return false ; } } Hay muchas menciones del estilo The One True Brace, pero existe cierta confusión en cuanto a su verdadera forma. Algunas fuentes dicen que es la variación especificada anteriormente, [7] mientras que otras señalan que es simplemente otro término de "jerga hacker" para K&R. [1]
Una variante menor del estilo K&R es el estilo del kernel de Linux, que es conocido por su uso extensivo en el árbol fuente del kernel de Linux . [8] Linus Torvalds recomienda encarecidamente a todos los contribuyentes que lo sigan. El estilo toma prestados muchos elementos de K&R.
El estilo del kernel utiliza tabulaciones (con las tabulaciones establecidas cada 8 caracteres) para la sangría. Al abrir llaves de una función, vaya al inicio de la línea que sigue al encabezado de la función. Cualquier otra llave de apertura va en la misma línea que la declaración correspondiente, separada por un espacio. Las etiquetas de una switchdeclaración están alineadas con el bloque circundante (solo hay un nivel de sangría). La longitud de la línea solía estar limitada a 80 caracteres; se elevó a 100 en 2020, pero aún se prefiere el límite original. [9] El cuerpo de una sola declaración de una declaración compuesta (como if, while y do- while) no necesita estar entre llaves. Sin embargo, si una o más de las subdeclaraciones en una if-elsedeclaració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 ; } Algunos recomiendan llaves obligatorias para declaraciones de control con una sola declaración en su alcance, es decir, llaves cada if, else, while, etc., incluidos los condicionales de una sola línea, de modo que la inserción de una nueva línea de código en cualquier lugar sea siempre segura (es decir, , dicha inserción no hará que el flujo de ejecución no coincida con la sangría del código fuente).
El costo de este estilo es que se necesita una línea completa adicional para el último bloque (excepto para los bloques intermedios en construcciones if/else if/else y bloques do/ while).
Si bien Java a veces se escribe en otros estilos, una parte importante del código Java utiliza una variante menor del estilo K&R en el que la llave de apertura está en la misma línea no solo 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 [10] [11] [12] 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.
El estilo Stroustrup es la adaptación de Bjarne Stroustrup del estilo K&R para C++, tal como se utiliza en sus libros, como Programación: principios y práctica usando C++ y El lenguaje de programación C++ . [13]
A diferencia de las variantes anteriores, Stroustrup no utiliza un "otra persona abrazada". Así, Stroustrup escribiría [13]
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++ . [14]
También denominada forma normal del kernel , es la forma de la mayor parte del código utilizado en los sistemas operativos Berkeley Software Distribution (BSD). 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. [15]
El kernel y el área de usuario de SunOS utilizan un estilo de sangría similar. [15] Al igual que KNF, esto también se basó en documentos de estilo AT&T y a veces se denomina Formulario normal Bill Joy. [16] 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. [15] [16] [17]
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, 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.doswitchreturnreturn
A continuación se muestran algunos 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. [18]
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 beginy 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 facilita la búsqueda de frenillos 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 potentes de Windows 3.0 de Norton & Yao.
Whitesmiths, junto con Allman, han sido los estilos de refuerzo más comunes con igual popularidad según Jargon File . [1]
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. [19]
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 ifse tratan como declaraciones, muy parecidas a las #elifdeclaraciones 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. [20] En cualquier caso, el código contenido tiene una sangría de dos espacios entre llaves.
Popularizado por Richard Stallman , el diseño puede estar influenciado por su experiencia en la escritura de código Lisp . [21] 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. [22] [23] [ 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.
char * s2 estático ( char * s1 , char * s2 ) { while ( x == y ) { algo (); algo más (); } cosa_final (); } [20]
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. [24] 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 de "Coding Horror", que simboliza un código especialmente peligroso, y afirma que impide la legibilidad. [19] La documentación sobre el estilo de codificación del kernel de Linux también desaconseja encarecidamente este estilo, instando a los lectores a grabar una copia de los estándares de codificación GNU como un "gran gesto simbólico". [25]
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 . [26]
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. [27]
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: [28]
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 , [29] 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 , [30] 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) [19] 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 . [31]
// 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 clases distintas 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 elsepalabra clave en un if : then | elsebloque, 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: prognes un procedimiento para evaluar múltiples subexpresiones secuencialmente para efectos , mientras se descarta todo menos el valor de retorno final (enésimo). Si se desean todos los valores de retorno, valuesse 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.[32] 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. [33] Si el código que sigue a las palabras clave where, letu ofomite llaves y punto y coma, entonces la sangría es significativa. [34]
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. [35] 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.
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 )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. [36] 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 según 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 provocar una desalineación visual, cuando se ven 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 consideran 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 .[37] Otros, como los autores de los estándares de codificación de WordPress , afirman lo contrario: que las pestañas duras aumentan la portabilidad. [38] Una encuesta de los 400.000 repositorios principales en GitHub encontró que los espacios son más comunes. [39]
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 Tabuna línea determinada. M-x indent-regioncó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á separada visualmente 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 está para el mismo bloque que el que está debajo del cursor cuando presiona la %tecla. Dado que la nexttecla del cursor de texto (es decir, la ntecla) retenía información de posicionamiento direccional (ya sea que se presionara anteriormente la tecla upo ), la macro de puntos (la tecla) podría usarse para colocar el cursor de texto en la siguiente llave, [40] 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 (yo) 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.
Considere este código inicial:
para ( int i = 0 ; i < 10 ; i ++ ) { hacer_algo (); } //para (i) do_somethingSerá 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) ==> ¡MAL! El bloque original (líneas 3 a 5) ya no es el cuerpo del forbucle y se ejecuta solo una vez. Además, ¡el comentario en 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_somethingque 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.