Manual:Coding conventions/cs

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. 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 tomu, aby byl kód opraven tak, aby byl v souladu s touto konvencí a oprava byla aktualizována.

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:



Na wikitech (platí alespoň pro operace / puppet):


 * Puppet

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 velikosti 8 mezer a někteří vývojáři zase pro změnu používají tabulátory o velikosti pouhé 2 mezery.

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
Když používáte IDE, stisknutím kláves Domů a Konec (mimo jiné klávesové zkratky) obvykle ignorujete koncové mezery a místo toho přeskočíte na konec určeného kódu. V textových editorech jiných než IDE však stisknutí tlačítka End přeskočí na úplný konec řádku, což znamená, že vývojář musí použít backspace přes koncové mezery, aby se dostal na místo, kam chce skutečně psát.

Odstranění koncové mezery je ve většině textových editorů triviální. Vývojáři by neměli přidávat koncové mezery, zejména ne na řádcích, které obsahují jiný viditelný kód.

Některé nástroje to usnadňují:


 * nano: GNU nano 3.2;
 * : v nabídce Možnosti uložení z nabídky „Úpravy> Předvolby“ povolte „Vymazat koncové mezery a značky EOL“ (Clean trailing whitespace and EOL markers) a „Pouze vyčistit změněné řádky“ (Only clean changed lines);
 * Kate: koncové mezery můžete vidět povolením možnosti „Zvýraznit koncové mezery“. Tuto možnost najdete v části „Nastavení > Konfigurovat Kate > Vzhled“. Můžete také zadat Kate, aby vyčistila koncové mezery při uložení v „Nastavení > Konfigurovat Kate> Otevřít nebo Uložit“.
 * vim: různé pluginy pro automatické čištění;
 * Sublime Text: TrailingSpaces plugin.

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

Obecný styl
Styl odsazení MediaWiki je podobný tzv. „One True Brace Style“. Zarážky jsou umístěny na stejném řádku jako začátek funkce, podmínka, smyčka atd. Jinak nebo jinde je umístěn na stejném řádku jako předchozí zavírací zarážka.

Víceřádkové příkazy se zapisují tak, že druhý a následující řádky jsou odsazeny o jednu úroveň navíc:

Použijte odsazení a konce řádků ke zvýraznění logické struktury vašeho kódu. Výrazy, které se vnořují do více úrovní závorek nebo podobných struktur, mohou začít novou úroveň odsazením s každou úrovní vnoření:

V příkazech pro přepínání odsazení v závorkách a mezi případy:

Vertikální zarovnání
Vyvarujte se vertikálního zarovnání pomocí tabulátorů. Má tendenci vytvářet rozdíly, které je obtížné interpretovat. Šířka povolená pro levý sloupec musí být neustále zvyšována, jakmile se přidává více položek.

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:

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

 $namespaceNames·=·[ → NS_MEDIA············=>·'Media', → NS_SPECIAL··········=>·'Special', → NS_MAIN·············=>·'', ]; (Pokud používáte doplněk tabular vim add-on, zadáním :Tabularize /= zarovnáte znaky '='.)

Zalomení řádků
Řá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.

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

Pokud pokračujete v příkazech „if“, přepnutí na složené závorky Allman-style jasně stanoví oddělení mezi podmínkou a tělem:

Názory se liší v rozsahu odsazení, které by mělo být použito pro podmíněnou část. Použití množství odsazení odlišného od toho, které používá tělo, objasňuje, že podmíněná část není tělem, ale toto není všeobecně podporováno.

Pokračování podmíněných a velmi dlouhých výrazů bývá ošklivé, ať už je děláte jakýmkoli způsobem. Proto je někdy nejlepší je rozdělit pomocí dočasných proměnných.

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.

Tím se zabrání běžné logické chybě, která je zvláště rozšířená, když vývojář používá textový editor, který nemá funkci „inteligentního odsazení“. K chybě dochází, když je jednořádkový blok později rozšířen na dva řádky:

