Dvě podmínky ve while

[Hmmm]

Takové žvásty fakt číst nebudu, cituji ze strany 34, ale dalo mi to poznání odkud se takové svinstva berou:

In the eighties we used to say that a function should be no bigger than a screen-full.
Of course we said that at a time when VT100 screens were 24 lines by 80 columns, and
our editors used 4 lines for administrative purposes. Nowadays with a cranked-down font
and a nice big monitor, you can fit 150 characters on a line and a 100 lines or more on a
screen. Lines should not be 150 characters long. Functions should not be 100 lines long.
Functions should hardly ever be 20 lines long.

Programovat podla poctu riadkov na monitore teda podla mna urcite nie je dobry napad.

Hovori ti nieco atomickost? Znovupouzitelnost? Prehladnost?

Funkcia, ktora ma 240 riadkov, bude tazko znovupouzitelna v uplne inom projekte. S prehladnostou moze mat tiez problem a atomickost zamerne nezmienujem.

Ja sa tiez rad drzim toho, ze funkcia by mala mat najviac 20 riadkov. Nie preto, ze to napisal nejaky Moore ci Green, ale preto, ze som prilis lenivy znovu vynachadzat koleso, rad teda pouzivam v novom projekte to co som uz pouzil pred niekolkymi mesiacmi v inom a, to ide ruka v ruke, som rad, ak po tych par mesiacoch viem prakticky okamzite povedat co stara funkcia robi.

[Reklama]

[k]

No vida, našel jsi to!

Nenašel, výčet parametrů VT100 není důkaz proč má mít funkce 20 řádek.

Funkcia, ktora ma 240 riadkov, bude tazko znovupouzitelna v uplne inom projekte.

Běžně mám funkce 200 řádek a běžně je používám v jiných projektech. Například když má switch 15 možností a každá možnost je na pět řádek + break, tak kvůli tobě nebudu dělit do pěti funkcí.

[Kit]

No vida, našel jsi to!

Nenašel, výčet parametrů VT100 není důkaz proč má mít funkce 20 řádek.

Našel jsi a otevřel tu učebnici. To je dobrý počin. Jen tak dál.

Funkcia, ktora ma 240 riadkov, bude tazko znovupouzitelna v uplne inom projekte.

Běžně mám funkce 200 řádek a běžně je používám v jiných projektech. Například když má switch 15 možností a každá možnost je na pět řádek + break, tak kvůli tobě nebudu dělit do pěti funkcí.

Ty ještě používáš break? 5 řádek u každé možnosti? Pak se nedivím, že máš funkce na 200 řádek. Vždyť se nesnažíš o znovupoužitelnost ani uvnitř toho switche.

[k]

Ty ještě používáš break? 5 řádek u každé možnosti? Pak se nedivím, že máš funkce na 200 řádek. Vždyť se nesnažíš o znovupoužitelnost ani uvnitř toho switche.

Věř tomu že jsem líný psát a je to nezbytně nutné.
Na případ kdy nepřekročíš limit 20 řádek na metodu a samotný switch má 20 možností se raději neptám, nechci to vědět s ohledem na mé duševní zdraví.

[Ondra Satai Nekola]

Ty ještě používáš break? 5 řádek u každé možnosti? Pak se nedivím, že máš funkce na 200 řádek. Vždyť se nesnažíš o znovupoužitelnost ani uvnitř toho switche.

Věř tomu že jsem líný psát a je to nezbytně nutné.
Na případ kdy nepřekročíš limit 20 řádek na metodu a samotný switch má 20 možností se raději neptám, nechci to vědět s ohledem na mé duševní zdraví.

Pokud pravidla porusujes z dobrych duvodu, je to OK. Ale to, co tu popisujes, mi pripomina spis typicky code smell. (mozna k tomu dobry duvod je, to bez kodu neposoudime, ale byl bych hodne podezrivavy)

[Reklama]

[Kit]

