Jak se neztratit v proměnných, konstantách, souborech, třídách a projektech. Jde to vůbec?
29.10.2004 15:00 | Petr Zajíc | přečteno 32581×
Dnes budeme pokračovat zcela v duchu minulých dvou dílů a rozebereme si další způsoby, jak se neztratit při psaní nějakého rozsáhlejšího projektu. Nebudou to věci překvapivě nové, ale věci překvapivě účinné, pokud se rozhodnete řídit se jimi.
Kvalitní kód je zcela vždy dokumentovaný kód. Paradoxně zjistíte, že
když budete programovat delší dobu, budete psát spíše více komentářů
než méně. To proto, že zralí programátoři jsou si vědomi potřebného
psaní komentářů velmi dobře (věřte mi, každý z nich totiž zažil fázi,
kdy se nevyznal ani ve svém vlastním projektu). Co by měly správné
komentáře obsahovat?
Pozn.: Ten poslední bod by se měl brát s
rezervou. Stejnou, ne-li lepší službu pro nás udělají systémy pro
správu zdrojových kódů. Ještě o nich bude řeč.
Někteří programátoři doporučují do poznámek psát rovněž datumy, kdy
se kód upravoval a některé další věci. Je to diskutabilní. Pokud je to
pro Vás přínosné, udělejte to.
Ještě pro doplnění: Některé čtenáře nadzvedlo, že jsem v předchozím
díle komentoval činnost procedury v jejím těle a ne před jejím
začátkem. Uvědomte si ale, že je mnohem důležitější to, zda komentáře máte než to, kde je máte. Budete-li chtít
přístup k psaní komentářů nějak unifikovat, mohou rozhodnout
následující činitele:
Už o tom rovněž byla řeč. Měli byste si zavést a dodržovat určitý pořádek v názvech proměnných, funkcí, tříd, konstant a souborů. Náhledů jak to dělat správně je mnoho. Pamatujte si, že většinou se budete na linuxovém prostředí setkávat s tím, že na velikosti písmen bude záležet, takže s tím počítejte. Někdo například názvy všech souborů píše s malými písmeny.
Určitý systém lze vnést i do proměnných. Praktické je, když je z názvu proměnné poznat k čemu slouží (nebo dokonce jaký je její datový typ). Srovnejte, prosím, následující dva řádky kódu (třeba přitom můžete zavzpomínat na školní léta):
<?
$c=$z*$p;
?>
anebo je čitelnější toto?
<?
$dblCast=$intZaklad*$dblPocet_procent;
?>
Samozřejmě, se vzrůstající náročností kódu oceníte takovou čitelnost ještě více. Hodně se dá napravit rovněž vhodným zavedením konstant a logickými názvy souborů. Porovnejte, prosím, následující dva fragmenty kódu:
<?
if ($err==1):
require ("file.php");
elseif ($err==2):
require ("file2.php");
elseif ($err==3):
require ("file3.php");
endif;
?>
anebo
<?
define ("ERR_NO_FILE", 1);
define ("ERR_EMPTY_FILE", 2);
define ("ERR_CANT_WRITE", 3);
if ($err==ERR_NO_FILE):
require ("nofile.php");
elseif ($err==ERR_EMPTY_FILE):
require ("emptyfile.php");
elseif ($err==ERR_CANT_WRITE):
require ("cantwrite.php");
endif;
?>
Ačkoli oba kousky kódu dělají v podstatě totéž - ke kterému z nich
byste se raději vraceli a luštili, co se v něm vlastně děje?
Mám na mysli organizaci kódu do souborů a složek operačního systému. Tady je každá rada drahá. U jednodušších věcí asi vystačíte s tím, že můžete všechny skripty umístit do kořenové složky webu, u složitějších projektů se vyplatí nějak zorganizovat složky. Například bývá často k vidění uspořádání, kde soubory začlenění jsou v samostatné složce, v jiné složce soubory pro import/export a podobně. Pozor pak musíte dávat při vkládání soubrů pomocí include(require), protože vyžadují správné uvádění cest. Můžete v zásadě použít dvě metody - uvádět relativně od existujícího dokumentu a uvádět relativně od kořenové složky webu. Obojí má své pro a proti, ale příliš se nevyplácí to míchat:
<?
require ("./inc/somefile.php");
?>
a ten druhý způsob
<?
require ($_SERVER["DOCUMENT_ROOT"]."/inc/somefile.php");
?>
Pochopitelně, můžete mít nějaký vlastní systém. Ale ve větším projektu se vkládání souborů prakticky nevyhnete, takže se s tím budete muset nakonec nějak popasovat.
Konečně, každý projekt by měl mít nějakou dokumentaci. Nemluvím teď o dokumentaci k vlastní aplikaci, ale o technické specifikaci jednotlivých funkcí a procedur. Tady se vývojáři dělí na několik typů:
Zejména těmu ukázněným pak mohou pomocí nástroje typu phpDocumentor. My se spokojíme s tvrzením, že by se to dělat mělo a v dalším díle se podívame na to, jak si při vývoji pomoci cizími kódy, nástroji pro správu zdrojových kódů a několika programovacími triky.