Později změněno na:

To má potenciál vytvářet jemné chyby.

emacs styl
V emacs pomocí  od nXHTML mode, můžete nastavit menší režim MediaWiki v souboru .emacs:

Výše uvedená funkce  zkontroluje vaši cestu, když je vyvolán , aby zjistil, zda obsahuje „mw“ nebo „mediawiki“ a nastaví vyrovnávací paměť pro použití menšího režimu   pro úpravu zdroje MediaWiki. Že se vyrovnávací paměť  používá poznáte, protože v řádku režimu uvidíte něco jako „PHP MW“ nebo „PHP / lw MW“.

Vytváření adres URL
Nikdy nevytvářejte adresy URL ručně s řetězcovým zřetězením nebo podobným způsobem. Pro požadavky zadané vaším kódem vždy používejte plný formát URL (zejména POST a požadavky na pozadí).

V PHP můžete použít příslušnou metodu nebo, magické slovo  ve wikitextu, mw.util.getUrl metoda v JavaScriptu a podobné metody v jiných jazycích. You'll avoid issues with unexpected short URL configuration and more.

Pojmenování souboru
Soubory, které obsahují kód na straně serveru, by měly být pojmenovány v UpperCamelCase. Toto je také naše konvence pojmenování pro rozšíření. Pojmenujte soubor po nejdůležitější třídě. Většina souborů bude obsahovat pouze jednu třídu nebo základní třídu a řadu potomků. Například  obsahuje pouze třídu  ;   obsahuje třídu   a také její potomky   a.

Přístupové soubory
Pojmenujte soubory „přístupového bodu“, například SQL, a vstupní body PHP, například  a   v lowercase. Skripty pro údržbu jsou obvykle v lowerCamelCase i když se to poněkud liší. Soubory určené pro správce webu, jako jsou readmes, licence a changelogs, jsou obvykle v UPPERCASE.

Nikdy nezahrnujte mezery do názvů souborů nebo adresářů a nikdy nepoužívejte znaky jiné než ASCII. U titulů s malými písmeny jsou spojovníky upřednostňovány před podtržítky.

JS, CSS a mediální soubory
U souborů JavaScript, CSS a mediálních souborů (obvykle načtených pomocí ResourceLoader) by se pojmenování souborů mělo shodovat s pojmenováním modulů. Například:
 * Modul  může obsahovat soubory   a
 * modul  obsahuje soubor

Názvy modulů zaregistrovaných pomocí rozšíření by měly následovat název jako, například:

Díky tomu je snadné najít soubory, i když modul rozdělíte na menší soubory, abyste je mohli pohodlně upravovat, a pak je spojíte do jednoho modulu.

Dokumentace
Dílčí stránky specifické pro jazyk mají více informací o přesné syntaxi kódových komentářů v souborech, např. komentáře v PHP pro doxygen. Použití přesné syntaxe nám umožňuje generovat dokumentaci ze zdrojového kódu na adrese http://doc.wikimedia.org.

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

Textové soubory
Vývojáři mohou uchovávat soubory dokumentace v Gitu vedle kódu. Může to být užitečné pro podrobnou dokumentaci architektury rozšíření, návrhu databáze atd., kterou byste měli aktualizovat s každým kódem, který změní chování. Stránky na mediawiki.org, které se týkají dokumentace v Gitu, by na ni měly odkazovat pomocí.

(Možnost převést text ze souborů Git na stránky wiki je sledována v T91626.)

Mnoho stránek technické dokumentace na stránkách mediawiki.org dokumentuje vývoj kódu MediaWiki v mnoha vydáních. Popište změny v dokumentu nebo uveďte, že popisuje pouze poslední kódovou základnu v „master“.

