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â¦)