# Programmation/Structure et style

* Historique
* Abstraction

## Concepts de base

* Commentaires
* Instructions
* Variables
* Types
* Expressions
* Comparaisons
* Instructions de contrôle
* Entrées-sorties

## Concepts spécifiques

* Manipulation de chaînes
* Procédures et fonctions
* Gestion de mémoire
* Gestion des exceptions
* Paradigmes de programmation
* Programmation séquentielle
* Programmation concurrente
* Programmation impérative
* Programmation orientée objet
* Programmation générique
* Programmation orientée aspect
* Programmation fonctionnelle
* Programmation logique
* Programmation par contrat

## Logiciels

* Eclipse
* NetBeans
* PhpStorm
* PyCharm
* SciTE
* Visual Studio Code

## Annexes

* Structure et style
* Règles de programmation
* Langages
* Historique
* Abstraction

## Concepts de base

* Commentaires
* Instructions
* Variables
* Types
* Expressions
* Comparaisons
* Instructions de contrôle
* Entrées-sorties

## Concepts spécifiques

* Manipulation de chaînes
* Procédures et fonctions
* Gestion de mémoire
* Gestion des exceptions
* Paradigmes de programmation
* Programmation séquentielle
* Programmation concurrente
* Programmation impérative
* Programmation orientée objet
* Programmation générique
* Programmation orientée aspect
* Programmation fonctionnelle
* Programmation logique
* Programmation par contrat

## Logiciels

* Eclipse
* NetBeans
* PhpStorm
* PyCharm
* SciTE
* Visual Studio Code

## Annexes

* Structure et style
* Règles de programmation
* Langages
[ Modifier le sommaire ]
La structure et le style d'un code source définissent sa présentation. Afin que la maintenance soit facile, il est nécessaire que la présentation du code soit cohérente dans tous les fichiers sources. Des règles de styles sont donc à définir.

## Langue

Les premiers langages de programmation ne gérant pas les accents (jeu de caractère limité à l'ASCII 7 bits), des habitudes ont été prises pour nommer les variables et écrire les commentaires sans accents. Cela a également aidé la langue anglaise à s'imposer.
Toutefois, cette limite technique n'existe plus dans les langages de programmation modernes, grâce notamment au support du jeu de caractères Unicode. Il est possible de nommer des variables en français avec des accents.
La langue utilisée dans les commentaires et dans la conception est donc d'un choix de développement.

## Style du code

Les caractères blancs (espaces, tabulations, retours à la ligne) sont généralement ignorés par la plupart des langages de programmation, et ne servent qu'à séparer deux mots dans les instructions. Ces caractères permettent donc de présenter le code de façon plus lisible que si les instructions s'enchaînaient sans espaces.
Ceci ne s'applique pas aux langages de programmation où l'indentation a une signification, comme le langage Python par exemple.
Exemple en C : Sans coloration syntaxique, quel code est le plus lisible ?
ou
Il est possible de définir ses propres règles de style, ou d'utiliser des règles de styles standard afin que la cohérence de présentation dépasse le cadre de son projet personnel.

## L'indentation

L'indentation définit l'espace blanc situé au début de chaque ligne de code. Les lignes de code sont rassemblées en blocs (fonctions, résultat d'un test, ...) et sont ordonnées de manière hiérarchique (bloc conditionnel dans une fonction, fonction dans une classe, classe dans un espace de nom, ...).
À chaque nouveau niveau hiérarchique plus profond, l'indentation augmente.
Exemple (dans un pseudo-langage) :
L'exemple précédent utilise 4 caractères espaces supplémentaire à chaque nouveau début de bloc hiérarchique. Le nombre de caractère espaces peut varier selon le style, il est même possible d'utiliser des caractères tabulations au lieu des espaces.
Utiliser des caractères tabulation au lieu des espaces présente certains avantages :
* Beaucoup de logiciels d'édition ou présentation permettent de définir le nombre d'espace à afficher pour chaque tabulation, ce qui permet à chacun d'adapter la présentation du code.
* Un caractère de tabulation occupant moins de place qu'une série de caractères espaces, le fichier source est plus petit. Cet avantage était particulièrement important pour les moyens de stockage limités (disquettes par exemple).
et certains inconvénients :
* Beaucoup de logiciels ne permettent pas de définir le nombre d'espace à afficher pour chaque tabulation qui est fixé (souvent 8, voire 4).
Les caractères de tabulation sont donc souvent à proscrire. Il est préférable d'utiliser le bon nombre de caractères espace à chaque nouvelle indentation :
* 1 ou 2 est souvent insuffisant pour distinguer les différents niveaux,
* 4 est généralement correct,
* 8 est largement trop grand, spécialement quand on limite la longueur des lignes de code (souvent 79 caractères maximum), la limite diminue alors rapidement à chaque nouveau niveau.
Cependant l'utilisation d'espaces a aussi des inconvénients :
* Certaines lignes peuvent être indentées avec un nombre invalide d'espaces. Par exemple (indentation de 4 espaces) des lignes indentées de 3 ou 5 espaces au lieu de 4, de 7 ou 9 au lieu de 8, ... La différence d'indentation n'est pas visible. Tandis qu'une différence d'un caractère de tabulation est très visible.
* L'indentation est fixe et imposée à tous. Un développeur reprenant un code existant ne pourra pas adapter facilement l'indentation du code si elle ne lui convient pas. Par exemple, le développeur originel utilisant un écran 4K utilise une indentation de 8 espaces, ce qui est trop grand pour un autre développeur utilisant un écran à faible résolution.
La règle d'or est de toujours utiliser le même style d'indentation (cohérence de présentation) et de ne surtout par mélanger espaces et tabulations.
Il faut aussi veiller à ne pas avoir besoin de plus de 5 indentations dans le code. Dans le cas contraire, il faut envisager de revoir la structure du code.

## Le style K&R

Le style K&R est nommé d'après Kernighan et Ritchie qui ont utilisé ce style dans leur livre Le langage de programmation C (The C Programming Language en version originale).
Ce style définit les règles suivantes :
* Chaque nouvelle accolade s'ouvre sur la même ligne que l'instruction de contrôle,
* L'indentation du contenu du bloc est augmenté,
* L'accolade fermante se situe au même niveau que l'instruction de l'accolade ouvrante.
Exemple:
Cependant, si la fonction utilise des arguments dont les types sont définis après, l'accolade ouvrante est sur une ligne à part :

## Le style Allman

Nommé d'après son auteur Eric Allman, ce style est essentiellement le même que K&R, excepté que chaque accolade ouvrante est située sur une ligne séparée.
Exemple:
La déclaration de la fonction, l'accolade ouvrante et l'accolade fermante sont 3 lignes séparées et possèdent le même niveau d'indentation.
Ce style est également utilisé dans les langages de programmation n'utilisant pas les accolades pour les blocs mais des mots-clés. Par exemple, en Pascal les blocs sont définis entre les mots-clés begin et end.

## Le style Whitesmiths

Moins commun que les précédents, ce style indente les accolades au même niveau que le bloc qu'il contient.
Exemple:

## Le style GNU

Ce style est intermédiaire entre le style Allman et le style Whitesmiths : les accolades sont semi-indentées.
Exemple:

## Voir aussi

* Développer en Java/Forges et bibliothèques#Les « Java Specification Requests » (JSR)
* Programmation PHP/Concevoir du code de haute qualité#PSR