Formáty textových souborů

 * Pokud je váš textový soubor wikitext, zadejte příponu . GitHub umí analyzovat podmnožinu wikitextu, takže   soubory zrcadlené na GitHubu budou zobrazovat určité formátování (rozšíření   také funguje, ale je delší) . Například   rozšíření Wikibase v GitHub.
 * Pokud je váš textový soubor wikitext, zadejte příponu . GitHub umí analyzovat podmnožinu wikitextu, takže   soubory zrcadlené na GitHubu budou zobrazovat určité formátování (rozšíření   také funguje, ale je delší) . Například   rozšíření Wikibase v GitHub.


 * Doxygen [$mdurl podporuje formátování Markdown], takže můžete do souborů  vkládat lehce formátovanou dokumentaci. Diffusion a GitHub také podporují soubory  . Název vysvětlujícího souboru pro adresář nebo projekt  . Aplikace Diffusion a GitHub zobrazí tento soubor při prohlížení tohoto adresáře nebo projektu (např. RESTbase $path, v $Git a na $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 podporuje formátování Markdown], takže můžete do souborů  vkládat lehce formátovanou dokumentaci. Diffusion a GitHub také podporují soubory  . Název vysvětlujícího souboru pro adresář nebo projekt  . Aplikace Diffusion a GitHub zobrazí tento soubor při prohlížení tohoto adresáře nebo projektu (např. RESTbase $path, v $Git a na $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 podporuje formátování Markdown], takže můžete do souborů  vkládat lehce formátovanou dokumentaci. Diffusion a GitHub také podporují soubory  . Název vysvětlujícího souboru pro adresář nebo projekt  . Aplikace Diffusion a GitHub zobrazí tento soubor při prohlížení tohoto adresáře nebo projektu (např. RESTbase $path, v $Git a na $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).


 * bez přípony a
 * Doxygen je standardně analyzuje jako soubory jazyka C (!!, sledované v ). Toho můžete využít tak, že soubor napodobuje komentář C a poté do souboru přidáte doxygenové směrnice. Například vygeneruje Návrh backendového souboru v doxygenu a začíná:




 * Special:Version/Credits předpokládá, že  a   (bez přípony) jsou soubory wikitext.

Záhlaví zdrojových souborů
Aby bylo možné vyhovět většině licencí, měli byste mít v horní části každého zdrojového souboru něco podobného následujícímu (specifické pro aplikace GPLv2 PHP).

Licence
Licence se obecně označují celým svým jménem nebo zkratkou podle SPDX standard. Viz také Návod: $wgExtensionCredits#license.

