Manual:Coding conventions/cs

Tato stránka popisuje pravidla 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ě pravidel pro tvorbu pojmenování. Úpravám, které nebudou v souladu s těmito pravidly, kontroloři 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 těmito pravidly a oprava byla aktualizována.

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



Na wikitech (platí alespoň pro provozní nebo hrané):


 * Puppet



Struktura kódu


Formáty souboru


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í. Řada systémů ale předpokládá, že má tabulátor velikost 8 mezer. 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. pouze 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 přidá 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ů (Home) a Konec (End) (mimo jiné klávesové zkratky) obvykle nevšímáte si koncových mezer 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čí kurzorem 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ů jednoduché. 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 (Save Options) uložení z nabídky "Úpravy> Předvolby" (Edit > Preferences) 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" (Highlight trailing spaces). Tuto možnost najdete v části "Nastavení > Konfigurovat Kate > Vzhled" (Settings > Configure Kate > Appearance). Můžete také zadat Kate, aby vyčistila koncové mezery při uložení v "Nastavení > Konfigurovat Kate> Otevřít nebo Uložit" (Settings > Configure Kate > Open/Save).
 * vim: různé pluginy pro automatické čištění;
 * Sublime Text: TrailingSpaces plugin.

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



Odsazování a zarovnání


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. rozhodovací znaky (else nebo elseif) jsou umístěny 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í:



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

Pokud potřebujete, použijte pro vertikální zarovnání položek raději mezery, než tabulátory. Použijte 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 '='.)



Šířka čáry
Řádky by měly být přerušovány mezi 80 až 100 sloupci. Existuje několik vzácných výjimek. Funkce, které přebírají mnoho parametrů, nejsou výjimkou. Myšlenka je, že kód by neměl přetékat z obrazovky, pokud je zalamování slov vypnuto.

