Manual:Coding conventions/fr

This page describes the coding conventions used within the MediaWiki codebase and extensions which are intended for use on Wikimedia websites, including appropriate naming conventions. Changes that do not comply with these conventions may be summarily -1'ed by code reviewers; this should be considered an invitation to fix the stylistic issues and update the patch.

This page lists general conventions that apply to all MediaWiki code, whatever language it is written in. For guidelines that apply to specific components or file types in MediaWiki, see:



On wikitech (applies at least to operations/puppet):


 * Puppet

Tab size
Lines should be indented with a single tab character per indenting level. You should make no assumptions about the number of spaces per tab. Most MediaWiki developers find 4 spaces per tab to be best for readability, but many systems are configured to use 8 spaces per tab and some developers might use 2 spaces per tab.

For vim users, one way to establish these settings is to add the following to $HOME/.vimrc:

autocmd Filetype php setlocal ts=4 sw=4

avec des lignes semblables pour css, html et javascript.

However, for Python, instead follow the whitespace guidelines from PEP 8, which recommends spaces for new projects.

Nouvelles lignes
All files should use Unix-style newlines (single LF character, not a CR+LF combination).


 * git on Windows will (by default) convert CR+LF newlines to LF during committing.

All files should have a newline at the end.


 * It makes sense since all other lines have a newline character at the end.
 * It makes passing data around in non-binary formats (like diffs) easier.
 * Command-line tools like cat and wc don't handle files without one well (or at least, not in the way that one would like or expect).

Encoding
All text files must be encoded with UTF-8 without a Byte Order Mark.

Do not use Microsoft Notepad to edit files, as it always inserts a BOM. A BOM will stop PHP files from working since it is a special character at the very top of the file and will be output by the web browser to the client.

In short, make sure your editor supports UTF-8 without BOM.

Trailing whitespace
When using an IDE, pressing the Home and End keys (among other keyboard shortcuts) usually ignores trailing whitespace and instead jumps to the end of the code, which is intended. In non-IDE text editors, though, pressing End will jump to the very end of the line, which means the developer must backspace through the trailing whitespace to get to the spot where they actually want to type.

Removing trailing whitespace is a trivial operation in most text editors. Developers should avoid adding trailing whitespace, primarily on lines that contain other visible code.

Some tools make it easier:


 * nano: craigbarnes/nanorc;
 * Komodo Edit: in the Save Options from menu "Edit > Preferences", enable "Clean trailing whitespace and EOL markers" and "Only clean changed lines";
 * Kate: you can see trailing spaces by enabling the option "Highlight trailing spaces". This option can be found in "Settings > Configure Kate > Appearance". You can also tell Kate to cleanup trailing spaces on save in "Settings > Configure Kate > Open/Save".
 * vim: various automatic cleanup plugins;
 * sublime: sublime.

Keywords
Do not use parentheses with keywords (e.g.,  ) where they are not necessary.

General style
MediaWiki's indenting style is similar to the so-called "One True Brace Style". Braces are placed on the same line as the start of the function, conditional, loop, etc. The else/elseif is placed on the same line as the previous closing brace.

Multi-line statements are written with the second and subsequent lines being indented by one extra level:

Use indenting and line breaks to clarify the logical structure of your code. Expressions which nest multiple levels of parentheses or similar structures may begin a new indenting level with each nesting level:

There are some exceptions, such as switch statements, where the indentation of the cases are optional, so both of the below are fine.

Vertical alignment
Avoid vertical alignment. It tends to create diffs which are hard to interpret, since the width allowed for the left column constantly has to be increased as more items are added.

When needed, create mid-line vertical alignment with spaces rather than tabs. For instance this:

Is achieved as follows with spaces rendered as dots:

 $namespaceNames·=·array( → NS_MEDIA············=>·'Media', →  NS_SPECIAL··········=>·'Special', →  NS_MAIN·············=>·'', ); (If you use the tabular vim add-on, entering :Tabularize /= will align the '=' signs.)

Line continuation
Lines should be broken at between 80 and 100 columns. There are some rare exceptions to this. Functions which take lots of parameters are not exceptions.

