ARCHIV

PHP (62) - Rozsáhlejší projekty 3.

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 | Články autora | přečteno 33318×

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.

Komentáře

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?

• U funkcí okomentujte, co musí být splněno, aby vracela to, co má. Mohou to být "vnější" vlivy, jako je existující připojení k databázi, existující rozšíření PHP a kdovíco ještě.
• U funkcí okomentujte vstupní parametry. Měl by mít parametr nějaký konkrétní typ? Hodnotu? Hodnotu z nějakého rozsahu? Napište si to. Později to zcela jistě oceníte.
• U funkcí okomentujte hodnoty, které může vrátit, a jejich význam. Je hrozné mít funkci, která sice dělá to, co by měla, ale nikdo neví, proč to bylo potřeba.
• U tříd nějak okomentujte parametry. Snažte se rozlišit veřejné a privátní členy, protože PHP je v tom dosti benevolentní.
  
• V těle programu komentujte kód vždy, když je principiálně nepřehledný. Usnandí vám to orientaci.
• Pokud jste nějakou část kódu přepsali, je lepší tu původní zakomentovat než odstranit. Později se Vám může stará verze hodit.

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:

• Vaše zvyky
• To, zda se chcete nebo musíte řídit nějakými konvencemi (například firemními)
• To, zda chcete nebo musíte používat nějaké nástroje pro automatizovanou dokumentaci

Typové konvence

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):

anebo je čitelnější toto?

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:

anebo

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?

Organizace projektu

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:

a ten druhý způsob

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.

Dokumentace

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

• na ty, kteří to nepíší vůbec
• na ty, kteří to píší částečně nebo jen u větších věcí
• a na ty, kteří to dělají ze zvyku a poměrně pravidelně

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.

Verze pro tisk