Pewarta Proxy

📋 Server Request & Proxy Logs

Loading active proxy settings...
Developed by Khairul Adha (adhexa.id)
Mengambil log server...

⚙ Pengaturan Proxy Target

5 mai 2023

Commentaires

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 :

  1. Vous (ou votre collĂšgue) ouvrez le code Ă©crit il y a quelque temps et constatez qu’il n’est pas optimal.
  2. 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”.
  3. 
 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).

Carte du tutoriel

Commentaires

lire ceci avant de commenter

  • Si vous avez des amĂ©liorations Ă  suggĂ©rer, merci de soumettre une issue GitHub ou une pull request au lieu de commenter.
  • Si vous ne comprenez pas quelque chose dans l'article, merci de prĂ©ciser.
  • Pour insĂ©rer quelques bouts de code, utilisez la balise <code>, pour plusieurs lignes – enveloppez-les avec la balise <pre>, pour plus de 10 lignes - utilisez une sandbox (plnkr, jsbin, codepen
)