Comme nous le savons du chapitre Structure du code, les commentaires peuvent ĂȘtre simples : Ă partir de // et multiligne : /* ... */.
Nous les utilisons normalement pour décrire comment et pourquoi le code fonctionne.
De prime abord, les commentaires peuvent sembler évidents, mais les novices en programmation les utilisent souvent à tort.
Mauvais commentaires
Les novices ont tendance Ă utiliser des commentaires pour expliquer âce qui se passe dans le codeâ. Comme ceci :
// Ce code fera cette chose (...) et cette chose (...)
// ...Et qui sait quoi d'autre...
very;
complex;
code;
Mais en bon code, le nombre de ces commentaires âexplicatifsâ devrait ĂȘtre minime. SĂ©rieusement, le code devrait ĂȘtre facile Ă comprendre sans eux.
Il existe une excellente rĂšgle Ă ce sujet: âSi le code est si peu clair quâil nĂ©cessite un commentaire, il devrait peut-ĂȘtre ĂȘtre réécritâ.
Recette: refactoriser les fonctions
Parfois, il est avantageux de remplacer un code par une fonction, comme ici :
function showPrimes(n) {
nextPrime:
for (let i = 2; i < n; i++) {
// check if i is a prime number
for (let j = 2; j < i; j++) {
if (i % j == 0) continue nextPrime;
}
alert(i);
}
}
La meilleure variante, avec une fonction factorisée est isPrime :
function showPrimes(n) {
for (let i = 2; i < n; i++) {
if (!isPrime(i)) continue;
alert(i);
}
}
function isPrime(n) {
for (let i = 2; i < n; i++) {
if (n % i == 0) return false;
}
return true;
}
Maintenant, nous pouvons comprendre le code facilement. La fonction elle-mĂȘme devient le commentaire. Un tel code est appelĂ© auto-descriptif.
Recette: créer des fonctions
Et si nous avons une longue âfeuille de codeâ comme celle-ci :
// ici on ajoute du whisky
for(let i = 0; i < 10; i++) {
let drop = getWhiskey();
smell(drop);
add(drop, glass);
}
// ici on ajoute du jus
for(let t = 0; t < 3; t++) {
let tomato = getTomato();
examine(tomato);
let juice = press(tomato);
add(juice, glass);
}
// ...
Ce pourrait ĂȘtre une meilleure variante de le refactoriser dans des fonctions comme :
addWhiskey(glass);
addJuice(glass);
function addWhiskey(container) {
for(let i = 0; i < 10; i++) {
let drop = getWhiskey();
//...
}
}
function addJuice(container) {
for(let t = 0; t < 3; t++) {
let tomato = getTomato();
//...
}
}
Une fois encore, les fonctions elles-mĂȘmes racontent ce qui se passe. Il nây a rien Ă commenter. Et aussi la structure du code est meilleure quand elle est divisĂ©e. Câest clair ce que chaque fonction fait, ce quâelle nĂ©cessite et ce quâelle renvoie.
En rĂ©alitĂ©, nous ne pouvons pas totalement Ă©viter les commentaires «explicatifs». Il existe des algorithmes complexes. Et il existe des ârĂ©glagesâ intelligents Ă des fins dâoptimisation. Mais gĂ©nĂ©ralement, nous devrions essayer de garder le code simple et auto-descriptif.
Bons commentaires
Ainsi, les commentaires explicatifs sont généralement mauvais. Quels commentaires sont bons ?
- DĂ©crivez lâarchitecture
- Fournissez une vue dâensemble des composants, de leurs interactions, de ce que sont les flux de contrĂŽle dans diverses situations⊠En bref â une vue plongeante du code. Il existe un langage spĂ©cial UML pour les diagrammes dâarchitecture de haut niveau. Ăa vaut vraiment la peine de lâĂ©tudier.
- Documenter les paramĂštres de fonction et leur utilisation
- Il y a une syntaxe spéciale JSDoc pour documenter une fonction : utilisation, paramÚtres, valeur renvoyée.
Par exemple :
/**
* Renvoie x élevé à la n-iÚme puissance.
*
* @param {number} x Le nombre Ă augmenter.
* @param {number} n L'exposant doit ĂȘtre un nombre naturel.
* @return {number} x élevé à la n-Úme puissance.
*/
function pow(x, n) {
...
}
De tels commentaires nous permettent de comprendre le but de la fonction et de lâutiliser correctement sans regarder dans son code.
à ce propos, de nombreux éditeurs comme WebStorm peut aussi les comprendre et les utiliser pour fournir une autocomplétion et une vérification automatique du code.
En outre, il existe des outils comme JSDoc 3 qui peut gĂ©nĂ©rer une documentation HTML Ă partir des commentaires. Vous pouvez lire plus dâinformations sur JSDoc Ă lâadresse http://usejsdoc.org/.
- Pourquoi la tùche est-elle résolue de cette façon ?
-
Ce qui est Ă©crit est important. Mais ce qui nâest pas Ă©crit peut ĂȘtre encore plus important pour comprendre ce qui se passe. Pourquoi la tĂąche est-elle rĂ©solue exactement de cette façon ? Le code ne donne pas de rĂ©ponse.
Sâil y a plusieurs façons de rĂ©soudre la tĂąche, pourquoi celle-ci ? Surtout quand ce nâest pas la plus Ă©vidente.
Sans ces commentaires, la situation suivante est possible :
- Vous (ou votre collĂšgue) ouvrez le code Ă©crit il y a quelque temps et constatez quâil nâest pas optimal.
- Vous pensez: âĂ quel point jâĂ©tais bĂȘte Ă ce moment-lĂ et Ă quel point je suis plus malin maintenantâ, puis réécrivez en utilisant la variante âplus Ă©vidente et correcteâ.
- ⊠Lâenvie de réécrire Ă©tait bonne. Mais dans le processus, vous constatez que la solution âplus Ă©videnteâ fait dĂ©faut. Vous vous rappelez mĂȘme vaguement pourquoi, parce que vous lâavez dĂ©jĂ essayĂ© il y a longtemps. Vous revenez Ă la bonne variante, mais le temps a Ă©tĂ© perdu.
Les commentaires qui expliquent la solution sont trÚs importants. Ils aident à continuer le développement de la bonne façon.
- Les caractĂ©ristiques subtiles du code ? OĂč sont-elles utilisĂ©s ?
-
Si le code a quelque chose de subtil et de contre-intuitif, cela vaut vraiment la peine de le commenter.
Résumé
Les commentaires sont une caractĂ©ristique importante du bon dĂ©veloppeur : leur prĂ©sence et mĂȘme leur absence.
Les bons commentaires nous permettent de bien maintenir le code, dây revenir aprĂšs un dĂ©lai et de lâutiliser plus efficacement.
Commentez ceci :
- Architecture globale, vue de haut niveau.
- Utilisation de la fonction.
- Les solutions importantes, surtout lorsquâelles ne sont pas immĂ©diatement Ă©videntes.
Ăvitez les commentaires :
- Qui disent âcomment fonctionne le codeâ et âce quâil faitâ.
- Ne les mettez que sâil est impossible de rendre le code aussi simple et auto-descriptif quâil nâen nĂ©cessite pas.
Les commentaires sont également utilisés pour les outils de documentation automatique tels que JSDoc3. Ils les lisent et génÚrent des documents HTML (ou des documents dans un autre format).
Commentaires
<code>, pour plusieurs lignes â enveloppez-les avec la balise<pre>, pour plus de 10 lignes - utilisez une sandbox (plnkr, jsbin, codepenâŠ)