Guide des lignes directrices

Cette série de documents décrit les directives de codage et les meilleures pratiques que nous utilisons pour écrire des démonstrations, des extraits de code, des exemples interactifs, etc. à utiliser sur MDN.

Si vous cherchez des lignes directrices à suivre pour rédiger vos exemples de codes, vous êtes au bon endroit. Le plus grand avantage de respecter ces directives est qu'elles favoriseront la cohérence entre nos échantillons et nos démos sur MDN, ce qui augmente la lisibilité et la compréhension en général.

Note: Si vous souhaitez obtenir des conseils sur le style du code tel qu'il apparaît sur un article de MDN, plutôt que sur le contenu du code, consultez notre Guide de formatage.

Structure de l'article

Cet article contient les meilleures pratiques générales de haut niveau pour la rédaction d'exemples de codes MDN. Ses sous-articles sont les suivants :

Meilleures pratiques générales

Cette section fournit rapidement les meilleures pratiques générales pour créer un échantillon de code minimal compréhensible afin de démontrer l'utilisation d'une caractéristique ou d'une fonction spécifique.

Les échantillons de code doivent l'être :

  • assez simple pour être compréhensible, mais
  • suffisamment complexe pour faire quelque chose d'intéressant, et de préférence utile.

Il y a une considération primordiale que vous devez garder à l'esprit : Les lecteurs copieront et colleront l'échantillon de code dans leur propre code, et pourront le mettre en production.

Par conséquent, vous devez vous assurer que l'exemple de code est utilisable et suit les meilleures pratiques généralement acceptées, et ne fait rien qui puisse rendre une application peu sûre, grossièrement inefficace, gonflée ou inaccessible. Si l'exemple de code n'est pas utilisable ou ne vaut pas la peine d'être produit, veillez à inclure un avertissement dans un commentaire de code et dans le texte explicatif — s'il s'agit d'un extrait et non d'un exemple complet, précisez-le clairement. Cela signifie également que vous devez fournir toutes les informations nécessaires à l'exécution de l'exemple, y compris les dépendances et la configuration.

Les échantillons de code doivent être aussi autonomes et faciles à comprendre que possible. L'objectif n'est pas nécessairement de produire un code efficace et intelligent qui impressionne les experts et possède une grande fonctionnalité, mais plutôt de produire des exemples de travail réduits qui peuvent être compris le plus rapidement possible.

Lignes directrices :
  • L'échantillon doit être court et, dans l'idéal, ne montrer que l'élément qui vous intéresse immédiatement.
  • N'incluez que le code qui est essentiel pour l'exemple. Une grande quantité de code non pertinent peut facilement distraire ou embrouiller le public. Si vous souhaitez fournir un exemple complet et plus long, placez-le dans l'un de nos dépôts Github (ou un JSBin, Codepen ou similaire) et fournissez ensuite le lien vers la version complète au-dessus ou au-dessous de l'exemple.
  • N'incluez pas de code inutile côté serveur, de bibliothèques, de cadres, de préprocesseurs et d'autres dépendances de ce type ils rendent le code moins portable et plus difficile à exécuter et à comprendre. Utilisez du code "vanilla" lorsque c'est possible.
  • Ne supposez pas que vous connaissez des bibliothèques, des cadres, des préprocesseurs ou d'autres caractéristiques non natives. Par exemple, utilisez des noms de classe qui ont un sens dans l'exemple plutôt que des noms de classe qui ont un sens pour les utilisateurs de BEM ou de Bootstrap.
  • Écrivez votre code de la façon la plus propre et la plus compréhensible possible, même si ce n'est pas la façon la plus efficace de le faire.
  • N'utilisez pas de mauvaises pratiques par souci de brièveté (comme les éléments de présentation tels que <big> ou document.write()); faites-le correctement.
  • Dans le cas de démonstrations d'API, si vous utilisez plusieurs API ensemble, indiquez quelles API sont incluses et quelles fonctionnalités proviennent d'où.