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:

Dans les instructions de type sélecteur, indentez à l'intérieur des accolades et entre les différents cas :

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  de nXHTML mode, vous pouvez définir un mode mineur MediaWiki dans votre fichier .emacs:

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 les fichiers JavaScript, CSS et media (habituellement chargés par le ResourceLoader) le nommage des fichiers doit suivre le nommage des modules. Par exemple :
 * le module  peut avoir les fichiers   et
 * le module  a le fichier

Les noms de modules enregistrés par les extensions doivent faire suivre le format suivant, par exemple:

Ceci permet de retrouver plus facilement les fichiers, même si vous coupez un module en modules plus petits pour faciliter les modifications puis les réassemblez en un module unique.

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 http://doc.wikimedia.org.

High level concepts, subsystems, and data flows should be documented in the folder.

Fichiers texte
Les développeurs peuvent garder les fichiers de documentation dans Git à côté du code. Ceci peut être bon pour la documentation détaillée de l'architecture d'une extension, la conception d'une base de données, etc. que vous devez mettre à jour avec chaque validation (commit) de code qui change le comportement. Les pages de mediawiki.org relatives à la documentation dans Git doivent déclarer le lien en utilisant.

(La possibilité de transclure du texte à partir des fichiers Git vers l'intérieur des pages wiki est répertoriée dans T91626.)

Notez que beaucoup de pages de documentation technique sur les pages mediawiki.org documentent l'évolution du code MediaWiki sur plusieurs versions. Décrivez les modifications dans votre document ou mettez le à jour en décrivant simplement la dernière base de code du "master".

Formats des fichiers texte

 * Doxygen [$mdurl prend en charge le formatage Markdown], donc vous pouvez mettre de la documentation formatée simplement dans les fichiers . Diffusion et GitHub supportent les fichiers   . Nommez le fichier d'explication d'un répertoire ou d'un projet  ; Diffusion et GitHub vont montrer ce fichier quand vous afficherez ce répertoire ou ce projet (par exemple $path de RESTbase, dans $Git et dans $GitHub). Diffusion and GitHub also support   files. Name the explanatory file for a directory or project  ; Diffusion and GitHub will display this file when you view that directory or project (e.g. RESTbase's , in  and on GitHub).
 * Doxygen [$mdurl prend en charge le formatage Markdown], donc vous pouvez mettre de la documentation formatée simplement dans les fichiers . Diffusion et GitHub supportent les fichiers   . Nommez le fichier d'explication d'un répertoire ou d'un projet  ; Diffusion et GitHub vont montrer ce fichier quand vous afficherez ce répertoire ou ce projet (par exemple $path de RESTbase, dans $Git et dans $GitHub). Diffusion and GitHub also support   files. Name the explanatory file for a directory or project  ; Diffusion and GitHub will display this file when you view that directory or project (e.g. RESTbase's , in  and on GitHub).
 * Doxygen [$mdurl prend en charge le formatage Markdown], donc vous pouvez mettre de la documentation formatée simplement dans les fichiers . Diffusion et GitHub supportent les fichiers   . Nommez le fichier d'explication d'un répertoire ou d'un projet  ; Diffusion et GitHub vont montrer ce fichier quand vous afficherez ce répertoire ou ce projet (par exemple $path de RESTbase, dans $Git et dans $GitHub). Diffusion and GitHub also support   files. Name the explanatory file for a directory or project  ; Diffusion and GitHub will display this file when you view that directory or project (e.g. RESTbase's , in  and on GitHub).


 * sans extension et
 * Doxygen par défaut les analyse comme des fichiers C (!!, référencé dans ). Vous pouvez profiter de cela en simulant un commentaire C pour le fichier, puis en y ajoutant des directives Doxygen. Par exemple,  génère l'Architecture des fichiers serveur dans Doxygen, et commence avec:




 * Special:Version/Credits suppose que  et   (sans extension) sont des fichiers de texte wiki.

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.

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 Phabricator, 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 fonctionalités supplémentaires concernant un composant du noyau de MediaWiki (classe PHP, module JS, etc...), ou si vous voulez une fonction qui fait quelque chose de similaire mais différent, il est préférable d'améliorez le composant du noyau. Evitez de dupliquer le code vers une extension ou ailleurs dans le noyau et de le modifier là-bas.

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 HTTP 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 :


 * – Cet attribut est présent dans le HTML généré par les widgets OOUI.
 * – attribut réservé à usage interne pour Parsoid.
 * et  – sont des attributs réservés à usage interne du coeur de MediaWiki, des habillages et des extensions. Le   est aussi utilisé par Parsoid.

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