Open main menu

Manuál:Konvence pro psaní kódu

This page is a translated version of the page Manual:Coding conventions and the translation is 30% complete.

Other languages:
English • ‎dansk • ‎español • ‎français • ‎polski • ‎português • ‎português do Brasil • ‎čeština • ‎русский • ‎العربية • ‎تۆرکجه • ‎සිංහල • ‎中文 • ‎日本語
shortcut: CC

Tato stránka popisuje konvence pro psaní kódu se kterým pracuje MediaWiki a její rozšíření, s nimiž se můžete setkat na webových stránkách projektů Wikimedie, a to včetně konvence pro tvorbu jmen. Úpravám, které nebudou v souladu s touto konvencí, revidenti kódu dají v hodnocení -1; což lze automaticky brát jako výzvu k k tomu, aby byl kód opraven tak, aby byl v souladu s touto konvencí a patch aktualizován.

Tato stránka popisuje všeobecnou konvenci pro psaní kódu, která se týká veškerého kódu MediaWiki, bez ohledu na programovací jazyk. Pro další pokyny, které se týkají konkrétních komponent či typů souborů v MediaWiki, viz:

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

Struktura kódu

Formátování

Odsazení

Řádky mohou být odsazeny znakem tabulátor (tab), pro každou úroveň zanoření. Pokud jde o velikost odsazení tabulátoru co do počtu mezer, tak většina vývojářů MediaWiki používá u svých editorů pro interpretaci tabulátoru 4 mezery, což je optimální pro čtení, ale řada systémů předpokládá, že má tabulátor o velikost 8 mezer a někteří vývojáři zase pro změnu používají tabulátory o velikosti pouhých 2 mezer.

Uživatelé editoru vim si mohou velikost tabulátoru nastavit tak, že přidají do $HOME/.vimrc následující kód:

autocmd Filetype php setlocal ts=4 sw=4

řádky s nastavením pro CSS, HTML a JavaScript vypadají podobně.

Nicméně v případě Pythonu je podle PEP 8 lepší používat místo tabulátoru mezery.

Konce řádků

Všechny soubory by měly používat unixové konce řádků, t.j. jeden znak LF (line feed - zalomení řádku). Tedy žádnou kombinaci znaků CR (carriage return - návrat vozíku) + LF.

  • git v prostředí Windows (by default) převádí znaky CR+LF (které označují konce řádku v prostředí tohoto systému) na LF při ukládání změn (commit).

Všechny soubory by měly končit prázdným řádkem.

  • Protože je logické, aby všechny řádky končily stejně – znakem zalomení řádku.
  • Jednotné zakončení řádku usnadňuje také předávání dat v jiných než binárních formátech (např. formou rozdílových souborů generovaných přes diff).
  • Pokud se vyskytují v souborech různé typy konce řádku, tak nástroje pro příkazovou řádku, jako např. cat nebo wc nefungují tak, jak by měly.

Kódování

Všechny texty musí být v UTF-8 bez znaku BOM.

Nepoužívejte k editaci souborů Microsoft Notepad, protože ten do nich vždy nacpe BOM. BOM je speciální znak na začátku souboru, na kterém PHP přeruší další zpracování souboru, takže se do webového prohlížeče na straně klienta dostane pouze tento znak.

Stručně řečeno, ujistěte se, že váš editor podporuje UTF-8 bez BOM.

Mezery na konci řádku

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: GNU nano 3.2;
  • 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 Text: TrailingSpaces plugin.

Klíčová slova

Nepoužívejte závorky s klíčovými slovy (jako např. require_once, require), pokud to není nezbytně nutné.

Odsazování a zarovnání

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.

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

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:

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

In switch statements indent within the braces and between cases:

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

Vertikální zarovnání

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.

Většina nástrojů, co umí generovat rozdílové soubory nabízí volbu, která umožňuje ignorovat změny v počtu mezer.
Git: git diff -w

Pokud potřebujete, použijte pro vertikální zarovnání položek raději mezery, než tabulátory. Zarovnání jako u tohoto příkladu:

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

Dosáhnete takto (mezery jsou vykresleny jako tečky):

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

(If you use the tabular vim add-on, entering :Tabularize /= will align the '=' signs.)

Zalomení řádky

Řádky by měly být zalomeny mezi 80 a 100 sloupcem. Z tohoto pravidla existují vzácné výjimky. Ale funkce, kterým se předává hodně parametrů, mezi ně rozhodně nepatří.