Operátor který je rozdělen na dva řádky byste měli umisťovat pokud možno jednotně (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í jiného odsazení odlišného od toho, jaké používá tělo, objasňuje, že podmíněná část není tělem. Toto ale 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, kdy 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á, pokud 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 (textový editor) pomocí  od  nXHTML mode, můžete nastavit menší režim MediaWiki v souboru  :

Výše uvedená funkce  zkontroluje vaši cestu, pokud 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 používá vyrovnávací paměť  poznáte, protože v řádku režimu uvidíte něco jako "PHP MW" nebo "PHP / lw MW".



Manipulace s údaji


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 metodu v JavaScriptu a podobné metody v jiných jazycích. Vyhnete se nejen problémům s neočekávanou krátkou konfigurací URL ale i dalším.



Pojmenování souboru
Soubory, které obsahují kód na straně serveru, by měly být pojmenovány v UpperCamelCase (první písmeno každého slova je ve složeném slově velké). 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. 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.



Přístupové soubory
Pojmenujte soubory "přístupového bodu" (například SQL) a vstupní body PHP (například  a  ) v lowerCase (každé slovo ve složeném slově je psáno velkými písmeny, s výjimkou prvního slova). 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 (napsané velkými písmeny).

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 (nachází hned vedle pravého Shiftu. Na jeho klávese jsou celkem čtyři znaky: náš spojovník (-), podtržítko (_), otazník (?) a lomeno (/)) upřednostňovány před podtržítky.

<span id="JS,_CSS,_and_media_files">

JS, CSS a mediální soubory
V případě JavaScriptu by CSS a další soubory frontend (obvykle načtené prostřednictvím ResourceLoader) měly být umístěny v adresáři pojmenovaném podle modulu, ve kterém jsou registrovány. Například. modul  může obsahovat soubory   a.

Jména souborů JavaScript, které definují třídy, by měla přesně odpovídat názvu třídy, kterou definují. Třída  by měla být v souboru pojmenovaném jako   nebo s koncovkou. To umožňuje rychlou navigaci v textových editorech tím, že přejdete k souborům pojmenovaným podle názvu vybrané třídy (například "Goto Anything [P]" (Přejít na cokoli) v Sublime nebo "Find File [P]" (Najít soubor) v Atomu).

Velké projekty mohou mít třídy v souladu s názvy, které by se překrývaly nebo byly nejednoznačné bez nějakého dalšího způsobu organizace souborů. Obecně k tomu přistupujeme pomocí podadresářů, jako je  (pro soubory balíčků), nebo delší názvy tříd a souborů jako   v.

Balíčky modulů registrované příponami by měly mít názvy jako, například. Díky tomu je snadné začít pracovat na modulu v textovém editoru přímým vyhledáním souborů zdrojového kódu pouze z veřejného názvu modulu (T193826).

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ých pravidel pro jazyk nám umožňuje vytvářet dokumentaci ze zdrojového kódu na adrese https://doc.wikimedia.org.

Koncepty, subsystémy a datové toky na vysoké úrovni by měly být dokumentovány ve složce.

<span id="Source_file_headers">

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.

<span id="Dynamic_identifiers">

Dynamické identifikátory
Obecně se doporučuje vyhýbat se dynamickému vytváření identifikátorů, jako jsou klíče zpráv rozhraní, názvy tříd CSS nebo názvy souborů. Pokud je to možné, zapište je a vyberte mezi nimi (např. pomocí podmíněného, trojčlenného nebo přepínače výběru). To zlepšuje stabilitu kódu a produktivitu vývojářů prostřednictvím: snadnější kontroly kódu, vyšší spolehlivosti při ladění, zjišťování použití, git-grep, Codesearch atd.

Pokud je kód považován za lepší odraz logické struktury nebo pokud je požadováno, aby byl plně variabilní, můžete místo toho zřetězit identifikátor s proměnnou. V takovém případě musíte poblíž zanechat komentář s možnými (nebo nejběžnějšími) hodnotami, které demonstrují chování a napomáhají hledání a objevování.

Viz též:
 * Help:System message

<span id="Release_notes">

Poznámky k vydání
Musíte dokumentovat všechny významné změny (včetně všech zpráv o opravených chybách) 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ěleno do tří sekcí:


 * Změny konfigurace (configuration changes) je místo, kde můžete uvést změny do odsouhlaseného výchozího chování, zpětně nevhodných změn nebo jiných věcí, které potřebují, aby se na ně podíval správce serveru, 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, ale nemusí tak tomu 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. Nové položky doplňujte v chronologickém pořadí na konci oddílu.

<span id="System_messages">

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 v kódu použít "celé" klíče zpráv, než abyste je stavěli průběžně za chodu. Usnadňuje to jejich vyhledávání v kódové základně. Následující příklad ukazuje, jak hledání  nenajde použití tohoto klíče, pokud není použit jako celek.

Pokud máte pocit, že musíte vytvářet zprávy průběžně, vložte komentář se všemi možnými celými zprávami pro ostatní:

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

<span id="Preferred_spelling">

Preferované hláskování
Stejně tak jako je důležité mít shodný pravopis v uživatelském rozhraní a v kódové základně, je nutné mít shodné 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.

<span id="Abbreviations_in_message_keys">

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.

<span id="Improve_the_core">

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 duplikaci kódu na rozšíření nebo jinde v jádru a jeho místním úpravám.

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 (provádění změn v softwarovém systému takovým způsobem, že nemají vliv na vnější chování kódu, ale vylepšují jeho vnitřní strukturu s minimálním rizikem vnášení chyb) 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ů. Kód MediaWiki PHP je důvěryhodným zdrojem pro uživatelské rozhraní, může vydávat libovolné HTML. Analyzátor převádí uživatelem generovaný wikitext do HTML. Jedná se o nedůvěryhodný zdroj. Složitý HTML vytvořený uživateli prostřednictvím wikitextu se často nachází v jmenném prostoru "Template" (šablona). HTML vytvořené analyzátorem podléhá před výstupem ošetření.

Většinu atributů  mohou uživatelé používat ve wikitextu a šablonách. Následující předpony však byly omezeny a nejsou ve wikitextu povoleny a budou odstraněny z výstupního HTML. To umožňuje kódu JavaScript klienta 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.
 * – vyhrazený atribut pro interní použití jádrem MediaWiki, vzhledy a rozšířeními. Atribut  používá Parsoid. Jiný základní kód by měl používat.

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.

Poznámky
<span id="External_links">

Externí odkazy

 * Způsoby kódu