The operator separating the two lines should be placed at the end of the preceding line.

When continuing "if" statements, a switch to Allman-style braces makes the separation between the condition and the body clear:

Opinions differ on the amount of indentation that should be used for the conditional part. Using an amount of indentation different to that used by the body makes it more clear that the conditional part is not the body, but this is not universally observed.

Continuation of conditionals and very long expressions tend to be ugly whichever way you do them. So it's sometimes best to break them up by means of temporary variables.

Braceless control structures
Do not write "blocks" as a single-line. They reduce the readability of the code by moving important statements away from the left margin, where the reader is looking for them. Remember that making code shorter doesn't make it simpler. The goal of coding style is to communicate effectively with humans, not to fit computer-readable text into a small space.

This avoids a common logic error, which is especially prevalent when the developer is using a text editor which does not have a "smart indenting" feature. The error occurs when a single-line block is later extended to two lines:

Later changed to:

This has the potential to create subtle bugs.

emacs style
In emacs, using  from nXHTML mode, you can set up a MediaWiki minor mode in your .emacs file:

The above  function will check your path when   is invoked to see if it contains “mw” or “mediawiki” and set the buffer to use the   minor mode for editing MediaWiki source. You will know that the buffer is using  because you'll see something like “PHP MW” or “PHP/lw MW” in the mode line.

eclipse style
There is an eclipse plugin called PDT Extensions that is helpful for formatting the code. A formatting template can be downloaded here.

Constructing URLs
Never build URLs manually with string concatenation or similar. Always use the full URL format for requests made by your code (especially POST and background requests).

You can use the appropriate or  method in PHP, the  magic word in wikitext, the mw.util.getURL method in JavaScript, and similar methods in other languages. You'll avoid issues with unexpected short URL configuration and more.

File naming
Files which contain server-side code should be named in UpperCamelCase. This is also our naming convention for extensions. Name the file after the most important class it contains; most files will contain only one class, or a base class and a number of descendants. For example,  contains only the  class;  contains the   class, and also its descendants   and.

Name "access point" files, such as SQL, and PHP entry points such as index.php and foobar.sql, in lowercase. Maintenance scripts are generally in lowerCamelCase, although this varies somewhat. Files intended for the site administrator, such as readmes, licenses and changelogs, are usually in UPPERCASE.

Never include spaces in file names or directories, and never use non-ASCII characters. For lowercase titles, hyphens are preferred to underscores.

For JavaScript, CSS and media files (usually loaded via ResourceLoader) file naming should match module naming. For example:
 * module  might have files resources/src/mediawiki.foo/mediawiki.foo.js and resources/src/mediawiki.foo/mediawiki.foo.css
 * module  has file resources/src/mediawiki/mediawiki.Title.js

JS and CSS files for extensions usually use a name like ext.myExtension</tt>, for instance:
 * extensions/FooBar/resources/ext.fooBar/ext.fooBar.init.js</tt>

This keeps it easy to find things, even if you divide up a module into smaller files for editing convenience and then bundle them together into a single module.

Groups of modules should have their files also grouped in directories. For example, there are several modules related to. All those module files start with jquery.</tt> and are stored in the resources/lib/jquery</tt> directory.

Documentation
The language-specific subpages have more information on the exact syntax for code comments in files, e.g. comments in PHP for doxygen. Using precise syntax allows us to generate documentation from source code at http://doc.wikimedia.org.

Some elements of MediaWiki are documented in core's. For instance, if you add a new hook, you should update with the name of the hook, a description of what the hook does, and the parameters used by the hook.

Text files
Developers can keep documentation files in Git alongside code. This can be good for detailed documentation of extension architecture, database design, etc. that you should update with each code commit that changes behavior. Pages on mediawiki.org that relate to documentation in Git should link to it using.

(The possibility to transclude text from Git files into wiki pages is tracked in T91626.)

Note that many technical documentation pages on mediawiki.org pages document the evolution of MediaWiki code over many releases. Either describe changes in your document or state it only describes the latest codebase in "master".

