Lokální psaní kódu
Školení, která pořádám 
U větších projektů je velice důležité rozhodnout, kde budou umístěné konstanty a společné proměnné. Je lepší přihlašovací údaje k databázi uvést přímo do souboru connect.inc.php, který toto spojení zajišťuje, nebo je lepší je uvést do souboru config.inc.php spolu s ostatními údaji a v souboru connect.inc.php je jenom použít? Je lepší e-mailovou adresu, na kterou se odesílají objednávky, uvést přímo jako parametr funkce mail, dát ji do proměnné na začátek souboru, který odeslání objednávky zajišťuje, nebo opět do společného konfiguračního souboru? Obecně – je lepší psát kód lokálně s co nejmenší závislostí na kontextu nebo centralizovaně s umístěním všech takovýchto proměnných na jedno místo?
<?php // přímo v kódu mail("objednavka@example.com", "Objednavka", $zprava); // přes proměnnou $email_objednavka = "objednavka@example.com"; mail($email_objednavka, "Objednavka", $zprava); // ve společném souboru include "include/config.inc.php"; mail($EMAIL_OBJEDNAVKA, "Objednavka", $zprava); ?>
Musím říct, že u cizích projektů jsem vděčný spíše za lokální psaní kódu – podívám se do souboru, který vidím v URL, a když tam hned najdu a mohu změnit co potřebuji, je to mnohem jednodušší, než nejprve pochopit celou strukturu souborů a pracně hledat, na kterém místě je definováno to, co potřebuji změnit. Pokud se v projektu naopak orientuji a mám ho dlouhodoběji spravovat, je jednodušší mít veškerou konfiguraci centrálně v jednom souboru.
Lokální psaní kódu má tu výhodu, že usnadňuje čtení a přidávání kódu lidem bez znalosti celku. Např. do SciTE jsem byl schopen doplnit několik funkcí bez toho, abych pochopil, jak je to celé propojené dohromady. Podobně jsem byl schopen začít přispívat do PHP dokumentace ještě před tím, než jsem celkovou strukturu (která centrální prvky obsahuje) pochopil. A dokážu číst i pro mě složitý zdroják PHP, byť často jen díky chytré křížové referenci, která mě rychle odkáže např. na definice maker.
Zpět k otázkám z prvního odstavce – především zastávám názor, že veškerá data mají být uložena v databázi a e-mailovou adresu za data považovat určitě lze. Pokud k webové aplikaci existuje administrační rozhraní, není nutné kvůli změně adresy zasahovat do kódu, ani žádat jiný odborný zákrok. Získání této adresy z databáze je potom možné provést těsně před samotným odesláním e-mailu. Co se přihlašovacích údajů k databázi týče, osobně je do proměnných nedávám a rovnou je používám. A pokud jde např. o počet záznamů vypisovaných na nějaké stránce, není podle mě chybou uvést tento počet rovnou jako součást SQL dotazu, samozřejmě za předpokladu, že se toto číslo použije ve skriptu pouze jednou, jinak je lepší ho umístit do proměnné.
Pokud jste příznivci spíše centrálního psaní kódu, snažte se udržet vazby mezi soubory v rozumných mezích, ať pro jejich pochopení není potřeba podobná funkce:
<?php /** Rekurzivní zkontrolování vložených souborů * @param string soubor, ze kterého má začít kontrola * @return null vypíše vložené soubory, vykřičník před neexistujícími */ function zavislosti($filename) { static $zkontrolovano = array(); preg_match_all('~(?:include|require)(?:_once)?\\s*\\(?\\s*[\'"]([^\'"]*)~i', file_get_contents($filename), $matches); foreach ($matches[1] as $val) { if (!isset($zkontrolovano[$val])) { $zkontrolovano[$val] = true; if (file_exists($val)) { echo "$val (ze souboru $filename)\n"; zavislosti($val); } else { echo "! $val (ze souboru $filename)\n"; } } } } ?>
Lokální psaní kódu se uplatňuje také při vazbě HTML/JS a HTML/CSS. Obsluhu událostí píšu téměř výhradně přímo do HTML kódu (byť často spočívá jen v zavolání jedné funkce) – nemusím totiž prvku dávat ID a složitě se na něj z JavaScriptu odkazovat a snadněji se pracuje s objektem event. Na druhou stranu veškeré styly obvykle uvádím do externího souboru a přiřazování ID mi nevadí – jsem rád, že mám všechny styly pohromadě a mohu je snadno změnit. Možná to je dáno také tím, že v CSS se na ID odkazuje pomocí # a v JavaScriptu přes 27× delší document.getElementById('').
Diskuse
Voidless:
No, ja si zvykl davat vsechny konfiguracni konstanty do souboru defines.php, ktery je vzdy v rootu webu (nebo aplikace).Ale je pravda, ze na ostatni konstanty pisu (od dob PHP5) jako tridni.
Zak:
Když jste zmínil PHP manuál. Zdá se mi, že třeba slovací mají lépe a více toho přeložené v manuálu než-li v českém. Kolik lidí pracuje na českém překladu?
Jakub Vrána 
:
Momentálně 0 s výjimkou příležitostných úprav Lukášem Jelínkem nebo mnou. Určitě doporučuji anglický manuál.
Jakub Vrána : Zak:
A není to škoda? Jiné jazyky docela hojně se překládají. To potom bylo lepé stáhnout ten manuál, když tam bude tak hnít. Víte, mnohým nováčkům usnadníte život a taky spoustu dotazů ve fór. Je to opravdu škoda. Český manuál spolu s jednou verzí čínštiny se moc nepřekládá. Zbytek ano. Asi začnu asi používat slovenský manuál protože ten se aktualizuje. Ne každý proště vládne dobrou angličtinou. Nechcete vyzvat jiné lidi ve vašem oboru, aby se podíleli? Jakub Vrána :
Budiž toto veřejná výzva lidem v oboru, aby se naučili anglicky.
Ne, vážně, pokud se chce na českém manuálu kdkoliv podílet (včetně tebe), ať napíše na doc-cs@lists.php.net.
Jakub Vrána : Jakub Vrána :
Jak to vidí Yuhů: http://www.jakpsatweb.cz/weblog/b/1125713808-…-psani-kodu.html
Jakub Vrána : Honza Hučín:
Díky za tento článek. Zrovna zakládám projekt, který se časem může velmi rozrůst, takže radši pětkrát měřím, než jednou říznu.Zdá se mi, že pro pozdější správu, aktualizaci a rozšiřování funcionality webu bude potřeba psát od začátku hodně modulárně. Čím na méně místech se bude muset něco opravovat při změně nastavení databáze, přesunu ve struktuře adresářů, přidání nějakého layeru nebo rozšíření typu Texy apod., tím lépe.
Asi o tom něco blognu.
Diskuse je zrušena z důvodu spamu.
© 2005-2024 