JaroB postnul komentář, který je zajímavý, ale nečitelný díky formátování, takže jsem z něho udělal nový článek a komentář smazal. Ne ze vším sice na 100% souhlasím, ale většinou ano a je to zajímavé a inspirující (tedy až na tu část o CnPack a eventy, Frames a použití resource string - přístup k nim je výrazně pomalý). Jen se mi zdá, že konvence <> zásada dobrého návrhu aplikace.
Originální příspěvek
Já osobně nejsem moc příznivec konvencí. Zdrojový kód lze zaformátovat buď zabudovaným formátovačem kódu, nebo pro nižší verze velmi dobrým programem od Egberta van Nese (DelForExp), který si poradí i s klíčovými slovy, ale neporadí si s extended records s property, konstantami a funkcemi z Delphi 2006 a vyšší. Ale to jde skousnout.
Horším problémem jsou názvové konvence. Funkce CnPack umožňuje komolení jmen komponent, ale to není úplně ono, zvlášť když se z takto komolených jmen získávají názvy pro eventy. Taky se mi zdá dost nevhodný systém konvencí, které jsou mnohdy uplatňovány Java programátory. Setkal jsem se s projektem v Delphi, který obsahoval kolem dvou tisíc tříd, a každá měla vlastní zdroják. Je prostě obtížné najít takový jmenný prostor, který by pokryl v co nejširší škále všechny možné nuance, a přesto se vyhnul číslování, a zároveň si celou šíři pamatovat napříč aplikací.
Podle mě je vhodné používat pro názvy komponent, rozhodujících (globálních) proměnných, vlastností nebo i funkcí pokud možno popisná a zároveň nezáměnná jména. U lokálních proměnných preferuji co nejkratší názvy, mnohdy lze pro čítače i jednopísmenné. Názvy komponent a dalších identifikátorů v knihovních balících jsou poplatné knihovně – podle názvu by se mělo vždycky dát dohledat, že unita, komponent nebo proměnná (není-li to zakrývající proměnná obecnějšího charakteru) patří právě do této knihovny. (Svého času jsem měl úsměvný konflikt se jménem unity DxCommon.pas, byla obsažena jak v balíku DelphiX, tak v balíku komponent DevExpress – ale pokaždé obsahovaly něco jiného a nedělalo to dobrotu, když se setkaly na jedné úrovni paths a v jedné verzi Delphi).
Pokud ovšem nejsou nastaveny politiky, že všechny veřejné názvy komponent, proměnných či vlastností (nebo názvů funkcí exportovaných z DLL) musí být komoleny nějaký obfuskátorem (v Delphi for .NET to je i nějaké příslušenství tuším Demeanor for .NET), aby nebylo možno odvodit třeba i nepřímo funkci skrývající se za názvem. Tady potom názvové konvence lehce selžou.
Před pár lety jsem splácal jisté třicatero, ale je to na diskuzi a taky vůli těch, kteří by se tím chtěli řídit. Následující body jsou spíš určeny pro Object Pascal, ale některé zásady se dají uplatnit i v jiných jazycích (C++ atp.)
Třicatero
1/ Vyvarovat se používání globálních proměnných, které se používají víceméně lokálně.
2/ Důsledně používat pojmenované konstanty a pro větší bezpečnost je vázat na public/private sekce tříd podle použití.
3/ Důsledně unifikovat přístup k datům, názvy polí používat přes pojmenované konstanty viz bod 2.
4/ Vyvarovat se polí v public sekcích, v přístupech používat property.
5/ Důsledně používat typové konstanty/proměnné – co možná nejvíce ponechat kontrol na překladači.
6/ Důsledně používat výčtové typy a množiny – významně to pomůže v bitových a logických operacích a v rozskocích (case).
7/ Názvy proměnných volit co nejvíce samopopisné (lze až do prvních 64 významných znaků).
8/ Důsledně využívat automatické konstrukce IDE při vytváření názvů komponent (ale i proměnných).
9/ Pro správu dat omezeného rozsahu s jednoduchým ukládáním je vhodné používat záznamy s metodami a vlastnostmi.
10/ Někdy je lepší vytvořit class helper než podědit třídu zvlášť, když potomek nedrží data "navíc".
11/ Návratové hodnoty funkcí vytvářet tak, aby je bylo možné použít tzv. na jediném řádku.
12/ Pro identifikaci chyb tříd je nejlepší vytvořit specifický exception class (místo obecného), snáze se identifikuje modu i metoda výskytu chyby.
13/ K optimalizaci kódu přistoupit až po naprogramování, vyhneme se chybám neúplně implementovaných algoritmů.
14/ Formuláře lze efektivně rozdělit buď pomocí frames nebo v některých případech systémem nepřímého subclassingu (plnohodnotný formulář je začleněn do kontejneru aplikace).
15/ Kvůli názvovým konvencím je lepší interface vygenerovat než psát ručně a vyhnout se tak pasti změti názvů (stejně tak generování interface z WSDL).
16/ Návrh GUI by měl respektovat základní ergonomické zásady (především pohybu po polích, intuitivnosti a vhodným nápovědným systémem). V případě použití společných událostí (není to na první pohled vidět) na tuto skutečnost upozornit v komentáři.
17/ Při převzetí cizího kódu se vyvarovat, bez pochopení podstaty, okamžitého refaktoringu, přejmenování proměnných či změny modularity aplikace.
18/ Při přetěžování funkcí/metod mít na paměti účel vytváření (tvůrce komponent vytvoří nadbytek přetížených funkcí, aplikační programátor jen to co opravdu potřebuje).
19/ Zvýšit čitelnost kódu doporučeným formátováním a komentáři pro základní metody (pro metody generované např. událostní metody komentovat tam, kde je to nezbytné).
20/ Algoritmy komentovat vždy, případně uvádět část ze zadávacích dokumentů (v tomto případě nestačí odkaz na dokumentaci).
21/ Při vytváření GUI, kde je množství podobných formulářů, zvážit využití prapředka (například pro dialogy se společnými prvky a funkcemi), protože v důsledku se omezí programový kód.
22/ Při ukládání textů v co největší míře využít možnosti refaktoringu k extrakci do tzv. resource stringů (usnadní to pozdější lokalizaci).
23/ Důsledně vyčistit nepoužité programové jednotky (mohou mít vlastní inicializační sekce, které zpomalí start/ukončení aplikace).
24/ Pokud aplikace využívá externí moduly, které nejsou součástí operačního systému, a proto musí být dodávány zároveň s aplikací (nejsou to plug-ins/add-ins), musí být použité interface na tyto moduly součástí dokumentace.
25/ Jsou-li použity komponenty třetích stran a není-li to v rozporu s licenčním ujednáním, musí být zdrojové kódy (příp. jednotky) součástí projektu.
26/ Pro nové algoritmy je vhodné vytvořit zvláštní testovací projekt.
27/ V případě více podobných projektů je vhodnější vytváření společných knihoven než striktně oddělených projektů, sníží se významně pracnost při dopadu požadavku do všech projektů.
28/ Preferovat puzzle architekturu na úrovni formuláře/subformuláře, protože dokáže extrémně rychle reagovat na změny funkčnosti ze strany zadavatele za cenu nízké pracnosti.
29/ Uvážlivě využívat komponenty třetích stran, týká se to hlavně balíků komponent, je pak nutné mít na paměti, že není snadné je z aplikace odstranit a vývojář je jistým rukojmím dodavatele při přechodu na vyšší verzi překladače, což obvykle vyvolává nutnost úpravy balíku kvůli kompatibilitě.
30/ A mít na paměti, že aplikace může být kdykoliv předána jinému vývojáři třeba do Indie, a podle toho ji mít nachystanou k odevzdání s veškerou dokumentací.
Pozn.: ad 30 a proto je důležité mít nějaké konvence ;-)
RSS