Conventions de codage

Jacques Bapst
[e-mail]
Informatique / Programmation
Programmation orientée objet avec Java
15 : Conventions de codage

PR1_15
Java / Conventions de codage
EIA-FR / Jacques Bapst 2
Pourquoi des conventions de codage ?
Les fichiers sources d'un programme sont destinés à deux types
de lecteurs : l'humain et la machine (le compilateur notamment).
•Pour le compilateur : "a.b(c)"
vaut bien "myFile.println(currentTime)"
Les conventions de codage (Style Guidelines) ont pour but
d'améliorer, pour les humains, la lisibilité des fichiers sources
en respectant certaines règles qui ne sont pas imposées par le
langage (choix des identificateurs, mise en page, …).
Il existe des conventions plus ou moins contraignantes.
Un certain nombre de conventions générales (proposées par Sun)
sont adoptées par la très grande majorité des développeurs Java.
D'autres (généralement plus contraignantes) sont imposées dans le
cadre de certains projets afin de garantir une certaine homogénéité
des codes sources indépendamment de leur auteur (et assurer une
stabilité dans le temps).

PR1_15
Java / Conventions de codage
EIA-FR / Jacques Bapst 3
Pourquoi des conventions de codage ?
Le respect de certaines conventions générales facilite grandement
la lecture du code source :
•Reconnaissance plus rapide de la structure du code
(on se retrouve en terrain connu)
•Identification rapide de certaines entités par leur convention
d'écriture (constantes, classes, …)
Un code source est écrit une fois et généralement lu à de
nombreuses reprises (parfois longtemps après son écriture et
souvent par des lecteurs différents).
Il vaut donc la peine d'investir un peu de temps au moment de son
écriture afin de faciliter sa lecture et sa compréhension ultérieure.
Certains éditeurs offrent des aides pour la mise en page du code
source et le respect de certaines règles de codage.
Les conventions proposées par Oracle :
www.oracle.com/technetwork/java/codeconventions-150003.pdf

PR1_15
Java / Conventions de codage
EIA-FR / Jacques Bapst 4
Mise en page
Les commentaires doivent être alignés au niveau d'indentation
du code qui suit (pas de commentaires qui brisent la structure du code
en débordant dans la marge d'indentation).
Ne pas dépasser (env.) 80 caractères par lignes (pour éviter le
scrolling horizontal et les problèmes d'impression).
Une seule instruction par ligne (sauf exceptions).
Déclarer de préférence les variables locales au début des méthodes.
Décomposer le code des méthodes trop longues (celles qui ne
tiennent pas sur une page imprimée).
TOUJOURS bien indenter !
•Accolade ouvrante placée en fin de ligne
•Indentation de 2 ou 4 espaces
•Accolade fermante seule sur la ligne et
alignée sur le début de la ligne contenant
l'accolade ouvrante qui lui correspond
Aligner les instructions lorsque cela a un sens (lisibilité).
if (a > b) {
nb = 1;
}
else {
nb = -1;
ok = false;
}

PR1_15
Java / Conventions de codage
EIA-FR / Jacques Bapst 5
Commentaires
Pour les commentaires généraux utiliser de préférence la notation
"// texte" (même pour les commentaires qui s'étendent sur plusieurs
lignes).
Utiliser la notation "/* texte */" pour inactiver temporairement
une portion de code.
Pour les applications (ou librairies) d'une certaine envergure, des
commentaires de documentation ("/** texte */") devraient
précéder chaque classe et chaque membre public (champs et
méthodes) de la classe.
Pour les exercices, on pourra se contenter d'un en-tête précédant
chaque méthode (au minimum une ligne séparatrice).
Inutile d'ajouter des commentaires triviaux :
int counter; // Variable compteur
i++; // i = i + 1