Na případ kdy nepřekročíš limit 20 řádek na metodu a samotný switch má 20 možností se raději neptám, nechci to vědět s ohledem na mé duševní zdraví.

To je prosté: Jednoduše ten limit překročím. Metoda, kde switch má 40 možností, má délku třeba 45 řádek. Není však delší, než je nezbytně nutné a dodržuji pravidlo: Jedna možnost - jeden řádek - jeden příkaz. Čitelnost je pak luxusní.

[k]

Můžeš se vyjádřit k neutrálnímu kódu _negotiate(telnet_t *telnet, unsigned char telopt) https://github.com/seanmiddleditch/libtelnet/blob/master/libtelnet.c
Konkrétně jak se zlepší přehlednost rozdělením tohoto díla na cca 10 metod o 20 řádcích.

[Ondra Satai Nekola]

Můžeš se vyjádřit k neutrálnímu kódu _negotiate(telnet_t *telnet, unsigned char telopt) https://github.com/seanmiddleditch/libtelnet/blob/master/libtelnet.c
Konkrétně jak se zlepší přehlednost rozdělením tohoto díla na cca 10 metod o 20 řádcích.

Od oka rozdelit podle v tech mistech, kde jsou /*komentare*/ protoze ta si primo rikaji o pojmenovani misto komentovani?

Mozna je navic to cele zbytecne delat kodem, prijde mi to jako neco, co by lepe resilo hledani v tabulkach... ale nemam kontext.

[k]

Od oka rozdelit podle v tech mistech, kde jsou /*komentare*/ protoze ta si primo rikaji o pojmenovani misto komentovani?

OK, tak místa kde by se to mělo dělit už známe, teď ještě jak přesně to rozdělení zlepší přehlednost
Kontext máte v dalších souborech projektu na githubu a v RFC na telnet, máte ideální podmínky

[Ondra Satai Nekola]

Od oka rozdelit podle v tech mistech, kde jsou /*komentare*/ protoze ta si primo rikaji o pojmenovani misto komentovani?

OK, tak místa kde by se to mělo dělit už známe, teď ještě jak přesně to rozdělení zlepší přehlednost
Kontext máte v dalších souborech projektu na githubu a v RFC na telnet, máte ideální podmínky

sorry, ale nehodlam travit vecer refaktorovanim takoveho kodu

prehlednost se zlepsi, protoze najednou metoda vypada jako posloupnost par dobre pojmenovanych veci, takze kdyz ji ctes, tak mas tuseni o semantice a detaily si muzes rozkliknout pozdeji (a jen kdyz je potrebujes)?

[Kit]

Můžeš se vyjádřit k neutrálnímu kódu _negotiate(telnet_t *telnet, unsigned char telopt) https://github.com/seanmiddleditch/libtelnet/blob/master/libtelnet.c
Konkrétně jak se zlepší přehlednost rozdělením tohoto díla na cca 10 metod o 20 řádcích.

Před každým vnějším case je komentář. To je vhodné místo pro volání funkce. A když píši funkce, tak nemyslím proceduru.

Vezmu jeden switch:

Kód: [Vybrat]

    /* in PROXY mode, just pass it thru and do nothing */
    if (telnet->flags & TELNET_FLAG_PROXY) {
        switch ((int)telnet->state) {
        case TELNET_STATE_WILL:
            NEGOTIATE_EVENT(telnet, TELNET_EV_WILL, telopt);
            break;
        case TELNET_STATE_WONT:
            NEGOTIATE_EVENT(telnet, TELNET_EV_WONT, telopt);
            break;
        case TELNET_STATE_DO:
            NEGOTIATE_EVENT(telnet, TELNET_EV_DO, telopt);
            break;
        case TELNET_STATE_DONT:
            NEGOTIATE_EVENT(telnet, TELNET_EV_DONT, telopt);
            break;
        }
        return;
    }

Mírně ho zmodifikuji a vyčlením do funkce:

