Estilo de sangría

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 núcleo original de Unix, 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 forma consistente. Del libro:

La posición de los brackets es menos importante, aunque la gente tiene opiniones muy firmes al respecto. Hemos elegido uno de los estilos más populares. Escoge el que mejor te quede y úsalo con regularidad.

En este estilo, una función tiene sus llaves de apertura y cierre en líneas separadas y con la misma sangría que la declaración, mientras que las instrucciones en el cuerpo de la función tienen una sangría adicional. Sin embargo, un bloque de varias instrucciones 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 elseo while.

Código de ejemplo:

int main ( int argc , char * argv []) { while ( x == y ) { hacer_algo (); hacer_algo_algo_otro (); if ( algún_error ) corregir_el_problema (); // bloque de una sola instrucción sin llaves else continuar_como_siempre (); } cosa_final (); }

El estilo de corchetes único verdadero ^{[ 8 ]} (abreviado 1TBS u OTBS ^{[ 9 ]} ) es una variante del estilo K&R donde no se omiten los corchetes para un bloque de una sola instrucción. ^{[ 10 ]}

bool is_negative ( int x ) { if ( x < 0 ) { return true ; } else { return false ; } }

Aunque no es obligatorio en lenguajes como C/C++, el uso de llaves para bloques de una sola instrucción garantiza que la inserción de una nueva instrucción no dé como resultado un flujo de control que no coincida con la indentación, como se ve, por ejemplo, en el infame error goto fail de Apple .

Algunas fuentes discrepan sobre el significado de One True Brace Style: podría tener ligeras diferencias según el estilo más frecuente en un idioma determinado, ^{[ 11 ] [ 12 ]} algunos autores podrían declarar un estilo muy distinto como OTBS según sus preferencias subjetivas, ^{[ 13 ]} mientras que otros lo señalan como "jerga hacker" para K&R. ^{[ 14 ]}

El árbol de código fuente del kernel de Linux tiene un estilo similar al de K&R. ^{[ 15 ]} Linus Torvalds aconseja a los colaboradores que lo sigan. Los atributos incluyen:

• Utiliza caracteres de tabulación para la sangría (no espacios) y asume que hay tabulaciones cada 8 espacios.
• La disposición de las llaves coincide con la de K&R, con las llaves de las definiciones de funciones en líneas separadas y la llave de apertura de las sentencias compuestas en la misma línea que la cláusula de control, separadas por un espacio.
• Las etiquetas dentro de una switchinstrucción están alineadas con el bloque que las contiene (solo hay un nivel de sangría).
• La longitud máxima de línea es de 100 caracteres, aunque se prefiere el límite anterior a 2020 de 80 caracteres. ^{[ 16 ]}
• El cuerpo de una instrucción compuesta (como if, while y do-while) no necesita ir entre llaves. Sin embargo, si una o más subinstrucciones de una if-elseinstrucción requieren llaves, entonces ambas subinstrucciones deben ir entre llaves:

int potencia ( int x , int y ) { int resultado ;if ( y < 0 ) { resultado = 0 ; } else { resultado = 1 ; while ( y -- > 0 ) resultado *= x ; } return resultado ; }

Una cantidad significativa de código Java utiliza una variante del estilo K&R en la que la llave de apertura se encuentra 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 principalmente porque las guías de estilo originales de Sun Microsystems ^{[ 17 ] [ 18 ] [ 19 ]} utilizaban esta variante de K&R y, como resultado, la mayor parte del código fuente estándar de la API de Java está escrito en este estilo. También es un estilo de indentación popular para ActionScript y JavaScript , junto con el estilo Allman .

Bjarne Stroustrup adaptó el estilo K&R para C++ en sus libros, tales como Programming: Principles and Practice using C++ y The C++ Programming Language . ^{[ 20 ]}

A diferencia de las variantes anteriores, Stroustrup no utiliza un "cuddled else". Por lo tanto, Stroustrup escribiría ^{[ 20 ]}

if ( x < 0 ) { puts ( "Negativo" ); negative ( x ); } else { puts ( "No negativo" ); nonnegative ( x ); }

Stroustrup amplía el estilo K&R para las clases, escribiéndolas de la siguiente manera:

clase DoubleVec { public : // construye un DoubleVec DoubleVec ( int s ) : elem ( new double [ s ]), sz ( s ) { } // acceso a elementos: indexación double & operator []( int i ) { return elem [ i ]; } int size () { return sz ; } private : // puntero a los elementos double * elem ; // número de elementos int sz ; };

Stroustrup no aplica sangría a 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 indentación 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 Directrices básicas modernas de C++ . ^{[ 21 ]}

Los sistemas operativos de la distribución de software de Berkeley (BSD) utilizan un estilo que a veces se denomina "forma normal del núcleo" (KNF). Aunque está destinado principalmente al código del núcleo, también se utiliza ampliamente en el código del espacio de usuario . Esencialmente, es una variante exhaustivamente documentada del estilo K&R, tal como se utiliza en el código fuente de Unix versiones 6 y 7 de Bell Labs . ^{[ 22 ]}

El núcleo y el espacio de usuario de SunOS utilizan un estilo de indentación similar. ^{[ 22 ]} Al igual que KNF, este también se basó en documentos de estilo AT&T y a veces se denomina Bill Joy Normal Form. ^{[ 23 ]} La guía de SunOS se publicó en 1996; se analiza brevemente ANSI C. La corrección de la indentación de una lista de archivos fuente se puede verificar con el programa cstyle escrito por Bill Shannon. ^{[ 22 ] [ 23 ] [ 24 ]}

En este estilo, el tabulador rígido (ts en vi ) se mantiene en ocho columnas, mientras que un tabulador flexible (sw en vi) suele definirse como auxiliar y se establece en cuatro. Los tabuladores rígidos se utilizan para indentar bloques de código, mientras que un tabulador flexible (cuatro espacios) de indentación adicional se utiliza para todas las líneas continuas que deben dividirse en varias líneas.

Además, las llamadas a funciones no usan un espacio antes del paréntesis, aunque las instrucciones nativas del lenguaje C, como if, while, do, switchy returnsí lo hacen (en el caso de que returnse use con paréntesis). Las funciones que no declaran variables locales en su bloque de nivel superior también deben dejar una línea en blanco después de su llave de apertura de bloque.

Ejemplos:

mientras ( x == y ) { algo (); algo_más (); } cosa_final ();

if ( data != NULL && res > 0 ) { if ( JS_DefineProperty ( cx , o , "data" , STRING_TO_JSVAL ( JS_NewStringCopyN ( cx , data , res )), NULL , NULL , JSPROP_ENUMERATE ) != 0 ) { QUEUE_EXCEPTION ( "¡Error interno!" ); goto err ; } PQfreemem ( data ); } else { if ( JS_DefineProperty ( cx , o , "data" , OBJECT_TO_JSVAL ( NULL ), NULL , NULL , JSPROP_ENUMERATE ) != 0 ) { QUEUE_EXCEPTION ( "¡Error interno!" ); goto err ; } }

static JSBool pgresult_constructor ( JSContext * cx , JSObject * obj , uintN argc , jsval * argv , jsval * rval ) {EXCEPCIÓN_DE_QUEEA ( "La clase PGresult no es instanciable por el usuario" );return ( JS_FALSE ); }

El estilo Allman recibe su 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 estilo "BSD KNF"; véase más arriba).

Este estilo coloca la llave asociada a una instrucción de control en la siguiente línea, con la misma sangría que la instrucción de control. Las instrucciones dentro de las llaves se indentan al siguiente nivel. ^{[ 14 ]}

mientras ( x == y ) { algo (); algo_más (); }cosa_final ();

Este estilo es similar a la indentación estándar utilizada por los lenguajes Pascal y Transact-SQL , donde las llaves son equivalentes a las palabras clave beginy end.

(* Ejemplo de estilo de indentación de código Allman en Pascal *) procedure dosomething ( x , y : Integer ) ; begin while x = y do begin something () ; something_else () ; end ; end ;

Las consecuencias de este estilo son que el código indentado se distingue claramente de la instrucción contenedora mediante líneas que son casi todas espacios en blanco , y la llave de cierre se alinea en la misma columna que la de apertura. Algunos consideran que esto facilita la búsqueda de llaves coincidentes. El estilo de bloqueo también delimita el bloque de código de la instrucción de control asociada. Comentar o eliminar una instrucción de control o un bloque de código, o refactorizar el código , reduce la probabilidad de introducir errores de sintaxis debido a llaves colgantes o faltantes. Además, es coherente con la colocación de llaves en el bloque de función externo.

Por ejemplo, lo siguiente sigue siendo sintácticamente correcto:

// mientras (x == y) { algo (); algo_más (); }

Tal y como es esto:

// para (int i=0; i < x; i++) // mientras (x == y) si ( x == y ) { algo (); algo_más (); }

Incluso así, con compilación condicional:

int c ; #ifdef HAS_GETCH while (( c = getch ()) != EOF ) #else while (( c = getchar ()) != EOF ) #endif { hacer_algo ( c ); }

El estilo Whitesmiths, también conocido como estilo Wishart, se utilizó originalmente en la documentación del primer compilador C comercial, el compilador Whitesmiths . También fue popular en los inicios de Windows, ya que se empleó en tres influyentes libros de programación para Windows: Programmer's Guide to Windows de Durant , Carlson y Yao , Programming Windows de Petzold y Windows 3.0 Power Programming Techniques de Norton y Yao.

Según Jargon File , en 1991 los estilos de refuerzo Whitesmiths, junto con Allman , eran los más comunes , con una popularidad aproximadamente igual en ese momento. ^{[ 14 ] [ 25 ]}

Este estilo coloca la llave asociada a una instrucción de control en la siguiente línea, con sangría. Las instrucciones dentro de las llaves se indentan al mismo nivel que las llaves.

Al igual que en el estilo Ratliff, la llave de cierre se indenta igual que las instrucciones dentro de las llaves. ^{[ 26 ]}

mientras ( x == y ) { algo (); algo_más (); }cosa_final ();

Las ventajas de este estilo son similares a las del estilo Allman . Los bloques se distinguen claramente de las instrucciones de control. La alineación de las llaves con el bloque subraya que, conceptual y programáticamente, el bloque completo constituye una única instrucción compuesta. La indentación de las llaves enfatiza su subordinación a la instrucción de control. La llave de cierre ya no se alinea con la instrucción, sino con la llave de apertura.

Un ejemplo:

if ( data != NULL && res > 0 ) { if ( ! JS_DefineProperty ( cx , o , "data" , STRING_TO_JSVAL ( JS_NewStringCopyN ( cx , data , res )), NULL , NULL , JSPROP_ENUMERATE )) { QUEUE_EXCEPTION ( "¡Error interno!" ); goto err ; } PQfreemem ( data ); } else if ( ! JS_DefineProperty ( cx , o , "data" , OBJECT_TO_JSVAL ( NULL ), NULL , NULL , JSPROP_ENUMERATE )) { QUEUE_EXCEPTION ( "¡Error interno!" ); goto err ; }

else ifse tratan como una instrucción, muy parecida a la #elifinstrucción del preprocesador.

Al igual que los estilos Allman y Whitesmiths , el estilo GNU coloca las llaves en una línea aparte, con una sangría de dos espacios, excepto al abrir la definición de una función, donde no se les aplica sangría. ^{[ 27 ]} En ambos casos, el código contenido se indenta con dos espacios a partir de las llaves.

Popularizado por Richard Stallman , el diseño puede estar influenciado por su experiencia escribiendo código Lisp . ^{[ 28 ]} En Lisp, el equivalente a un bloque (un progn) es una entidad de datos de primera clase, y darle su propio nivel de indentación ayuda a enfatizarlo, 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. ^{[ 29 ] [ 30 ]}

Aunque no se trata de una sangría propiamente dicha, 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. ^{[ 27 ]}

static char * concat ( char * s1 , char * s2 ) { while ( x == y ) { something (); something_else (); } final_thing (); }

Este estilo combina las ventajas de Allman y Whitesmiths , eliminando así la posible desventaja de Whitesmiths de que las llaves no sobresalgan del bloque. Una desventaja es que la llave final ya no se alinea con la instrucción a la que pertenece conceptualmente. Otra posible desventaja es que podría desperdiciar espacio al usar dos niveles visuales de sangría para un solo nivel conceptual, pero en realidad esto es improbable porque, en sistemas con sangría de un solo nivel, cada nivel suele tener al menos 4 espacios, igual que 2 * 2 espacios en el estilo GNU.

Los estándares de codificación de GNU recomiendan este estilo, y casi todos los responsables del mantenimiento del software de los proyectos GNU lo utilizan.

El editor de texto GNU Emacs y el comando de indentación del sistema GNU reformatearán el código según este estilo por defecto. ^{[ 31 ]} Quienes no utilicen GNU Emacs, o editores similares extensibles/personalizables, podrían encontrar que la configuración de indentación automática de su editor no es útil para este estilo. Sin embargo, muchos editores que por defecto usan el estilo KNF se adaptan bien al estilo GNU cuando el ancho de tabulación se establece en dos espacios; de igual manera, GNU Emacs se adapta bien al estilo KNF simplemente estableciendo el ancho de tabulación en ocho espacios. En ambos casos, el reformateo automático destruye el espaciado original, pero la indentación automática de línea 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 "Horror de la codificación", que simboliza código especialmente peligroso, y afirma que dificulta la legibilidad. ^{[ 26 ]} La documentación sobre el estilo de codificación del kernel de Linux también desaconseja este estilo, instando a los lectores a quemar una copia de los estándares de codificación de GNU como un "gran gesto simbólico". ^{[ 32 ]}

La edición de 1997 de Computing Concepts with C++ Essentials de Cay S. Horstmann adapta el método de Allman colocando la primera instrucción de un bloque en la misma línea que la llave de apertura. Este estilo también se utiliza en los ejemplos del Pascal User Manual and Report de Jensen y Wirth . ^{[ 33 ]}

while ( x == y ) { something (); something_else (); //... if ( x < 0 ) { printf ( "Negativo" ); negative ( x ); } else { printf ( "No negativo" ); nonnegative ( x ); } } final_thing ();

Este estilo combina las ventajas del estilo Allman , al mantener la alineación vertical de las llaves para facilitar la lectura y la identificación de los bloques, con el ahorro de una línea del estilo K&R. Sin embargo, la edición de 2003 utiliza ahora el estilo Allman en todo el texto. ^{[ 34 ]}

Este es el estilo más utilizado en el lenguaje Pico por sus diseñadores. Pico carece de sentencias de retorno y utiliza puntos y comas como separadores de sentencias en lugar de terminadores. Produce esta sintaxis: ^{[ 35 ]}

cosas(n): { x: 3 * n; y: hacer_cosas(x); y + x } 

Las ventajas y desventajas son similares a las de ahorrar espacio en pantalla con el estilo K&R. Una ventaja adicional es que las llaves de apertura y cierre son consistentes en su aplicación (ambas comparten espacio con una línea de código), a diferencia del estilo K&R, donde una llave comparte espacio con una línea de código y la otra ocupa una línea propia.

En el libro Programmers at Work , ^{[ 36 ]} C. Wayne Ratliff, el programador original de los populares lenguajes de programación de cuarta generación dBase -II y -III , analizó un estilo similar a 1TBS, pero donde la llave de cierre se alinea con la sangría del bloque anidado. Indicó que este estilo fue documentado originalmente en material de Digital Research Inc. Este estilo a veces se denomina estilo banner , ^{[ 37 ]} posiblemente por su parecido con una pancarta colgada de un poste. En este estilo, que es a Whitesmiths lo que K&R es a Allman, el control de cierre tiene la misma sangría que el último elemento de la lista (y, por lo tanto, pierde prominencia correctamente). ^{[ 26 ]} Este estilo puede facilitar la lectura visual para algunos, ya que 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 Software Tools . ^{[ 38 ]}

// En C for ( i = 0 ; i < 10 ; i ++ ) { if ( i % 2 == 0 ) { hacer_algo ( i ); } else { hacer_algo_algo_otra ( i ); } }

Si bien el estilo GNU a veces se caracteriza como código C indentado por un programador de Lisp, incluso se podría llegar a insertar llaves de cierre juntas en la última línea de un bloque. Este estilo hace que la indentación sea la única forma de distinguir bloques de código, pero tiene la ventaja de no contener líneas irrelevantes. Podría denominarse fácilmente estilo Lisp, ya que es muy común en el código Lisp. En Lisp, la agrupación de llaves idénticas al final de los árboles de expresiones indica que el usuario no tiene que seguir visualmente los niveles de anidamiento, sino únicamente comprender la estructura del árbol.

La variante tradicional de Lisp de este estilo prefiere niveles de indentación extremadamente estrechos (normalmente dos espacios) porque el código Lisp suele anidarse muy profundamente, ya que Lisp solo presenta expresiones , sin una clase distinta de sentencias ; los argumentos de las funciones se indentan en su mayoría al mismo nivel para ilustrar su estatus compartido dentro de la expresión que los contiene. Esto también se debe a que, aparte de las llaves, Lisp es convencionalmente un lenguaje muy conciso, que omite incluso formas comunes de código repetitivo simple por considerarlo poco informativo, como la elsepalabra clave en un bloque, y en su lugar la representa uniformemente como .if : then | else(if expr1 expr2 expr3)

// C for ( i = 0 ; i < 10 ; i ++ ) { if ( i % 2 == 0 ) { hacer_algo ( i );} else { hacer_algo_más ( i ); hacer_tercera_cosa ( i );}}

;; Lisp ( hacer veces ( i 10 ) ( si ( = ( rem i 2 ) 0 ) ( hacer-algo i ) ( progn ( hacer-algo-más i ) ( hacer-tercera-cosa i ))))

^{Nota: prognes un procedimiento para evaluar secuencialmente múltiples subexpresiones en busca de efectos , descartando todos los valores de retorno excepto el último (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 las llaves y los puntos y comas están permitidos en el lenguaje. ^{[ 39 ]} Los dos segmentos siguientes son igualmente aceptables para el compilador:

sin llaves = hacer texto <- obtenerContenidos dejar primeraPalabra = cabeza $ palabras texto palabraGrande = mapear aPrimeraPalabra ponerStrLn palabraGrandebraceful = do { text <- getContents ; let { firstWord = head $ words text ; bigWord = map toUpper firstWord } ; putStrLn bigWord }

En Haskell, el estilo puede reemplazar las llaves. Por lo general, las llaves y los puntos y comas se omiten para las secciones procedimentalesdo 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 puntos y comas. ^{[ 40 ]} Si el código que sigue a las palabras clave where, let, o ofomite llaves y puntos y comas, entonces la indentación es importante. ^{[ 41 ]}

Como ejemplo de lo conciso que suele ser APL, aquí está la implementación de la función paso a paso para el Juego de la Vida de Conway :

vida ← { ⊃ 1 ⍵ ∨ . ∧ 3 4 =+ / + ⌿ ¯1 0 1 ∘. ⊖ ¯1 0 1 ⌽ ¨ ⊂ ⍵ }

El estilo C de APL se asemeja al estilo conciso del código APL y se usa comúnmente en sus implementaciones. ^{[ 42 ]} Este estilo fue creado por Arthur Whitney y se usa ampliamente en la implementación de K , el proyecto del propio Arthur. El lenguaje de programación J también se implementa con este estilo. Cabe destacar que no todas las implementaciones de APL usan este estilo de C, a saber: GNU APL y Dyalog APL.

Además de la indentación estilo APL C, normalmente los nombres se acortan a uno o dos caracteres: para reducir la cantidad de indentación y las expresiones que abarcan varias líneas. ^{[ 43 ]}

Normalmente, un programador utiliza un editor de texto que proporciona tabulaciones a intervalos fijos (un número determinado de espacios) para mantener el espaciado entre caracteres según un estilo específico. Este intervalo se denomina ancho de tabulación . A veces, el programador almacena el código con caracteres de tabulación ( uno por cada pulsación de la tecla Tab) o bien almacena una secuencia de espacios cuyo número es igual al ancho de tabulación.

Almacenar caracteres de tabulación en el código puede provocar una desalineación visual al visualizarlo en diferentes contextos, lo que contrarresta el valor del estilo de indentación.

Los programadores no llegan a un consenso sobre cómo almacenar los caracteres de tabulación. Quienes defienden el almacenamiento de caracteres de tabulación argumentan que facilita la escritura y reduce el tamaño de los archivos de texto, ya que un solo carácter de tabulación cumple la función de varios espacios. Quienes se oponen, como Jamie Zawinski , afirman que usar espacios en su lugar aumenta la portabilidad entre plataformas . ^{[ 45 ]} Otros, como los autores de los estándares de codificación de WordPress , sostienen lo contrario: que las tabulaciones fijas aumentan la portabilidad. ^{[ 46 ]} Un estudio de los 400 000 repositorios más importantes de GitHub reveló que los espacios son más comunes. ^{[ 47 ]}

Muchos editores de texto, como Notepad++ , TextEdit , Emacs , vi y nano , se pueden configurar para almacenar los caracteres de tabulación al introducirlos con la tecla Tab o para convertirlos en espacios (según el ancho de tabulación configurado), de modo que no se añadan caracteres de tabulación al archivo al pulsar dicha tecla. Algunos editores pueden convertir caracteres de tabulación en espacios y viceversa.

Algunos paginadores de archivos de texto , como less , permiten configurar el ancho de las tabulaciones. Algunas herramientas, como expand / unexpand, permiten realizar conversiones sobre la marcha mediante filtros.

• Tabulaciones contra espacios: Una eterna guerra santa, por Jamie Zawinski
• Por qué prefiero no usar tabulaciones en el código fuente, por Adam Spiers
• Por qué me encanta tener pestañas en el código fuente (archivado)
• Tabulaciones elásticas: la solución al problema de las tabulaciones frente a los espacios.