Jak najít zdrojáky? (diskuse)

[Michal Kubeček]

Jestli je to ten python-gammu-0.8.tar.bz2, tak ne… Jsem zvědav, jak dlouho by ten člověk hledal zdrojáky na stránkách Mozilly…

[Michal Čihař]

Ano. máme tu prvního výherce .

[Spike]

Zdrojáky stable úplně v klidu, ale pěkně dlouho jsem hledal CVS... A přitom jsem to měl přímo pod nosem...

[Robert Krátký]

Není moc z čeho vybírat, takže se ty zdrojáky dají identifikovat docela snadno. Ale když do názvu archivu přidáš "src", nic tím nepokazíš.

[unchallenger]

A tím zmateš zbývajících 99% lidí, kteří nemají problém zdroják najít, nasereš případné baliče pro distribuce, etc., protože:

Package the distribution of `Foo version 69.96' up in a gzipped tar
file with the name `foo-69.96.tar.gz'.  It should unpack into a
subdirectory named `foo-69.96'.
                                           (GNU coding standards)

.tar.bz2 se přitom dnes už víceméně bere za rovnoprávnou alternativu.

[VícNežNic]

To jsou ty samé coding standards kde se píše třeba tohle?

For the body of the function, our recommended style looks like this:

     if (x < foo (y, z))
       haha = bar[4] + 5;
     else
       {
         while (z)
           {
             haha += foo (z, z);
             z--;
           }
         return ++x + bar ();
       }

Tak ty bych moc vážně nebral&hellip

[unchallenger]

O některých věcech nepanuje shoda a nikdy nepanovala, takže je dodržuje tak možná GNU samo.

Ale u jiných tato shoda panuje a nějaké chování je očekáváno (např. rpmbuild implicitně počítá s popsaným pravidlem, a je-li to jinak, musíš mu to říci). Jistěže můžeš napsat Makefile, kde bude defaultní target remove-home a udělá rm -rf ~, dokonce to můžeš popsat v README, ale stejně tě lidi nebudou mít rádi...

[unchallenger]

Taky je velký rozdíl v pravidlech, které se týkají jen vývojářů (formátování kódu), a pravidlech, které se týkají těch, kdo program používají (chování, makefile, tarbally). U těch prvních jsem mnohem víc nakloněn tomu, ať si to každý řeší, jak mu to vyhovuje.

[Pmx]

A co se ti na tom nelíbí?

[VícNežNic]

To je tak, kód může být hnusný. Pak ještě hnusnější. Pak může být nejhnusnější, potom dlouho nic a pak je tenhle příklad

[VícNežNic]

No, dovolím si i ukázku jak by to mělo vypadat správně

if (x < foo (y, z)) {
        haha = bar[4] + 5;
} else {
        while (z) {
                haha += foo (z, z);
                z--;
        }
        return ++x + bar ();
}

Hned je to přehlednější a hezčí

Na druhou stranu musím uznat, že mají pěkně udělané detaily, jako mezeru mezi jménem funkce a závorkama s parametry a další drobnosti se kterými v zásadě souhlasím.

Jo, a odsazení je přes tabulátor, aby bylo jasno

[Josef Kufner]

jo tak to ma byt :)

ad zdrojaky: Ta stránka je fakt nepřehledná. Chtěla by trošku urovnat a zbavit zbytečných prvků a čar.

[Michal Čihař]

Dobře reklama je zbytečný prvek, ale zatím to tam chci nechat . Čáry v tabulce? Mě to takhle připadá lepší než bez nich, ale nejsem grafik, no teď tam jsou CSS na obojí, tak to můžete posoudit.

[Michal Čihař]

No to vypadá podstatně lépe . Ale kdybych to psal já, tak se ještě zbavím toho ++x v returnu, protože to si prostě říká o to v tom udělat chybu .

[VícNežNic]

To se mi taky nelíbí, ale měnil jsem jenom formátování

[unchallenger]

Tak to ani náhodou.

return ++x + bar ();

Je klasická ukázka, jak mezery před ( rozbíjejí kód, takže musíš hledat, co vlastně patří k čemu.

else chci pořádně vidět, takže na začátek řádku. Jinak by to šlo.

if (x < foo(y, z)) {
    haha = bar[4] + 5;
}
else {
    while (z) {
        haha += foo(z, z);
        z--;
    }
    return ++x + bar();
}

[unchallenger]

K mezerám před ( bych ještě podotkl, že mezery se kolem operátorů mají objevovat s jejich klesající prioritou. Jelikož má volání funkce nejvyšší prioritu, jsou mezery kolem operátoru volání funkce nanejvýš pomýlené. Pokud bys chtěl zmíněný výraz zapsat čitelně, musel bys to udělat:

return ++x + (bar ());

tedy s přehnaným závorkováním, ke kterému GNU styl mezerování bohužel vede, má-li se udržet srozumitelnost.

[VícNežNic]

Závorkování nevadí, slepence závorek ano.

Když už by nebylo zbytí, mohlo by to vypadat:

return bar () + (++x);

Že to vypadá hnusně není tou závorkou ale zbytečným ++

Ale řekněme, že tohle je případ, kdy se dá závorka obětovat

[VícNežNic]

Tak to ani náhodou.

return ++x + bar ();

Je klasická ukázka, jak mezery před ( rozbíjejí kód, takže musíš hledat, co vlastně patří k čemu.

else chci pořádně vidět, takže na začátek řádku. Jinak by to šlo.

A tohle je lépe vidět? Nemyslím. Kdyby tam byl jediný řádek s } else {, tak to bude vyčnívat a nepůjde to přehlédnout (protože jak kód nad tím tak pod tím bude odsazený). Takhle se to utopí.

return ++x + bar(); se mi nelíbí ať už s mezerou nebo bez. ++ nebo -- bych tady vůbec nepoužil. Nicméně tohle je účelový příklad aby vynikly drobné nedostatky té mezery Naopak na příkladu kde by v těch závorkách bylo dalších pět zanořených a navrch ještě nějaké přetypování by se to krásně ukázalo

[unchallenger]

Ad else. To je asi otázka zvyku, ale klíčová slova složených příkazů (kromě blbého do-while) prostě hledám pouze na začátích řádků. Co je za nějakou }, to jako by nebylo.

Ad (). Příklad je umělý, takže to ++ asi nemá moc smysl rozebírat. Jinak nevím, co by se mělo ukázat. S GNU přetypováním to vypadá

return ++x + (int) bar (y) + * (int *) (b + 3) + (int) (bb * 3);

a to už vůbec netuším, co je vlastně bar zač, co se sčítá tím +, a kde se tam vzala ta hvězdička...

[VícNežNic]

Opět umělý příklad

(int) bar (y) + ((int *)(b + 3) + (int)(bb * 3));

Nějak přehledněji? (mezi dvě závorky bych mezery asi nepsal, stejně jako třeba mezi [5] [4], [5][4] je IMHO lepší)

[unchallenger]

(int)bar(y) + ((int*)(b+3) + (int)(bb*3));

nebo

(int)bar(y) + ((int*)(b + 3) + (int)(bb * 3));

ale jinak pokud možno hlavně

(int*)(b + 3) + (int)(bb * 3) + (int)bar(y);

protože psát pointerovou aritmetiku s pointerem zahrabaným kdesi vprostřed výrazu je cesta do pekel. Kromě toho je hned vidět, že se sčítají tři věci a jaké.

Mezery se píší za kvůli přehlednosti, takže nemám problém s tím, že

2*3 + 1

se napíše bez mezer kolem *, kdežto

foo->bar(x) * (int)x[3]

s mezerou kolem *, pokud v jednom výrazu nedostanou operátory s vyšší prioritou mezery, když operátory s nižší mezery nemají.

[VícNežNic]

No dobře, ale stejně to IMHO vyjde nastejno a nelíbí se mi to

[Marián André]

No, možno by stačilo využiť stĺpec Description na vyššie odkazovanej stránke a bolo by jasné aj pre takýchto pisateľov mailov.

[Michal Čihař]

No dobře, tak jsem to tam přidal . Ale mám obavy, že tomuhle člověku nepomůže vůbec nic.