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

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

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

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

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.

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.

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.

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ě 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ýchch změn nebo jiných věcí, které potřebují 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í 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.

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.

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.

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

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

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

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