Manual:Coding conventions/fr

Cette page décrit les conventions de codage utilisées dans le code de base de MediaWiki et les extensions utilisées pour les sites web Wikimedia, y compris les conventions de nommage correspondantes. Les modifications qui ne suivent pas ces conventions peuvent être arbitrairement refusées (notées -1 pour la validation par les relecteurs de code); ceci doit être considéré comme une invitation à corriger les problèmes de style et mettre à jour le patch.

Cette page liste les conventions générales qui s'appliquent à l'ensemble du code MediaWiki, quelque soit le langage dans lequel il est écrit. Pour les instructions concernant des composants spécifiques ou des types de fichiers particuliers de MediaWiki, voir:



Sur Wikitech (s'applique au moins aux opérations/puppet):


 * Puppet

Largeur des tabulations
Les lignes doivent être indentées avec un seul caractère Tab par niveau d'indentation. Ne faites pas de supposition sur le nombre d'espaces par Tab. La plupart des développeurs MediaWiki estiment que 4 espaces par Tab conviennent bien pour la lisibilité, mais beaucoup de systèmes sont configurés pour utiliser 8 espaces par Tab et certains développeurs peuvent utiliser aussi 2 espaces par Tab.

Pour les utilisateurs vim, une manière de faire ces initialisations est d'ajouter ce qui suit à $HOME/.vimrc:

autocmd Filetype php setlocal ts=4 sw=4

avec des lignes semblables pour CSS, HTML et JavaScript.

Néanmoins, pour Python, suivez à la place le guide concernant les espaces de PEP 8, qui recommande les espaces pour les nouveaux projets.

Nouvelles lignes
Tous les fichiers doivent utiliser le passage à la ligne du style Unix (caractère LF uniquement, et non une combinaison CR+LF).


 * git sous Windows va (par défaut) convertir les passages à la ligne CR+LF en LF lors de la validation (commit).

Tous les fichiers doivent se terminer par un retour à la ligne.


 * Cela a un sens parce que toutes les autres lignes ont un caractère de nouvelle ligne à la fin.
 * Cela aide à faire circuler plus facilement les données en formats non binaires (comme les diffs).
 * Les outils en ligne de commande comme cat et wc ne manipulent pas les fichiers si aucun n'est bon (ou au moins, pas de la manière que l'on voudrait ou que l'on souhaiterait).

Encodage
Tous les fichiers texte doivent être encodés avec UTF-8 sans Byte Order Mark (BOM).

N'utilisez pas Microsoft Notepad pour modifier vos fichiers, parce qu'il insère toujours un BOM. Le BOM arrête l'exécution des fichiers PHP parce que c'est un caractère spécial tout au début du fichier et qu'il est passé par le navigateur web au client.

Bref, assurez-vous que votre éditeur prend en charge UTF-8 sans BOM.

Caractères espaces de fin de ligne
Quand vous utilisez un IDE, en pressant les touches Home et End (parmi d'autres raccourcis clavier) vous ignorez habituellement les espaces de fin et à la place vous sautez à la fin du code, ce qui est le but. Pour les éditeurs de texte non-IDE, au contraire, en pressant End vous allez à l'extémité complète de la ligne, ce qui signifie que le développeur doit revenir en arrière à travers les espaces de fin pour revenir finalement à l'endroit où il voulait entrer son texte.

Enlever les espaces de fin est une opération triviale pour la plupart des éditeurs de texte. Les développeurs doivent éviter d'ajouter des espaces après la fin, principalement sur les lignes qui contiennent d'autre code visible.

Certains outils rendent cela plus facile:


 * nano: GNU nano 3.2;
 * : dans Enregistrer les options du menu "Editer > Préférences", active "Supprimer les espaces et les marqueurs de fin de ligne" et "Nettoyer seulement les lignes modifiées";
 * Kate: vous pouvez voir les espaces de fin en activant l'option "Metre en valeur les espaces de fin". Cette option se trouve dans "Paramètres > Configurer Kate > Aspect". Vous pouvez aussi dire à Kate de nettoyer les espaces de fin lors de l'enregistrement dans "Paramètres > Configurer Kate > Ouvrir/Enregistrer".
 * vim: divers plugin de nettoyage automatique;
 * Sublimer le texte: plugin TrailingSpaces.

Mots-clé
N'utilisez pas de parenthèses avec des mots-clé (comme,  ) là où ce n'est pas nécessaire.

Style général
Le style d'indentation de MediaWiki est similaire à ce que l'on appelle le "style à une accolade vraie" (One True Brace Style). Les accolades sont ainsi placées sur la même ligne que le début de la fonction, de la condition, de la boucle, etc. Le else/elseif est placé sur la même ligne que l'accolade fermante qui le précède.

Les instructions qui s'écrivent sur plusieurs lignes ont leur seconde ligne et les suivantes indentées d'un niveau supplémentaire:

Utilisez l'indentation et le passage à la ligne suivante pour clarifier la structure logique de votre code. Les expressions qui imbriquent des niveaux multiples de parenthèses ou des structures similaires peuvent commencer un nouveau niveau d'indentation avec chaque niveau d'imbrication:

Alignement vertical
Evitez l'alignement vertical. Il a tendance à créer des diffs difficiles à interpréter, parce que la largeur autorisée pour la colonne de gauche doit sans cesse augmenter au fur et à mesure que des éléments sont ajoutés.

Quand c'est nécessaire, créez un alignement vertical sur la ligne du milieu avec des espaces plutôt que des tabulations. Par exemple, ceci :

Se réalise ainsi avec les espaces remplacés par des points:

 $namespaceNames·=·[ → NS_MEDIA············=>·'Media', → NS_SPECIAL··········=>·'Special', → NS_MAIN·············=>·'', ];

(Si vous utilisez le plugin vim de tabulation, en entrant :Tabularize /= vous alignerez les signes '='.)

Continuation de ligne
Les lignes doivent s'arrêter entre les colonnes 80 et 100. Il existe quelques rares exceptions à cela. Les fonctions qui prennent beaucoup de paramètres ne font pas exception.

L'opérateur qui sépare les deux lignes doit être placé de manière cohérente (toujours à la fin, ou toujours au début de la ligne). Certaines langages peuvent avoir individuellement des règles plus spécifiques.

L'opérateur de méthode doit toujours être mis au début de la ligne suivante.

Lorsque vous continuez des instructions "if", un sélecteur d'accolades de   style Allman rend plus claire la séparation entre la condition et le corps :

Les opinions diffèrent sur le nombre d'indentations qui doivent être utilisées pour la partie conditionnelle. En utilisant un nombre d'indentations différent que celui du corps, on voit de suite que la partie contitionnelle n'est pas le corps, mais ceci n'est pas observé universellement.

La continuation des conditions et les expressions très longues deviennent inextricables quelque soit la manière dont vous les formuliez. Il est donc parfois meilleur de les séparer à l'aide de variables temporaires.

Structures de contrôle sans accolades
N'écrivez pas les « blocs » sur une seule ligne. Cela réduit la lisibilité du code en déplaçant les instructions importantes de la marge gauche, là où le lecteur les attend. Rappelez-vous que faire un code plus court ne le simplifie pas. Le but du style de codage est de communiquer efficacement avec les humains, et non pas de placer du texte compréhensible par l'ordinateur dans un petit espace.

Ceci évite une erreur de logique commune, qui est particulièrement importante quand le développeur utilise un éditeur de texte qui n'a pas la fonction d' « indentation intelligente ». L'erreur apparait alors quand un bloc mono-ligne est ensuite étendu sur deux lignes :

Modifié ultérieurement en:

Ceci a la capacité de créer des bogues subtiles.

Style emacs
Dans emacs, en utilisant  du mode nXHTML, vous pouvez définir un mode MediaWiki mineur dans votre fichier   :

La fonction  ci-dessus, va vérifier votre chemin lorsque   est appelé pour voir si s'il contient “mw” ou “mediawiki” et initialiser le tampon pour utiliser le mode mineur   pour la modification du source MediaWiki. Vous saurez que le tampon utilise  parce que vous verrez quelquechose comme “PHP MW” ou “PHP/lw MW” dans le champ du mode ligne.

Construction des URL
Ne construisez jamais les URL manuellement avec des concaténations de chaînes ou similaire. Utilisez toujours le format complet de l'URL pour les requêtes faites par votre code (particulièrement pour les requêtes POST et d'arrière-plan).

Vous pouvez utiliser la méthode appropriée de ou de  en PHP, le mot magique  dans le texte wiki, la méthode mw.util.getUrl en JavaScript, et d'autres méthodes similaires dans d'autres langages. Vous éviterez les problèmes avec la configuration d'URL courte non-attendue et davantage.

Nommage des fichiers
Les fichiers qui contiennent du code côté serveur doivent être nommés en casse mixte commençant par une majuscule. C'est aussi notre convention de nommage pour les extensions. Nommer le fichier d'après la plus importante classe qu'il contient; la plupart des fichiers ne contiennent qu'une seule classe, ou une classe de base et un nombre de descendants. Par exemple,  ne contient que la classe   ;   contient la classe  , avec ses descendants:   et.

Fichiers des points d'accès
Nommez les fichiers de « point d'accès », tels que les points d'entrée de SQL et PHP, comme  et , en minuscules. Les scripts de maintenance sont généralement en casse mixte, bien que cela puisse varier. Les fichiers de l'administrateur de site, comme les README, les licences et les jounaux des modifications, sont habituellement en MAJUSCULES.

N'utilisez jamais les espaces dans les noms de fichiers ou de répertoires, et n'utilisez jamais les caractères non-ASCII. Pour les titres en minuscules, les tirets sont préférables aux caractères soulignés.

Fichiers JS, CSS, et de média
Pour JavaScript, les fichiers CSS et autres frontend (généralement enregistrés via ResourceLoader) doivent être placés dans un répertoire nommé d’après le bundle de modules dans lequel ils sont enregistrés. Par exemple. module  peut avoir des fichiers   et

Les fichiers JavaScript qui définissent les classes doivent correspondre exactement au nom de la classe qu’elles définissent. Le code de classe  doit être dans un fichier nommé, ou se terminant par. Cela permet une navigation rapide dans les éditeurs de texte en naviguant vers des fichiers nommés d’après un nom de classe sélectionné (comme "Goto Anything [P]" dans Sublime, ou "Find File [P]" dans Atom).

Les grands projets peuvent avoir des classes dans une hiérarchie avec des noms qui se chevaucheraient ou seraient ambigus sans un moyen supplémentaire d’organiser les fichiers. Nous abordons généralement cela avec des sous-répertoires comme  (pour Package files), ou des noms de classes et de fichiers plus longs comme   dans.

Les paquets de modules enregistrés par des extensions doivent suivre des noms comme, par exemple. Cela permet de commencer facilement à travailler sur un module dans un éditeur de texte, en trouvant directement les fichiers de code source à partir seulement du nom du module public (T193826).

Documentation
Les sous-pages spécifiques à un langage ont davantage d'informations sur la syntaxe exacte concernant les commentaires dans les fichiers de code, par exemple les commentaires en PHP pour Doxygen. En utilisant la syntaxe précise, vous pourrez générer la documentation à partir du code source, sur doc.wikimedia.org.

Les concepts de haut niveau, les sous-systèmes, et les flux de données doivent être documentés dans le répertoire.

Entêtes des fichiers source
Pour être conforme avec la plupart des licenses vous devez avoir quelque chose de similaire à ceci (spécifique aux applications PHP GPLv2) au début de chaque fichier source.

Licences
Les licenses sont généralement référencées par leur nom complet ou un acronyme comme pour le SPDX standard. Voir aussi Manual:$wgExtensionCredits#license.

Identifiants dynamiques
It is generally recommended to avoid dynamically constructing identifiers such as interface message keys, CSS class names, or file names. When possible, write them out and select between them (e.g. using a conditional, ternary, or switch). This improves code stabilty and developer productivity through: easier code review, higher confidence during debugging, usage discovery, git-grep, Codesearch, etc.

If code is considered to be a better reflection of the logical structure, or if required to be fully variable, then you may concatenate the identifier with a variable instead. In that case, you must leave a comment nearby with the possible (or most common) values to demonstrate behaviour and to aid search and discovery.

Voir aussi :
 * Help:System message

Notes des versions
Vous devez documenter toutes les modifications significatives (y compris les rapports de bogues corrigés) faites sur le coeur du logiciel qui pourraient impacter les utilisateurs du wiki, les administrateurs des serveurs, ou les auteurs des extensions dans le fichier. est en développement; pour chaque version nous déplaçons les anciennes notes de diffusion dans le fichier  et nous en ouvront un nouveau. est généralement divisé en trois sections :


 * Configuration changes c'est l'endéroit pour décrire les modifications relatives aux comportements par défaut acceptés, aux ruptures de compatibilité, et autres sujets qui demandent à ce qu'administrateur de serveurs regarde et décide "si la modification est acceptable pour son wiki". Essayez d'inclure une explication brève sur la manière de revenir à l'ancienne fonctionalité si cela est désiré.
 * Bug fixes c'est l'endroit pour décrire les modifications qui corrigent le comportement désigné comme problématique ou indésirable. Cela correspond souvent à des tâches référencées dans, mais pas nécessairement.
 * New features sert, vous vous en doutez, à décrire l'ajout d'une nouvelle fonctionalité.

Il peut y avoir des sections supplémentaires pour les comportements spécifiques (par exemple l'API Action) ou pour diverses modifications qui ne rentrent pas dans les catégories ci-dessus.

Dans tous les cas, si vos modifications concernent la réponse à un ou plusieurs problèmes référencés dans Phabricator, mettez le ou les ID des tâches concernées au début de l'entrée. Ajoutez de nouvelles entrées dans l'ordre chronologique à la fin de la section.

Messages système
Quand vous créez un nouveau message système, utilisez des tirets (-) quand c'est possible au lieu d'une casse mixte ou d'utiliser le souligné(_). Ainsi par exemple,  est bien pour un nom, tandis que   ou   sont à proscrire.

Si le message est une étiquette qui peut avoir un deux-points à la fin, ne codez pas le deux-points; à la place, mettez le dans le texte du message. Certaines langues (telles que le français qui demande d'avoir un espace avant) doivent gérer le deux-points d'une manière différente, ce qui est impossible si les deux-points sont codés en dur. Ceci vaut pour plusieurs autres d'interpunctuation.

Essayez d'utiliser les clés de messages "en entier" dans le code, plûtot que de les construire à la volée; car c'est plus facile de les rechercher dans la base de code. L'exemple suivant montre qu'une recherche de  ne trouvera pas cette utilisation de clé de message si elle n'est pas entière.

Si vous pensez que vous devez construire les messages à la volée, mettez à côté, un commentaire avec tous les messages possibles en entier:

Voir la Localisation pour davantage de conventions concernant la créatiion, l'usage, la documentation et la maintenance des clés de messages.

Orthographe préférée
C'est aussi important d'avoir une orthographe cohérente de l'interface utilisateur avec la base de code que d'avoir une interface cohérente. Après un long historique, l'orthographe de l'anglais américain ('American English') est l'orthographe préférée pour les messages en langue anglaise, les commentaires, et la documentation.

Abbréviations des clés de messages

 * ph
 * emplacement à substituer (texte des champs d'entrée)


 * tip
 * texte de la bulle d'aide


 * tog-xx
 * gérer les options dans les préférences utilisateur

Ponctuation
Les messages d'erreur qui ne sont pas des titres sont considérés comme des phrases et doivent avoir une ponctuation.

Améliorer le noyau
Si vous avez besoin de fonctionnalités supplémentaires concernant un composant du noyau MediaWiki (classe PHP, module JS, etc...), ou si vous voulez une fonction qui fait quelque chose de similaire mais un peu différent, il est préférable d'améliorer le composant du noyau. Evitez de dupliquer le code dans une extension ou ailleurs dans le noyau et de le modifier à cet endroit.

Remise en forme du code
Restructurez le code aussitôt que les modifications sont faites: n'attendez pas que le code s'enlaidisse au fur et à mesure des modifications.

Néanmoins, utilisez des commits séparés si votre restructuration est importante. Voir aussi les Instructions pour l'architecture (ébauche).

HTML
Les réponses HTTP de MediaWiki produisent du code HTML qui peut être généré par l'une des deux sources. Le code PHP de MediaWiki est une source fiable pour l'interface utilisateur, il peut produire tout HTML arbitraire. L'analyseur convertit le texte wiki généré de l'utilsateur en HTML, c'est une source non fiable. Le code HTML complexe créé par les utilisateurs via le texte wiki est souvent issu de l'espace de noms « Template ». Le HTML produit par l'analyseur est sujet à être nettoyé avant d'être envoyé.

La plupart des attributs de données peuvent être employés par les utilisateurs dans le texte wiki et les modèles. Mais les préfixes suivants ont été restreints et ne sont pas autorisés dans les textes wiki. Ceci permet au code JavaScript du client de déterminer si un élément DOM provient d'une source de confiance ou pas : Ceci permet de savoir au code JavaScript du client si un élément du DOM provient d'une source fiable :


 * – Cet attribut est présent dans le HTML généré par les widgets OOUI.
 * – attribut réservé à usage interne pour Parsoid.
 * – attribut réservé à usage interne du coeur de MediaWiki, des habillages et des extensions. L'attribut  est utilisé par Parsoid; tout autre code du noyau doit utiliser.

En sélectionnant des éléments dans JavaScript, on peut préciser un attribut clé/valeur pour s'assurer que seulement les éléments DOM de la source présumée de confiance, sont pris en compte. Exemple: Ne gèrer que l'accroche 'wikipage.diff' pour les diffs officiels.

Liens externes

 * outils de style pour le code