Style d'indentation - Indentation style
En programmation informatique , un style d'indentation est une convention régissant l' indentation de blocs de code pour transmettre la structure du programme. Cet article traite en grande partie des langages de forme libre , tels que C et ses descendants, mais peut être (et est souvent) appliqué à la plupart des autres langages de programmation (en particulier ceux de la famille des accolades ), où les espaces sont par ailleurs insignifiants. Le style d'indentation n'est qu'un aspect du style de programmation .
L'indentation n'est pas une exigence de la plupart des langages de programmation, où elle est utilisée comme notation secondaire . Au contraire, l'indentation aide à mieux transmettre la structure d'un programme aux lecteurs humains. En particulier, il est utilisé pour clarifier le lien entre les constructions de flux de contrôle telles que les conditions ou les boucles, et le code contenu à l'intérieur et à l'extérieur de celles-ci. Cependant, certains langages (tels que Python et occam ) utilisent l'indentation pour déterminer la structure au lieu d'utiliser des accolades ou des mots-clés ; c'est ce qu'on appelle la règle du hors-jeu . Dans de telles langues, l'indentation est significative pour le compilateur ou l'interprète ; c'est plus qu'une simple question de clarté ou de style.
Cet article utilise le terme crochets pour désigner les parenthèses et le terme accolades pour désigner les accolades.
Placement des accolades dans les instructions composées
La principale différence entre les styles d'indentation réside dans le placement des accolades de l'instruction composée ( {...}) qui suit souvent une instruction de contrôle ( if, while, for...). Le tableau ci-dessous montre cet emplacement pour le style des déclarations discutées dans cet article ; le style de déclaration de fonction est un autre cas. Le style de placement des accolades dans les instructions peut différer du style de placement des accolades d'une définition de fonction. Par souci de cohérence, la profondeur d'indentation a été maintenue constante à 4 espaces, quelle que soit la profondeur d'indentation préférée de chaque style.
| Placement de l'attelle | modes |
|---|---|
while (x == y)
{
something();
somethingelse();
}
|
Tous les hommes |
while (x == y) {
something();
somethingelse();
}
|
K&R |
while (x == y)
{
something ();
somethingelse ();
}
|
GNOU |
while (x == y)
{
something();
somethingelse();
}
|
Forgerons |
while (x == y)
{ something();
somethingelse();
}
|
Horstmann |
while (x == y)
{ something()
; somethingelse()
;
}
|
Haskell |
while (x == y)
{ something();
somethingelse(); }
|
Pico |
while (x == y) {
something();
somethingelse();
}
|
Ratliff |
while (x == y)
{ something();
somethingelse(); }
|
Zézayer |
Tabulations, espaces et taille des retraits
La largeur affichée pour les onglets peut être définie sur des valeurs arbitraires dans la plupart des éditeurs de programmation, y compris Notepad++ (MS-Windows), TextEdit (MacOS/X), Emacs (unix), vi (unix) et nano (unix). De plus, ces éditeurs peuvent être configurés pour générer un mélange de tabulations et d'espaces ou pour convertir entre tabulations et espaces, pour correspondre à des schémas d'indentation spécifiques. Sous unix, la largeur de tabulation peut également être définie dans les pagers , comme less , et convertie à la volée par des filtres, tels que expand / unexpand .
Les éditeurs Unix placent par défaut les onglets à des intervalles de huit colonnes, tandis que les environnements Macintosh et MS-Windows utilisent par défaut quatre colonnes. Cette différence provoque un désalignement du code source, lorsqu'une indentation qui mélange des tabulations et des espaces est affichée sous une configuration qui affiche les tabulations différemment de la configuration de l'auteur.
Il y a un débat en cours parmi les programmeurs sur le choix entre les onglets durs et les espaces. De nombreux premiers programmeurs utilisaient des caractères de tabulation pour mettre en retrait, pour faciliter la saisie et pour économiser sur la taille du fichier source. Certains programmeurs, tels que Jamie Zawinski , déclarent que l'utilisation d'espaces au lieu de tabulations augmente la portabilité multiplateforme . D'autres, comme les auteurs des normes de codage WordPress , affirment le contraire : les onglets durs augmentent la portabilité. Une enquête sur les 400 000 meilleurs référentiels sur GitHub a révélé que les espaces sont plus courants.
La taille de l'indentation est généralement indépendante du style. Une expérience réalisée sur le code PASCAL en 1983 a révélé que la taille de l'indentation affectait considérablement la compréhension. Les tailles d'indentation entre 2 et 4 caractères se sont avérées optimales. Pour Ruby , de nombreux langages de script shell et certaines formes de formatage HTML , deux espaces par niveau d'indentation sont généralement utilisés.
Outils
Il existe de nombreux outils pour convertir entre les styles d'indentation, tels que indent, un programme inclus avec de nombreux systèmes d' exploitation de type Unix .
Dans Emacs , diverses commandes sont disponibles pour résoudre automatiquement les problèmes d'indentation, y compris le fait de frapper Tabsur une ligne donnée (dans la configuration par défaut). M-x indent-regionpeut être utilisé pour indenter correctement de grandes sections de code. Selon le mode, Emacs peut également remplacer les espaces d'indentation de début par le nombre approprié de tabulations suivis d'espaces, ce qui se traduit par le nombre minimal de caractères pour l'indentation de chaque ligne source.
Les tabstops élastiques sont un style de tabulation qui nécessite la prise en charge de l'éditeur de texte, où des blocs de texte entiers sont automatiquement alignés lorsque la longueur d'une ligne dans le bloc change.
modes
Style K&R
Le style K&R (Kernighan & Ritchie Style), également appelé "le seul vrai style d'accolade" dans le jargon des hackers (en abrégé 1TBS), est couramment utilisé en C, C++ et d'autres langages de programmation d'accolades . C'était le style utilisé dans le noyau Unix original, le livre de Kernighan et Ritchie The C Programming Language , ainsi que le livre de Kernighan et Plauger The Elements of Programming Style .
En suivant K&R, chaque fonction a son accolade ouvrante à la ligne suivante sur le même niveau d'indentation que son en-tête, les instructions à l'intérieur des accolades sont indentées et l'accolade fermante à la fin est au même niveau d'indentation que l'en-tête de la fonction à une ligne qui lui est propre.
Les blocs à l'intérieur d'une fonction, cependant, ont leurs accolades ouvrantes sur la même ligne que leurs instructions de contrôle respectives ; les accolades fermantes restent dans une ligne distincte, à moins qu'elles ne soient suivies d'un mot-clé elseou while. De telles accolades non alignées sont surnommées « accolades égyptiennes » (ou « accolades égyptiennes ») pour leur ressemblance avec des armes dans certaines poses fantaisistes des anciens Égyptiens.
int main(int argc, char *argv[])
{
...
while (x == y) {
something();
somethingelse();
if (some_error)
do_correct();
else
continue_as_usual();
}
finalthing();
...
}
Le langage de programmation C ne spécifie pas explicitement ce style, bien qu'il soit suivi de manière cohérente tout au long du livre. Du livre:
La position des accolades est moins importante, bien que les gens aient des croyances passionnées. Nous avons choisi l'un des nombreux styles populaires. Choisissez un style qui vous convient, puis utilisez-le de manière cohérente.
Dans les anciennes versions du langage C, les types d'arguments devaient être déclarés sur la ligne suivante (c'est-à-dire juste après l'en-tête de la fonction) :
/* Original pre-ISO C style without function prototypes */
int main(argc, argv)
int argc;
char *argv[];
{
...
}
Variante : 1 To (OTBS)
Les partisans de ce style l'appellent parfois "le seul vrai style de corset" (en abrégé 1TBS ou OTBS). Les deux principales différences par rapport au style K&R sont que les fonctions ont leurs accolades ouvrantes sur la même ligne séparées par un espace, et que les accolades ne sont pas omises pour une instruction de contrôle avec une seule instruction dans sa portée.
Dans ce style, les constructions qui permettent l'insertion de nouvelles lignes de code sont sur des lignes séparées et les constructions qui interdisent les insertions sont sur une seule ligne. Ce principe est amplifié en veillant à ce que chaque if, else, while, etc., y compris les conditions d'une seule ligne, de sorte que l'insertion d'une nouvelle ligne de code n'importe où soit toujours sûre (c'est-à-dire qu'une telle insertion ne rendra pas le flux d'exécution en désaccord avec l'indentation du code source).
Les avantages suggérés de ce style sont que l'attelle de départ n'a besoin d'aucune ligne supplémentaire seule ; et l'accolade de fin s'aligne sur l'énoncé auquel elle appartient conceptuellement. L'un des coûts de ce style est que l'accolade de fin d'un bloc a besoin d'une seule ligne complète, qui peut être partiellement résolue dans les blocs if/else et do/while :
void checknegative(x) {
if (x < 0) {
puts("Negative");
} else {
nonnegative(x);
}
}
Il existe de nombreuses mentions de The One True Brace Style, mais il existe une certaine confusion quant à sa véritable forme. Certaines sources disent qu'il s'agit de la variation spécifiée ci-dessus, tandis que d'autres la notent comme un autre terme de "jargon hacker" pour K&R.
Variante : noyau Linux
Une variante mineure du style K&R est le style du noyau Linux, qui est connu pour son utilisation intensive dans l'arborescence des sources du noyau Linux . Linus Torvalds conseille fortement à tous les contributeurs de le suivre. Le style emprunte de nombreux éléments à K&R :
Le style du noyau utilise des taquets de tabulation (les taquets de tabulation étant définis tous les 8 caractères) pour l'indentation. Les accolades ouvrantes d'une fonction vont au début de la ligne suivant l'en-tête de la fonction. Toutes les autres accolades ouvrantes vont sur la même ligne que l'instruction correspondante, séparées par un espace. Les étiquettes d'une switchinstruction sont alignées avec le bloc englobant (il n'y a qu'un seul niveau d'indentations). Le corps d'une seule instruction d'une instruction composée (comme if, while et do-while) n'a pas besoin d'être entouré d'accolades. Si, toutefois, une ou plusieurs des sous- if-elseinstructions d' une instruction nécessitent des accolades, les deux sous-instructions doivent être placées entre des accolades. La longueur de la ligne a longtemps été limitée à 80 caractères, mais est maintenant passée à 100, mais la limite d'origine est toujours préférée.
Le style du noyau Linux spécifie que "si une seule branche d'une instruction conditionnelle est une seule instruction ... utilisez des accolades dans les deux branches":
int power(int x, int y)
{
int result;
if (y < 0) {
result = 0;
} else {
result = 1;
while (y-- > 0)
result *= x;
}
return result;
}
Variante : accolades obligatoires
Certains prônent des accolades obligatoires pour les instructions de contrôle avec seulement une seule instruction dans son champ d' application, à savoir contreventement tous les cas, sinon, tout, etc., y compris conditionals une seule ligne, de sorte que l' insertion d'une nouvelle ligne de n'importe où le code est toujours en sécurité (c. -à- , une telle insertion ne mettra pas le flux d'exécution en désaccord avec l'indentation du code source).
Le coût de ce style est qu'une ligne complète supplémentaire est nécessaire pour le dernier bloc (sauf pour les blocs intermédiaires dans les constructions if/else if/else et do/while).
Variante : Java
Alors que Java est parfois écrit dans d'autres styles, un corps important de code Java utilise une variante mineure du style K&R dans laquelle l'accolade ouvrante est sur la même ligne non seulement pour les blocs à l'intérieur d'une fonction, mais aussi pour les déclarations de classe ou de méthode. Ce style est largement répandu parce que les guides de style originaux de Sun Microsystems utilisaient cette variante K&R, et par conséquent, la plupart du code source standard de l' API Java est écrit dans ce style. Il s'agit également d'un style d'indentation populaire pour ActionScript et JavaScript , avec le style Allman .
Variante : Stroustrup
Le style Stroustrup est l'adaptation par Bjarne Stroustrup du style K&R pour C++, tel qu'il est utilisé dans ses livres, tels que Programming: Principles and Practice using C++ et The C++ Programming Language .
Contrairement aux variantes ci-dessus, Stroustrup n'utilise pas de « autre câliné ». Ainsi, Stroustrup écrirait
if (x < 0) {
puts("Negative");
negative(x);
}
else {
puts("Non-negative");
nonnegative(x);
}
Stroustrup étend le style K&R pour les classes, en les écrivant comme suit :
class Vector {
public:
Vector(int s) :elem(new double[s]), sz(s) { } // construct a Vector
double& operator[](int i) { return elem[i]; } // element access: subscripting
int size() { return sz; }
private:
double * elem; // pointer to the elements
int sz; // number of elements
};
Stroustrup n'indente pas les étiquettes public:et private:. De plus, dans ce style, alors que l'accolade ouvrante d'une fonction commence sur une nouvelle ligne, l'accolade ouvrante d'une classe est sur la même ligne que le nom de la classe.
Stroustrup permet d'écrire des fonctions courtes sur une seule ligne. Le style Stroustrup est un style d'indentation nommé disponible dans l'éditeur Emacs . Stroustrup encourage une disposition de style dérivée de K&R avec C++ comme indiqué dans ses directives de base C++ modernes .
Variante : BSD KNF
Également appelée forme normale du noyau , il s'agit de la forme de la plupart du code utilisé dans les systèmes d'exploitation Berkeley Software Distribution (BSD). Bien que principalement destiné au code du noyau, il est également largement utilisé dans le code utilisateur . Il s'agit essentiellement d'une variante bien documentée du style K&R tel qu'il est utilisé dans le code source Unix des versions 6 et 7 de Bell Labs .
Le noyau et l'espace utilisateur SunOS utilisent un style d'indentation similaire. Comme KNF, cela était également basé sur des documents de style AT&T et est parfois appelé Bill Joy Normal Form. La directive SunOS a été publiée en 1996 ; ANSI C est discuté brièvement. L'exactitude de l'indentation d'une liste de fichiers source peut être vérifiée par le programme cstyle écrit par Bill Shannon.
Dans ce style, la tabulation dure (ts dans vi ) est maintenue à huit colonnes, tandis qu'une tabulatrice souple est souvent définie comme une aide également (sw dans vi) et fixée à quatre. Les tabulations matérielles sont utilisées pour indenter les blocs de code, tandis qu'une tabulation logicielle (quatre espaces) d'indentation supplémentaire est utilisée pour toutes les lignes continues qui doivent être réparties sur plusieurs lignes.
De plus, les appels de fonction n'utilisent pas d'espace avant la parenthèse, bien que les instructions natives du langage C telles que if, while, do, switchet returndo (dans le cas où returnest utilisé avec des parenthèses). Les fonctions qui ne déclarent aucune variable locale dans leur bloc de niveau supérieur doivent également laisser une ligne vide après leur accolade de bloc d'ouverture.
Voici quelques exemples :
while (x == y) {
something();
somethingelse();
}
finalthing();
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("Internal error!");
goto err;
}
PQfreemem(data);
} else {
if (JS_DefineProperty(cx, o, "data", OBJECT_TO_JSVAL(NULL),
NULL, NULL, JSPROP_ENUMERATE) != 0) {
QUEUE_EXCEPTION("Internal error!");
goto err;
}
}
static JSBool
pgresult_constructor(JSContext *cx, JSObject *obj, uintN argc,
jsval *argv, jsval *rval)
{
QUEUE_EXCEPTION("PGresult class not user-instantiable");
return (JS_FALSE);
}
Style Allman
Le style Allman porte le nom d' Eric Allman . Il est aussi parfois appelé style BSD car Allman a écrit de nombreux utilitaires pour BSD Unix (bien que cela ne doive pas être confondu avec les différents "styles BSD KNF" ; voir ci-dessus).
Ce style place l'accolade associée à une instruction de contrôle sur la ligne suivante, en retrait au même niveau que l'instruction de contrôle. Les déclarations entre accolades sont mises en retrait au niveau suivant.
while (x == y)
{
something();
somethingelse();
}
finalthing();
Ce style est similaire à l'indentation standard utilisée par les langages Pascal et Transact-SQL , où les accolades sont équivalentes aux mots begin- clés et end.
(* Example Allman code indentation style in Pascal *)
procedure dosomething(x, y: Integer);
begin
while x = y do
begin
something();
somethingelse();
end;
end;
Les conséquences de ce style sont que le code indenté est clairement séparé de l'instruction contenant par des lignes qui sont presque toutes des espaces et que l'accolade fermante s'aligne dans la même colonne que l'accolade ouvrante. Certaines personnes pensent que cela facilite la recherche d'appareils orthodontiques assortis. Le style de blocage délimite également le bloc de code de l'instruction de contrôle associée. La mise en commentaire ou la suppression d'une instruction de contrôle ou d'un bloc de code, ou la refactorisation de code , sont toutes moins susceptibles d'introduire des erreurs de syntaxe via des accolades pendantes ou manquantes. En outre, il est cohérent avec le placement des accolades pour le bloc de fonction externe.
Par exemple, ce qui suit est toujours correct syntaxiquement :
// while (x == y)
{
something();
somethingelse();
}
Comme c'est ça :
// for (int i=0; i < x; i++)
// while (x == y)
if (x == y)
{
something();
somethingelse();
}
Même comme ça, avec la compilation conditionnelle :
int c;
#ifdef HAS_GETCH
while ((c = getch()) != EOF)
#else
while ((c = getchar()) != EOF)
#endif
{
do_something(c);
}
Variante : Allman-8
Une variante populaire pour une utilisation dans l'éducation, Allman-8 utilise les onglets d'indentation à 8 espaces et la limite de 80 colonnes de la variante Linux Kernel de K&R. Le style contribue prétendument à améliorer la lisibilité sur les projecteurs. De plus, la taille de l'indentation et la restriction des colonnes aident à créer un repère visuel pour identifier l'imbrication excessive de blocs de code. Ces avantages se combinent pour aider à fournir aux nouveaux développeurs et apprenants des conseils implicites pour gérer la complexité du code.
Style des forgerons
Le style Whitesmiths, également parfois appelé style Wishart, était à l'origine utilisé dans la documentation du premier compilateur C commercial, le compilateur Whitesmiths . Il était également populaire au début de Windows, car il était utilisé dans trois livres de programmation Windows influents, Programmer's Guide to Windows de Durant , Carlson & Yao , Programming Windows de Petzold et Windows 3.0 Power Programming Techniques de Norton & Yao.
Les forgerons, avec Allman , ont été les styles de contreventement les plus courants avec une popularité égale selon le Jargon File .
Ce style place l'accolade associée à une instruction de contrôle sur la ligne suivante, en retrait. Les instructions entre accolades sont mises en retrait au même niveau que les accolades.
while (x == y)
{
something();
somethingelse();
}
finalthing();
Les avantages de ce style sont similaires à ceux du style Allman . Les blocs sont clairement séparés des instructions de contrôle. L'alignement des accolades avec le bloc souligne que le bloc complet est conceptuellement et par programmation, une instruction composée. L'indentation des accolades souligne qu'elles sont subordonnées à l'instruction de contrôle. L'accolade de fin ne s'aligne plus avec l'instruction, mais avec l'accolade d'ouverture.
Un exemple:
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("Internal error!");
goto err;
}
PQfreemem(data);
}
else if (!JS_DefineProperty(cx, o, "data", OBJECT_TO_JSVAL(NULL), NULL, NULL, JSPROP_ENUMERATE))
{
QUEUE_EXCEPTION("Internal error!");
goto err;
}
else ifsont traités comme des instructions, un peu comme l' #elifinstruction du préprocesseur.
style GNU
Comme les styles Allman et Whitesmiths , le style GNU place des accolades sur une ligne par elles-mêmes, indentées par deux espaces, sauf lors de l'ouverture d'une définition de fonction, où elles ne sont pas indentées. Dans les deux cas, le code contenu est indenté de deux espaces à partir des accolades.
Popularisée par Richard Stallman , la mise en page peut être influencée par son expérience dans l'écriture de code Lisp . En Lisp, l'équivalent d'un bloc (un progn) est une entité de données de première classe, et lui donner son propre niveau d'indentation permet de souligner que, alors qu'en C, un bloc n'est que de la syntaxe. Ce style peut également être trouvé dans certains manuels de langage de programmation ALGOL et XPL des années 1960 et 1970. Bien qu'il ne soit pas directement lié à l'indentation, le style de codage GNU inclut également un espace avant la liste entre crochets des arguments d'une fonction.
static char *
concat (char *s1, char *s2)
{
while (x == y)
{
something ();
somethingelse ();
}
finalthing ();
}
Ce style combine les avantages d' Allman et de Whitesmiths , éliminant ainsi l'inconvénient possible des Whitesmiths que les appareils orthodontiques ne se démarquent pas du bloc. Un inconvénient est que l'accolade de fin ne correspond plus à l'énoncé auquel elle appartient conceptuellement. Un autre inconvénient possible est qu'il peut gaspiller de l'espace en utilisant deux niveaux visuels d'indentations pour un niveau conceptuel, mais en réalité, cela est peu probable car, dans les systèmes avec indentation à un seul niveau, chaque niveau est généralement d'au moins 4 espaces, identique à 2 * 2 espaces dans le style GNU.
Les normes de codage GNU recommandent ce style, et presque tous les mainteneurs de logiciels de projet GNU l' utilisent.
L' éditeur de texte GNU Emacs et la commande d' indentation des systèmes GNU reformateront le code selon ce style par défaut. Ceux qui n'utilisent pas GNU Emacs, ou des éditeurs similaires extensibles/personnalisables, peuvent trouver que les paramètres d'indentation automatique de leur éditeur ne sont pas utiles pour ce style. Cependant, de nombreux éditeurs utilisant par défaut le style KNF s'adaptent bien au style GNU lorsque la largeur de tabulation est définie sur deux espaces ; de même, GNU Emacs s'adapte bien au style KNF en définissant simplement la largeur de tabulation à huit espaces. Dans les deux cas, le reformatage automatique détruit l'espacement d'origine, mais l'indentation automatique des lignes fonctionnera correctement.
Steve McConnell , dans son livre Code Complete , déconseille d'utiliser ce style : il marque un échantillon de code qui l'utilise avec une icône « Coding Horror », symbolisant un code particulièrement dangereux, et déclare qu'il entrave la lisibilité. La documentation sur le style de codage du noyau Linux déconseille également fortement ce style, exhortant les lecteurs à graver une copie des normes de codage GNU comme un « grand geste symbolique ».
Style Horstmann
L'édition 1997 de Computing Concepts with C++ Essentials de Cay S. Horstmann adapte Allman en plaçant la première instruction d'un bloc sur la même ligne que l'accolade ouvrante. Ce style est également utilisé dans les exemples de Jensen et Wirth's Pascal User Manual and Report .
while (x == y)
{ something();
somethingelse();
//...
if (x < 0)
{ printf("Negative");
negative(x);
}
else
{ printf("Non-negative");
nonnegative(x);
}
}
finalthing();
Ce style combine les avantages d' Allman en gardant l'alignement vertical des accolades pour la lisibilité, et en identifiant facilement les blocs, avec la sauvegarde d'une ligne du style K&R. Cependant, l'édition 2003 utilise maintenant le style Allman partout.
Style pico
C'est le style le plus couramment utilisé dans la langue Pico par ses concepteurs. Pico n'a pas d'instructions de retour et utilise des points-virgules comme séparateurs d'instructions au lieu de terminateurs. Cela donne cette syntaxe :
stuff(n):
{ x: 3 * n;
y: doStuff(x);
y + x }
Les avantages et les inconvénients sont similaires à ceux de l'économie d'espace d'écran avec le style K&R. Un avantage supplémentaire est que les accolades de départ et de fermeture sont cohérentes dans l'application (les deux partagent l'espace avec une ligne de code), par rapport au style K&R, où une accolade partage l'espace avec une ligne de code et une accolade a une seule ligne.
Style Ratliff
Dans le livre Programmers at Work , C. Wayne Ratliff a discuté de l'utilisation du style ci-dessous. Le style commence un peu comme 1TBS mais ensuite l'accolade de fermeture s'aligne avec l'indentation du bloc imbriqué. Ratliff était le programmeur original derrière les langages de programmation populaires dBase -II et -III de quatrième génération . Il a indiqué qu'il était à l'origine documenté dans du matériel de Digital Research Inc. Ce style a parfois été appelé style de bannière , peut-être pour la ressemblance avec une bannière suspendue à un poteau. Dans ce style, qui est pour Whitesmiths ce que K&R est pour Allman, le contrôle de fermeture est en retrait comme le dernier élément de la liste (et perd ainsi correctement sa saillance). Le style peut faciliter le balayage visuel pour certains, car les en- têtes de n'importe quel bloc sont la seule chose étendue à ce niveau (la théorie étant que le contrôle de fermeture du bloc précédent interfère avec le flux visuel de l'en-tête de bloc suivant dans le K&R et styles Allman). Kernighan et Plauger utilisent ce style dans le code Ratfor dans Software Tools .
// In C
for (i = 0; i < 10; i++) {
if (i % 2 == 0) {
doSomething(i);
}
else {
doSomethingElse(i);
}
}
ou, dans un langage de balisage...
{|
|-
| lots of stuff...
more stuff
|| alternative for short lines || etc.
|}
{|
|-
... etc
|}
Style de lisp
Un programmeur peut même aller jusqu'à insérer des accolades fermantes dans la dernière ligne d'un bloc. Ce style fait de l'indentation le seul moyen de distinguer les blocs de code, mais a l'avantage de ne contenir aucune ligne non informative. Cela pourrait facilement être appelé le style Lisp (car ce style est très courant dans le code Lisp) ou le style Python (Python n'a pas d'accolades, mais la disposition est très similaire, comme indiqué dans les blocs de code ci-dessous). En Python, la mise en page fait partie du langage, appelée règle de hors-jeu .
// In C
for (i = 0; i < 10; i++)
{if (i % 2 == 0)
{doSomething(i);}
else
{doSomethingElse(i);
doThirdThing(i);}}
# In Python
for i in range(10):
if i % 2 == 0:
do_something(i)
else:
do_something_else(i)
do_third_thing(i)
;; In Lisp
(dotimes (i 10)
(if (= (rem i 2) 0)
(do-something i)
(progn
(do-something-else i)
(do-third-thing i))))
Style Haskell
La disposition Haskell peut rendre le placement des accolades facultatif, bien que les accolades et les points-virgules soient autorisés dans la langue. Les deux segments ci-dessous sont également acceptables pour le compilateur :
braceless = do
text <- getContents
let
firstWord = head $ words text
bigWord = map toUpper firstWord
putStrLn bigWord
braceful = do
{ text <- getContents
; let
{ firstWord = head $ words text
; bigWord = map toUpper firstWord
}
; putStrLn bigWord
}
En Haskell, la disposition peut remplacer les accolades. Habituellement, les accolades et les points-virgules sont omis pour les do sections procédurales et le texte du programme en général, mais le style est couramment utilisé pour les listes, les enregistrements et autres éléments syntaxiques constitués d'une paire de parenthèses ou d'accolades, qui sont séparés par des virgules ou des points-virgules. Si le code suivant les mots-clés where, let, ou ofomet les accolades et les points-virgules, alors l'indentation est significative.
Autres considérations
Perdre la trace des blocs
Dans certaines situations, il existe un risque de perdre la trace des limites de bloc. Cela se voit souvent dans de grandes sections de code contenant de nombreuses instructions composées imbriquées à de nombreux niveaux d'indentations. Au moment où le programmeur fait défiler jusqu'au bas d'un énorme ensemble d'instructions imbriquées, il peut avoir perdu la trace des instructions de contrôle qui vont où. Cependant, un code trop long peut avoir d'autres causes, telles qu'être trop complexe , et un programmeur confronté à ce problème pourrait plutôt se demander si la refactorisation du code serait utile à plus long terme.
Les programmeurs qui comptent sur le comptage des accolades ouvrantes peuvent avoir des difficultés avec les styles d'indentation tels que K&R, où l'accolade de départ n'est pas visuellement séparée de son instruction de contrôle . Les programmeurs qui s'appuient davantage sur les indentations tireront davantage profit des styles verticalement compacts, tels que K&R, car les blocs sont plus courts.
Pour éviter de perdre la trace des instructions de contrôle telles que for, une grande indentation peut être utilisée, telle qu'un onglet fixe de 8 unités de large, ainsi que la division des fonctions volumineuses en fonctions plus petites et plus lisibles. Linux est fait de cette façon, tout en utilisant le style K&R.
Dans les éditeurs de texte de la famille vi , un moyen de suivre les limites des blocs consiste à positionner le curseur de texte sur l'une des accolades et à appuyer sur la %touche . Le curseur saute alors sur l'accolade opposée. Étant donné que la nexttouche du curseur de texte (c'est-à-dire la ntouche) conservait les informations de positionnement directionnel (que la touche upou ait downété précédemment enfoncée), la macro de points (la .touche) pourrait alors être utilisée pour placer le curseur de texte sur l'accolade suivante, étant donné un style de codage. Au lieu de cela, l'inspection des limites de bloc à l'aide de la %clé peut être utilisée pour appliquer une norme de codage.
Une autre façon consiste à utiliser des commentaires en ligne ajoutés après l'accolade fermante :
for (int i = 0; i < total; i++) {
foo(bar);
} //for (i)
if (x < 0) {
bar(foo);
} //if (x < 0)
Le principal inconvénient de cette méthode est le maintien du code dupliqué à plusieurs emplacements.
Une autre solution est implémentée dans un éditeur de pliage , qui peut masquer ou révéler des blocs de code via leur niveau d'indentation ou leur structure d'instruction composée. De nombreux éditeurs mettront également en évidence les crochets ou les accolades correspondants lorsque le curseur est positionné à côté d'un.
Insertion de la déclaration
Le style K&R empêche une autre erreur courante lors de l'utilisation de l' éditeur de ligne Unix standard , ed . Une instruction insérée par erreur entre l'instruction de contrôle et l'accolade ouvrante du bloc de boucle transforme le corps de la boucle en un seul voyage.
for (int i = 0; i < 10; i++)
whoops(bar); /* repeated 10 times, with i from 0 to 9 */
{
only_once(); /* Programmer intended this to be done 10 times */
} //for (i) ← This comment is no longer valid, and is very misleading!
Le style K&R évite ce problème en gardant l'instruction de contrôle et l'accolade ouvrante sur la même ligne.
Voir également
Les références
Liens externes
- C Style : Standards and Guidelines: Defining Programming Standards for Professional C Programmers , Prentice Hall, ISBN 0-13-116898-3 / ISBN 978-0-13-116898-5 (le texte intégral est également en ligne). Straker, David (1992).
- Retrait contextuel
- Normes de codage GNU
- Formateurs de code source chez Curlie