Operátor který je rozdělen na dva řádky byste měli umisťovat pokud možno konzistentně (pokaždé buď na konci řádku, nebo naopak pokaždé na začátku řádku). I když některé jazyky pro to mohou mít svá vlastní, specifická pravidla.

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'
);

Operátor metody by vždycky měl být umístěn na začátku dalšího řádku.

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

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

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'
) {
    ..
}

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.

Závorky diktují strukturu

I když se vám to může zdát efektivnější, vyvarujte se u podmínek a funkcí psaní jednořádkových "bloků" kódu. Zhoršuje to přehlednost kódu. Důležité příkazy se tím dostávají na pozice, kde je lze při čtení kódu snadno přehlédnout. Uvědomte si, že cílem není získat naňahňaný minimalistický kód. Při psaní kódu byste měli především brát ohled na to, abyste v maximální míře usnadnili čtení kódu, tak aby mu porozuměli i ostatní vývojáři.

// No:
if ( $done ) return;

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

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

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:

if ( $done )
    return;

Later changed to:

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

This has the potential to create subtle bugs.

emacs style

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

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

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

Data manipulation

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 Linker or Title method in PHP, the fullurl 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.[1] 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, Title.php contains only the Title class; WebRequest.php contains the WebRequest class, and also its descendants FauxRequest and DerivativeRequest.

Access point files

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.

JS, CSS, and media files

For JavaScript, CSS and media files (usually loaded via ResourceLoader) file naming should match module naming. For example:

  • Module mediawiki.foo might have files resources/src/mediawiki.foo/bar.js and resources/src/mediawiki.foo/baz.css
  • module mediawiki.Title has file resources/src/mediawiki.Title.js

Modules names registered by extensions should follow name like ext.myExtension, for instance:

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

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

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 /docs folder. For instance, if you add a new hook, you should update /docs/hooks.txt 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 {{git file}}.

(The possibility to transclude text from Git files into wiki pages is tracked in phab: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
If your text file is wikitext, give it a .wiki extension. GitHub can parse a subset of wikitext, so foo.wiki files mirrored on GitHub will display some formatting (a .mediawiki extension also works, but is longer). For example, the Wikibase extension's docs/lua.wiki in GitHub.


.md
Doxygen supports Markdown formatting, so you can put lightly-formatted documentation in .md files. Diffusion and GitHub also support .md files. Name the explanatory file for a directory or project README.md; Diffusion and GitHub will display this file when you view that directory or project (e.g. RESTbase's doc/development/, in Diffusion and on GitHub).
no extension and .txt
Doxygen by default parses these as C language files (!!, tracked in task T106116). You can take advantage of this by making the file mimic a C comment, and then add doxygen directives to the file. For example, includes/filebackend/README generates File backend design in doxygen, and begins with:
/*!
\ingroup FileBackend
\page file_backend_design File backend design

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

<?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
 */

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 RELEASE-NOTES-N.NN file. RELEASE-NOTES-1.35 is in development; on every release we move the past release notes into the HISTORY file and start afresh. RELEASE-NOTES-N.NN 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, some-new-message is a good name, while someNewMessage and some_new_message 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 templatesused-section will not find this use of the message key if they are not used as a whole.

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

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

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

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

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.

Improve the core

If you need some additional functionality from a MediaWiki core component (PHP class, JS module etc.), or you need a function that does something similar but slightly different, prefer to improve the core component. Avoid duplicating the code to an extension or elsewhere in core and modifying it there.

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

HTML

MediaWiki HTTP responses output HTML that can be generated by one of two sources. The MediaWiki PHP code is a trusted source for the user interface, it can output any arbitrary HTML. The Parser converts user-generated wikitext into HTML, this is an untrusted source. Complex HTML created by users via wikitext is often found in the "Template" namespace. HTML produced by the Parser is subject to sanitization before output.

Most data attributes are allowed to be used by users in wikitext and templates. But, the following prefixes have been restricted and are not allowed in wikitext. This enables client JavaScript code to determine whether a DOM element came from a trusted source:

  • data-ooui – This attribute is present in HTML generated by OOUI widgets.
  • data-parsoid – reserved attribute for internal use by Parsoid.
  • data-mw and data-mw-... – reserved attribute for internal use by MediaWiki core, skins and extensions. The data-mw is also used by Parsoid.

When selecting elements in JavaScript, one can specify an attribute key/value to ensure only DOM elements from the intended trusted source are considered. Example: Only trigger 'wikipage.diff' hook for official diffs.

Notes

External links