Conventions de codage

Informatique / Programmation
Programmation orientée objet avec Java
15 : Conventions de codage
Jacques Bapst
[email protected]
Java / Conventions de codage
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).
EIA-FR / Jacques Bapst
PR1_15
2
Java / Conventions de codage
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
EIA-FR / Jacques Bapst
PR1_15
3
Java / Conventions de codage
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).
if (a > b) {
 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
nb = 1;
}
else {
nb = -1;
ok = false;
}
 Aligner les instructions lorsque cela a un sens (lisibilité).
EIA-FR / Jacques Bapst
PR1_15
4
Java / Conventions de codage
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;
i++;
EIA-FR / Jacques Bapst
// Variable compteur
// i = i + 1
PR1_15
5
Java / Conventions de codage
Choix des identificateurs [1]
 D'une manière générale, les identificateurs doivent être autodescriptifs sans toutefois être trop longs (< ~30 caractères).
 Les variables temporaires peuvent faire exception à cette règle.
Par exemple les compteurs de boucle sont fréquemment déclarés
avec un seul caractère (traditionnellement i, j, k, m, n pour les entiers).
 Pour les identificateurs composés de plusieurs mots on adoptera
généralement la notation dite Mixed-Case ou Camel-Case où les
mots sont écrits en minuscules exceptée la première lettre des mots
lors de la transition d'un mot à l'autre (la première lettre du premier mot
pouvant être en majuscule ou en minuscule selon les cas).
aMixedCaseIdentifier
SomeOther
 Dans la notation Mixed-Case on n'utilise généralement pas d'autres
caractères de séparation.
EIA-FR / Jacques Bapst
PR1_15
6
Java / Conventions de codage
Choix des identificateurs [1]
Type
d'identificateur
Convention de nommage
Packages
Uniquement des mots en minuscules séparés com.ibm.javadev
par des points (niveaux hiérarchiques).
ch.eif.project.i02
Si possible, utilisation d'URL inversé.
Classes
Un ou plusieurs noms (substantifs).
Notation Mixed-Case (Camel-Case) avec
première lettre en majuscule.
Raster
StringTokenizer
Interfaces
Un ou plusieurs nom ou adjectifs.
Notation Mixed-Case (Camel-Case) avec
première lettre en majuscule.
Printable
ActionListener
Méthodes
(procédure)
Un verbe (év. avec compléments)
Notation Mixed-Case (Camel-Case) avec
première lettre en minuscule.
runProcess()
draw()
Méthodes
(fonctions)
Un ou plusieurs noms ou noms qualifiés
(éventuellement précédés de get ou is).
Notation Mixed-Case (Camel-Case) avec
première lettre en minuscule.
maxWidth()
isVisible()
EIA-FR / Jacques Bapst
Exemple
PR1_15
7
Java / Conventions de codage
Choix des identificateurs [2]
Type
d'identificateur
Convention de nommage
Exemple
Champs
Variables locales
Paramètres
Un ou plusieurs noms ou noms qualifiés.
Notation Mixed-Case (Camel-Case) avec
première lettre en minuscule.
position
maxSpeed
Constantes
(static final)
Un ou plusieurs noms ou noms qualifiés.
Mots en majuscules séparés par le caractère
souligné ('_').
PI
MAX_LENGTH
Énumérations
(enum)
Un ou plusieurs noms ou noms qualifiés.
Mots en majuscules séparés par le caractère
souligné ('_').
GREEN
ROTATION_MODE
Types génériques
Une seule lettre, en majuscule.
(<…>)
EIA-FR / Jacques Bapst
<K, V>
PR1_15
8