Kód: [Vybrat]

/* in PROXY mode, just pass it thru and do nothing */
if (telnet->flags & TELNET_FLAG_PROXY) {
    return passThruProxy(telnet, telopt);
}

Kód: [Vybrat]

static int passThruProxy(telnet_t *telnet, unsigned char telopt);
    switch ((int)telnet->state) {
        case TELNET_STATE_WILL: return NEGOTIATE_EVENT(telnet, TELNET_EV_WILL, telopt);
        case TELNET_STATE_WONT: return NEGOTIATE_EVENT(telnet, TELNET_EV_WONT, telopt);
        case TELNET_STATE_DO:   return NEGOTIATE_EVENT(telnet, TELNET_EV_DO, telopt);
        case TELNET_STATE_DONT: return NEGOTIATE_EVENT(telnet, TELNET_EV_DONT, telopt);
    }
}

Jak vidíš, zápis se zkrátil a čitelnost zlepšila.

Dále autor zapomíná příkazové závorky u jednořádkových ifů. To je hodně nebezpečné.

Ještě to chce rozbít vnořené switche tak, aby v každé funkci byl pouze jeden.

[k]

prehlednost se zlepsi, protoze najednou metoda vypada jako posloupnost par dobre pojmenovanych veci, takze kdyz ji ctes, tak mas tuseni o semantice a detaily si muzes rozkliknout pozdeji (a jen kdyz je potrebujes)?

Jak vidíš, zápis se zkrátil a čitelnost zlepšila.

Jak to hodláte udělat bylo jasné celou dobu, vnitřní switche dáte do pěti funkcí a budete si honit triko že máte šest krátkých funkcí. Bohužel ke zvýšení přehlednosti nedošlo, kód takto rozdělený je naopak přehledný méně, musí se zkoumat kdy se která funkce zavolá, co se jí předá a co se (případně) vrátí.
Přesvědčit jste mě nepřesvědčili.

[Ondra Satai Nekola]

Tak to je na tvem gustu. U nas bys asi pres reviews moc kodu neprotlacil, nejenom kvuli poctu radek, ale hlavne protoze ta metoda micha vic urovni abstrakce naraz
A mam dojem, ze ani kernel nebo GNU coding standards to nesplnuje, ale ty jsem videl uz pred lety, tak se mozna pletu.

[Kit]

Jak vidíš, zápis se zkrátil a čitelnost zlepšila.

Jak to hodláte udělat bylo jasné celou dobu, vnitřní switche dáte do pěti funkcí a budete si honit triko že máte šest krátkých funkcí. Bohužel ke zvýšení přehlednosti nedošlo, kód takto rozdělený je naopak přehledný méně, musí se zkoumat kdy se která funkce zavolá, co se jí předá a co se (případně) vrátí.
Přesvědčit jste mě nepřesvědčili.

Aspoň vidíš, že nevařím z vody a že prezentuji styl, kterým skutečně programuji. Ten program je napsán procedurálním stylem, navíc s použitím #define. Refaktorovat by se to dalo, ale 1500 řádek by nějakou dobu trvalo. Nemohu za to, že neumíš pracovat s formálními parametry funkcí ani s návratovou hodnotou, protože na tom není dohromady co zkoumat. Nemám ambice spravovat telnet, výsledkem by byla jen tvá nespokojenost.

Pokud jsem tě nepřesvědčil, máš smůlu.

[Lol Phirae]

Co se týče závorek tak kdo daný jazyk ovládá jasně ví jak se co vyhodnocuje, když ne neměl by nic upravovat...

Tak jistě. Protože se nikdo nikdy neuklepne v odsazení, případně při kopírování něčeho někam to nezkopíruje i s tím odsazením. A nikdo pak po mnoha letech nepátrá po tom, proč se sakra něco (ne)vyhodnocuje tam, kde by (ne)mělo. U těch if-ů apod. to je fakt na uražení pazoury.