Text file formats

 * .wiki</tt>
 * If your text file is wikitext, give it a .wiki</tt> extension. GitHub can parse a subset of wikitext, so foo.wiki</tt> files mirrored on GitHub will display some formatting (a .mediawiki</tt> extension also works, but is longer). For example, the Wikibase extension's docs/lua.wiki</tt> in GitHub.


 * .md</tt>
 * Doxygen supports Markdown formatting, so you can put lightly-formatted documentation in .md</tt> files. Diffusion and GitHub also support .md</tt> files. Name the explanatory file for a directory or project README.md</tt>; Diffusion and GitHub will display this file when you view that directory or project (e.g. RESTbase's doc/development/, in and on GitHub).


 * no extension and .txt</tt>
 * Doxygen by default parses these as C language files (!!, tracked in ). You can take advantage of this by making the file mimic a C comment, and then add doxygen directives to the file. For example, generates File backend design in doxygen, and begins with:




 * Special:Version/Credits assumes <tt>AUTHORS</tt> and <tt>CREDITS</tt> (with no extension) are wikitext files.

Source file headers
In order to be compliant with most licenses you should have something similar to the following (specific to GPLv2 PHP applications) at the top of every source file.

Licenses
Licenses are generally referred to by their full name or acronym as per SPDX standard. See also Manual:$wgExtensionCredits#license.

Release notes
You must document all significant changes (including all fixed bug reports) to the core software which might affect wiki users, server administrators, or extension authors in the <tt>RELEASE-NOTES-N.NN</tt> file. <tt></tt> is in development; on every release we move the past release notes into the <tt></tt> file and start afresh. <tt>RELEASE-NOTES-N.NN</tt> is generally divided into three sections:


 * Configuration changes is the place to put changes to accepted default behavior, backwards-incompatible changes, or other things which need a server administrator to look at and decide "is this change right for my wiki?". Try to include a brief explanation of how the previous functionality can be recovered if desired.
 * Bug fixes is the place to note changes which fix behavior which is accepted to be problematic or undesirable. These will often be issues reported in Phabricator, but needn't necessarily.
 * New features is, unsurprisingly, to note the addition of new functionality.

There may be additional sections for specific components (e.g. the Action API) or for miscellaneous changes that don't fall into one of the above categories.

In all cases, if your change is in response to one or more issues reported in Phabricator, include the task ID(s) at the start of the entry. Add new entries in chronological order at the end of the section.

System messages
When creating a new system message, use hyphens (-) where possible instead of CamelCase or snake_case. So for example,  is a good name, while   and   are not.

If the message is going to be used as a label which can have a colon after it, don't hardcode the colon; instead, put the colon inside the message text. Some languages (such as French which require a space before) need to handle colons in a different way, which is impossible if the colon is hardcoded. The same holds for several other types of interpunctuation.

Try to use message keys "whole" in code, rather than building them on the fly; as this makes it easier to search for them in the codebase. For instance, the following shows how a search for  will not find this use of the message key if they are not used as a whole.

If you feel that you have to build messages on the fly, put a comment with all possible whole messages nearby:

See Localisation for more conventions about creating, using, documenting and maintaining message keys.

Preferred spelling
It is just as important to have consistent spelling in the UI and codebase as it is to have consistent UI. By long standing history, 'American English' is the preferred spelling for English language messages, comments, and documentation.

Abbreviations in message keys

 * ph
 * placeholder (text in input fields)


 * tip
 * tooltip text


 * tog-xx
 * toggle options in user preferences

Punctuation
Non-title error messages are considered as sentences and should have punctuation.

ResourceLoader
Module names should match the main definition of the scripts they load. For example a module defining the  object is named "mediawiki.util" and the module for the   object constructor is named "mediawiki.Title".

Core modules
If you need some additional functionality of a core module (or you need a function that does something similar but a different), actually improve the core module. Don't just copy+paste and modify the code in another place.

Refactoring
Refactor code as changes are made: don't let the code keep getting worse with each change.

However, use separate commits if the refactoring is large. See also Architecture guidelines (draft).

Liens externes

 * Code style tools