Open main menu

Manuel:Conventions de codage

This page is a translated version of the page Manual:Coding conventions and the translation is 99% complete.
Outdated translations are marked like this.
Other languages:
English • ‎dansk • ‎español • ‎français • ‎polski • ‎português • ‎português do Brasil • ‎čeština • ‎русский • ‎العربية • ‎تۆرکجه • ‎සිංහල • ‎中文 • ‎日本語
Raccourci : CC

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

Structure du code

Formatage du fichier

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;
  • Edition de Komodo : 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 require_once, require) là où ce n'est pas nécessaire.

Indentation et alignement

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.

function wfTimestampOrNull( $outputtype = TS_UNIX, $ts = null ) {
    if ( $ts === null ) {
        return null;
    } else {
        return wfTimestamp( $outputtype, $ts );
    }
}

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:

$wgAutopromote = [
    'autoconfirmed' => [ '&',
        [ APCOND_EDITCOUNT, &$wgAutoConfirmCount ],
        [ APCOND_AGE, &$wgAutoConfirmAge ],
    ],
];

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

switch ( $word ) {
    case 'lorem':
    case 'ipsum':
        $bar = 2;
        break;
    case 'dolor':
        $bar = 3;
        break;
    default:
        $bar = 0;
        break;
}

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.

La plupart des outils de diff fournissent des options pour ignorer les modifications des espaces.
Git: git diff -w

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 :

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

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.

return strtolower( $val ) === 'on'
    || strtolower( $val ) === 'true'
    || strtolower( $val ) === 'yes'
    || preg_match( '/^\s*[+-]?0*[1-9]/', $val );
$foo->dobar(
    Xml::fieldset( wfMessage( 'importinterwiki' )->text() ) .
        Xml::openElement( 'form', [ 'method' => 'post', 'action' => $action, 'id' => 'mw-import-interwiki-form' ] ) .
        wfMessage( 'import-interwiki-text' )->parse() .
        Xml::hidden( 'action', 'submit' ) .
        Xml::hidden( 'source', 'interwiki' ) .
        Xml::hidden( 'editToken', $wgUser->editToken() ),
    'secondArgument'
);

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

$this->getMockBuilder( Message::class )->setMethods( [ 'fetchMessage' ] )
    ->disableOriginalConstructor()
    ->getMock();

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 :

if ( $.inArray( mw.config.get( 'wgNamespaceNumber' ), whitelistedNamespaces ) !== -1 &&
    mw.config.get( 'wgArticleId' ) > 0 &&
    ( mw.config.get( 'wgAction' ) == 'view' || mw.config.get( 'wgAction' ) == 'purge' ) &&
    mw.util.getParamValue( 'redirect' ) !== 'no' &&
    mw.util.getParamValue( 'printable' ) !== 'yes'
) {
    ..
}

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.

// No:
if ( $done ) return;

// No:
if ( $done ) { return; }

// Yes:
if ( $done ) {
    return;
}

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 :

if ( $done )
    return;

Modifié ultérieurement en:

if ( $done )
    $this->cleanup();
    return;

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

Style emacs

Dans emacs, en utilisant php-mode.el de nXHTML mode, vous pouvez définir un mode mineur MediaWiki dans votre fichier .emacs:

(defconst mw-style
  '((indent-tabs-mode . t)
    (tab-width . 4)
    (c-basic-offset . 4)
    (c-offsets-alist . ((case-label . +)
                        (arglist-cont-nonempty . +)
                        (arglist-close . 0)
                        (cpp-macro . (lambda(x) (cdr x)))
                        (comment-intro . 0)))
    (c-hanging-braces-alist
        (defun-open after)
        (block-open after)
        (defun-close))))

(c-add-style "MediaWiki" mw-style)

(define-minor-mode mah/mw-mode
  "tweak style for mediawiki"
  nil " MW" nil
  (delete-trailing-whitespace)
  (tabify (point-min) (point-max))
  (subword-mode 1)) ;; If this gives an error, try (c-subword-mode 1)), which is the earlier name for it