Poznámky k vydání
Musíte dokumentovat všechny významné změny (včetně all fixed bug reports) do základního softwaru, který by mohl ovlivnit uživatele wiki, správce serverů, autory rozšíření v. se vyvíjí. Při každém vydání přesuneme předchozí poznámky k vydání do souboru  a začneme znovu. je obecně rozdělena do tří sekcí:


 * Změny konfigurace (Configuration changes) je místo, kde můžete dát změny do akceptovaného výchozího chování, zpětně nekompatibilních změn nebo jiných věcí, které potřebuje správce serveru, aby se na ně podíval, a rozhodnul zda "je tato změna pro moji wiki vhodná?". Pokuste se zahrnout stručné vysvětlení toho, jak lze předchozí funkci v případě potřeby obnovit.
 * Opravy chyb (Bug fixes) je místo, kde lze zaznamenat změny, které opravují chování, které je považováno za problematické nebo nežádoucí. Často se jedná o problémy hlášené v Phabricator, ale nemusí to nutně být.
 * Nové funkce (New features') dává na vědomí přidání nových funkcí.

Mohou existovat další oddíly pro konkrétní komponenty (např. Action API) nebo pro různé změny, které nespadají do jedné z výše uvedených kategorií.

Ve všech případech, pokud vaše změna je odpovědí na jeden nebo více problémů hlášených v programu Phabricator, uveďte ID úlohy na začátek záznamu. Doplnit nové položky v chronologickém pořadí na konci oddílu.

Systémové zprávy
Při vytváření nové systémové zprávy, pokud je to možné, použijte pomlčky (-) místo CamelCase nebo snake_case. Například  je správné jméno, zatímco   a   jsou špatně.

Pokud se zpráva použije jako štítek, který může mít dvojtečku na konci, dvojtečku netiskněte. Místo toho vložte dvojtečku do textu zprávy. Některé jazyky (např. Francouzština, které nejdříve potřebují mezeru) musí zpracovat dvojtečky jiným způsobem, což je nemožné, pokud je dvojtečka pevně zakódována. Totéž platí pro několik dalších typů interpunkce.

Zkuste použít kódy zpráv „celé“ v kódu, spíše než je stavět za chodu; protože to usnadňuje jejich vyhledávání v kódové základně. Následující příklad například ukazuje, jak hledání  nenajde toto použití klíče zpráv, pokud není použit jako celek.

Pokud máte pocit, že musíte vytvářet zprávy za chodu, vložte komentář se všemi možnými celými zprávami v okolí:

Další konvence o vytváření, používání, dokumentování a údržbě klíčů zpráv viz Lokalizace.

Preferované hláskování
Stejně tak důležité je mít konzistentní pravopis v uživatelském rozhraní a v kódové základně. Stejně jako mít konzistentní uživatelské rozhraní. Podle dlouhé historie je 'americká angličtina' preferovaným hláskováním pro zprávy, komentáře a dokumentaci v anglickém jazyce.

Zkratky v klávesách pro zprávy

 * ph
 * zástupný symbol (text ve vstupních polích)


 * tip
 * popis textu


 * tog-xx
 * přepínání možností v uživatelských předvolbách

Interpunkce
Chybové zprávy bez názvu jsou považovány za věty a měly by obsahovat interpunkci.

Vylepšení jádra
Pokud potřebujete nějakou další funkcionalitu z jádrové komponenty MediaWiki (třída PHP, modul JS atd.), Nebo pokud potřebujete funkci, která dělá něco podobného, ale mírně odlišného, upřednostňujte vylepšení základní komponenty. Vyhněte se duplikování kódu na příponu nebo jinde v jádru a tam jej neupravujte.

Refactoring
Kód refaktoru při provádění změn: nedovolte, aby se kód při každé změně zhoršoval.

Pokud je však refaktoring velký, použijte samostatné potvrzení. Viz také Pokyny pro architekturu (pracovní verze).

HTML
MediaWiki HTTP odešle výstup HTML, který lze vygenerovat jedním ze dvou zdrojů. PHP kód MediaWiki je důvěryhodným zdrojem uživatelského rozhraní. Může vydávat libovolný HTML. Analyzátor převádí wikitext generovaný uživatelem do HTML. Jedná se o nedůvěryhodný zdroj. Složité HTML vytvořené uživateli pomocí wikitextu se často nachází v oboru názvů „Template“. HTML vytvořené analyzátorem je před výstupem vyčištěno.

Většinu datových atributů mohou uživatelé používat ve wikitextu a šablonách. Následující předpony však byly omezeny a ve wikitextu nejsou povoleny. To umožňuje klientskému kódu JavaScript určit, zda prvek DOM pochází z důvěryhodného zdroje:


 * - Tento atribut je přítomen v HTML generovaném widgety OOUI.
 * – rezervovaný atribut pro interní použití společností Parsoid.
 * and  – vyhrazený atribut pro vnitřní použití jádrem, vzhledy a rozšířeními MediaWiki.     je také používán Parsoidem.

Při výběru prvků v JavaScriptu lze určit klíč nebo hodnotu atributu, aby bylo zajištěno, že budou brány v úvahu pouze prvky DOM ze zamýšleného důvěryhodného zdroje. Příklad: Only trigger 'wikipage.diff' hook for official diffs.

Externí odkazy

 * Nástroje ve stylu kódu