ukazkove zdrojaky

[Jan Kasprzak]

Jan Markus wrote:
: Diky, mrknu na to. Dost lidi mi napsalo soukrome a hodne doporucuji
: kod co vysel zpoza rukou samotneho RMS. Musim rict, ze se mi hodne
: libi.

[aaa, zacina nam flame war na tema styl programovani; nasadme si azbestove
 cepice :-]

	Myslim ze ciste napsany je treba (ze znacne casti) kernel
Linuxu. Akoratze vzhledem k povaze toho v jakem prostredi tento kod
bezi to neni nekdy pro neznaleho uplne nejsrozumitelnejsi. Cili jako
vyukovy kod pro zacatecniky nedoporucuji.

: Odsazuje pouze dvema mezerama (coz mi pripada prehlednejsi nez
: ty polovicni ci dokonce cely tabelatory)

	Bleee (stejne jako celemu formatovani C-kodu podle projektu GNU).
Nevim co vidite hezkeho na tomto:

main ()
{
  if (a)
    {
      b ();
    }
  else
    {
      c ();
    }
}

Pritom indent -kr -i8 Vam da kod ktery je na mene radku a presto (nebo
vlaste i proto) je ten kod daleko citelnejsi (oci tady maji jen tri
urovne odsazeni, na kterych se mohou zarazit, a kod ma taky jen tri urovne
vnoreni, takze odsazeni zde odpovida logicke strukture kodu):

main()
{
        if (a) {
                b();
        } else {
                c();
        }
}

Ale no flames. Doporucuji precist si (nebo i studentum dat precist)
linux/Documentation/CodingStyle. Tam je popsano jaky styl se uvnitr
jadra pouziva, ale hlavne je tam u kazdeho rozhodnuti napsano
_proc_ by se takto melo psat (osobne doporucuju precist si zejmena
odstavce o slozenych zavorkach a prave o odsazovani). Odsazovani o mene
nez cely tabelator je jednak mene prehledne, zvlast po dlouhych hodinach
u monitoru :-) a jednak dovoluje programatorovi prilis velkou uroven
vnoreni bloku (coz je znamkou spatne navrzeneho kodu).

: a vsechno peclive
: okomentovava, takze je z kodu hotova kniha...

	Coz taky neni vzdy dobre. Je to zase pekne popsane v CodingStyle.
Kdyz clovek ma tendenci napsat komentar ktery vysvetluje nejakou zaludnost
v kodu, melo by to pro neho byt signalem k zamysleni, jestli nahodou nejde
tahle vec udelat tak, aby tam tato zaludnost nebyla. Ne vzdy to jde udelat,
ale riziko prilisneho komentovani tady vzdycky je. Extremni priklad jsem
videl nedavno v jedne bakalarske praci, kde bylo neco jako

int tmp3; /* promenna tmp3 obsahuje pocet nalezenych prvku */

... celoradkovy komentar vysvetlujici to, co by se dalo daleko lepe
napsat bez komentare a s promennou, ktera by se misto tmp3 jmenovala
nejak jako items_found nebo nalezenych_prvku.

	Stejne tak je zverstvo takove to co maji mnohe projekty - povinny
popis funkce pred jeji definici - coz obvykle konci tim ze se prevypravi
slovne nazev funkce, nazvy a typy argumentu a typ navratove hodnoty.
U dobre napsaneho kodu je toto vse jasne z nazvu funkce a parametru.
Je-li pouzit nejaky trik, ktery tam fakt musi byt, pak dokumentujme
_jen_ ten trik.

	Primarnim zdrojem informaci o kodu ma byt kod samotny (jeho
cistota a citelnost). Komentare se casto dostanou postupnymi zmenami
do rozporu se skutecnosti. Proto by jich melo byt co nejmene, a to
konkretne jen upozorneni na nejake triky a nestandardnosti (plus mozna
nejake celkove vysokourovnove povidani na zacatku programu nebo modulu
nebo u nejake podstatnejsi funkce).

: Nekdo (nebudu prozrazovat ;)) tady nadava na zdrojaky vim-u. Taky me
: prekvapilo kolik lidi (chci rici hackeru :>) pouziva volani "goto",
: pricemz v literature je to casto odsuzovany... asi nectu tu spravnou
: literaturu

	Kod plny goto je zlo, ale goto ma jedno platne a funkcni vyuziti
- osetreni chybovych stavu: podivejte se, jak probiha treba inicializace
ruznych driveru v jadre Linuxu - obvykle je to ve stylu

int mydev_probe(...)
{
	if (!(mydev_priv = kmalloc(...))
		goto out1;
	....
	if (!register_interrupt(...))
		goto out2;
	....
	if (!register_chrdev(...))
		goto out3;
	....

	return 0;
out3:
	unregister_interrupt(...);
out2:
	kfree(...);
out1:
	return -ENODEV;
}

	Pokud byste tohle psal bez goto, utopil byste se ve vnorenych
blocich. A presne proto je v tomto miste goto rozumne a zvysujici citelnost.

: Taky se mi ozvali dva BSD nadsenci. Vida, na BSD jsem malem zapomel,
: uz jsem si ho nainstaloval i se zdrojakama a kocham se po nocich.

	Kernel fakt ve vyuce zacatecniku nepouzivejte - neni to "linearni"
kod, cili je z principu nepoucenemu mene zrejmy nez nejaky "sekvence bezici"
program.

	Co se tyce stylu programovani, doporucuji si precist knihu
"Perl Best Practices" od Damiana Conwaye (O'Reilly ma na webu ukazkovou
kapitolu). Je to sice z vetsi casti specificke pro Perl, ale dost veci
je tam aplikovatelnych i na programovani obecne (programovani po odstavcich,
nedostatek nebo premira komentaru, pojmenovani promennych, atd.).
A hlavne - napsal to clovek ktery opravdu pise kod, nepise ho sam,
a jeho kod se pouziva - zadny teoretik.

-Y.

-- 
| Jan "Yenya" Kasprzak  <kas at {fi.muni.cz - work | yenya.net - private}> |
| GPG: ID 1024/D3498839      Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/    Journal: http://www.fi.muni.cz/~kas/blog/ |
> Specs are a basis for _talking_about_ things. But they are _not_ a basis <
> for implementing software.                              --Linus Torvalds <