;; Add other sniffers as needed
(defun mah/sniff-php-style (filename)
  "Given a filename, provide a cons cell of
   (style-name . function)
where style-name is the style to use and function
sets the minor-mode"
  (cond ((string-match "/\\(mw[^/]*\\|mediawiki\\)/"
                       filename)
         (cons "MediaWiki" 'mah/mw-mode))
        (t
         (cons "cc-mode" (lambda (n) t)))))

(add-hook 'php-mode-hook (lambda () (let ((ans (when (buffer-file-name)
                                                 (mah/sniff-php-style (buffer-file-name)))))
                                      (c-set-style (car ans))
                                      (funcall (cdr ans) 1))))

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

Manipulation des données

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 Linker ou de Title en PHP, le mot magique fullurl dan sle 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.[1] 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, Title.php ne contient que la classe Title ; WebRequest.php contient la classe WebRequest , avec ses descendants: FauxRequest et DerivativeRequest.

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 index.php et foobar.sql, 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 mediawiki.foo peut avoir les fichiers resources/src/mediawiki.foo/bar.js et resources/src/mediawiki.foo/baz.css
  • le module mediawiki.Title a le fichier resources/src/mediawiki.Title.js

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

  • extensions/FooBar/resources/ext.fooBar/init.js

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.

Certains éléments de MediaWiki sont documentés dans /docs folder. Par exemple, si vous ajoutez une nouvelle accroche, vous devez mettre à jour /docs/hooks.txt avec le nom de l'accroche, une description de ce que fait l'accroche, et les paramètres utilisés par l'accroche.

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 {{git file}}.

(La possibilité de transclure du texte à partir des fichiers Git vers l'intérieur des pages wiki est répertoriée dans phab: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

.wiki
Si votre texte est du texte wiki, donnez lui une extension .wiki . GitHub peut analyser une partie du texte wiki, donc les fichers foo.wiki en miroir sur GitHub vont afficher un certain formatage (une extension .mediawiki fonctionne aussi, mais elle est plus longue). Par exemple, le docs/lua.wiki de l'extension Wikibase dans GitHub.


.md
Doxygen prend en charge le formatage Markdown, donc vous pouvez mettre de la documentation formatée simplement dans les fichiers .md. Diffusion et GitHub supportent les fichiers .md . Nommez le fichier d'explication d'un répertoire ou d'un projet README.md; Diffusion et GitHub vont montrer ce fichier quand vous afficherez ce répertoire ou ce projet (par exemple doc/development/ de RESTbase, dans Diffusion et dans GitHub).
sans extension et .txt
Doxygen par défaut les analyse comme des fichiers C (!!, référencé dans tâche T106116). Vous pouvez profiter de cela en simulant un commentaire C pour le fichier, puis en y ajoutant des directives Doxygen. Par exemple, includes/filebackend/README génère l'Architecture des fichiers serveur dans Doxygen, et commence avec:
/*!
\ingroup FileBackend
\page file_backend_design File backend design

Some notes on the FileBackend architecture.
...
Special:Version/Credits suppose que AUTHORS et CREDITS (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.

<?php
/**
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License along
 * with this program; if not, write to the Free Software Foundation, Inc.,
 * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 * http://www.gnu.org/copyleft/gpl.html
 * 
 * @file
 */

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 RELEASE-NOTES-N.NN . RELEASE-NOTES-1.35 est en développement; pour chaque version nous déplaçons les anciennes notes de diffusion dans le fichier HISTORY et nous en ouvront un nouveau. RELEASE-NOTES-N.NN 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, some-new-message est bien pour un nom, tandis que someNewMessage ou some_new_message 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 templatesused-section ne trouvera pas cette utilisation de clé de message si elle n'est pas entière.

// No:
return wfMessage( 'templatesused-' . ( $section ? 'section' : 'page' ) );

// Yes:
$msgKey = $section ? 'templatesused-section' : 'templatesused-page';
return wfMessage( $msgKey );

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

// Messages that can be used here:
// * myextension-connection-success
// * myextension-connection-warning
// * myextension-connection-error
$text = wfMessage( 'myextension-connection-' . $status )->parse();

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

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 :

  • data-ooui – Cet attribut est présent dans le HTML généré par les widgets OOUI.
  • data-parsoid – attribut réservé à usage interne pour Parsoid.
  • data-mw et data-mw-... – sont des attributs réservés à usage interne du coeur de MediaWiki, des habillages et des extensions. Le data-mw 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.

Notes

Liens externes