Který kód je lepší?

[bohous]

Zdar lidi. Chci se zeptat. Mam 2 ukazky kodu a chci se zeptat, ktera je lepsi:
1.

Kód: [Vybrat]

var connStr = ConfigurationManager.ConnectionStrings["connstr1"].ConnectionString;
            if (args.Length == 1)
            {
                switch (args[0])
                {
                    case "-p":
                        connStr = ConfigurationManager.ConnectionStrings["connstr2"].ConnectionString;
                        break;
                    default:
                        Console.WriteLine("wrong");
                        Console.ReadKey();
                        return;
                }
            }
2.

Kód: [Vybrat]

string connStr;
switch (args.Length)
{
case 0:
connStr= ConfigurationManager.ConnectionStrings["connStr1"].ConnectionString;
break;

case 1:
switch (args[0])
{
case "-p":
connectionString = ConfigurationManager.ConnectionStrings["connstr2"].ConnectionString;
break;

default:
InvalidArg();
return;
}
break;

default:
InvalidArg();
return;
}

Je jsem delal kod prvni. Nevim kdo, nejspis teamliiidr, to prepsal do tvaru 2.
Co si myslite?

[Reklama]

[PsychoIT]

Nejspíše dva kandidáti na příspěvek na hovnokod.cz .

[bohous]

s cim mas konkretne problem debile? umis to zapsat lepe? tak do toho

[LP]

Nelíbí se mi tak úplně ani jeden. Mimochodem není to Length, ale length, takže ta podmínka nebude platit nikdy(pokud to není nějaká custom vlastnost). Druhá varianta je možná o něco lepší v případě, že se očekává rozšiřování o další parametry. Ale to je čistě "tahání za slovíčka", přepsat to z ifu na switch nebo obráceně je myslím ten nejmenší problém a osobně bych to asi řešil, až se tam opravdu budou přidávat parametry. Ale z kousku kódu těžko soudit... Každopádně v návrhu aplikace jsou vždycky podstatnější věci k řešení, než ify a switche...

[bohous]

podstata je, ze jde o konzolovou aplikaci, ktera kdyz ma prepinac -p, tak se pouzije nejakej connection string. kdyz se nezada prepinac, tak je pouzitej nejakej default connection string. Ja mam default connectionstring jeste pred podminkou. jine prepinace tam nebudou.

[Reklama]

[Tuxik]

Druhej je lepší, teda kromě toho, že má nějaký rozprasený formátování, protože řeší i zadání více argumentů, což je v tomto případě evidentně chyba.
Vzít výchozí hodnotu a vzápětí ji podmíněně změnit mi taky nepřijde úplně hezký - v tomto případě úplně zbytečný a matoucí.
Nicméně bych tak nějak očekával, že parsování argumentů budou mít vývojáři vychytanější a ne že jej budou řešit takhle jednoúčelově.

[Ondra.]

ten 2. je o fous lepsi, protoze je to  konzistentenjsi... nicmene je to jedno, protoze je to humus tak jako tak. Pro zpracovani parametru prikazove radky existuje 1000+1 knihoven, neni duvod to psat znovu.

[lopata]

Přepsal ti to, protože to máš blbě. Co asi tak ta první varianta udělá, když tu aplikaci zavolám jako?

Kód: [Vybrat]

program -p server -foo

Mimochodem psát si parsování command line je klasický not in house syndrom.

[bohous]

1000+1 knihoven, neni duvod to psat znovu.

mam dotahnout kanon na vrabce? jde o jednoucelovou aplikaci, neni duvod resit parsovani parametru jeste pomoci knihovny. Proc bych to proboha delal? Nevim jak to delate vy, asi naprogramujete i to, co se od vas nevyzaduje. vic parametru neni potreba resit. je jenom jeden parametr.

[lopata]

mam dotahnout kanon na vrabce? jde o jednoucelovou aplikaci, neni duvod resit parsovani parametru jeste pomoci knihovny. Proc bych to proboha delal? Nevim jak to delate vy, asi naprogramujete i to, co se od vas nevyzaduje. vic parametru neni potreba resit. je jenom jeden parametr.

Protože ta knihovna bude narozdíl od tvého řešení odladěná a bez chyb. Víc parametrů bude potřeba řešit hned v další iteraci, věř tomu. S knihovnou to navíc budeš mít hotové rychleji. Člověk, který to po tobě převezme, tě nebude proklínat, protože pracovat se známou knihovnou je mnohem jednodušší, než se hrabat ve tvém prasokódu.

[Ivan Nový]

1000+1 knihoven, neni duvod to psat znovu.

mam dotahnout kanon na vrabce? jde o jednoucelovou aplikaci, neni duvod resit parsovani parametru jeste pomoci knihovny. Proc bych to proboha delal? Nevim jak to delate vy, asi naprogramujete i to, co se od vas nevyzaduje. vic parametru neni potreba resit. je jenom jeden parametr.

A kolik parametrů bude potřeba za 3 roky?

[Tuxik]

mam dotahnout kanon na vrabce? jde o jednoucelovou aplikaci, neni duvod resit parsovani parametru jeste pomoci knihovny. Proc bych to proboha delal? Nevim jak to delate vy, asi naprogramujete i to, co se od vas nevyzaduje. vic parametru neni potreba resit. je jenom jeden parametr.

Kanón na vrabce bych nebral, ale vzhledem k tomu, že jsi to na těch 14 řádcích dokázal zprasit, možná by nějaké vyladěné univerzální řešení bylo lepší a ušetřilo by ti starosti.

[bohous]

To jako vazne??? Ta aplikace se dal rozsirovat nebude, i ted nema poradne zadnej vyznam. Kdyz si dotahnu na vsechno knihovnu, tak jednoducha aplikace bude mit ne 500kb, ale 5mb nebo vic. A kdyz neni potreba osetrovat vic parametru, co je 100% jisty, tak snad nebudu nad tim uvazovat

[bohous]

Novej, ani jeden. Protoze ta aplikace se mozna pouzije ani ne 5x.

[bohous]

mam dotahnout kanon na vrabce? jde o jednoucelovou aplikaci, neni duvod resit parsovani parametru jeste pomoci knihovny. Proc bych to proboha delal? Nevim jak to delate vy, asi naprogramujete i to, co se od vas nevyzaduje. vic parametru neni potreba resit. je jenom jeden parametr.

Kanón na vrabce bych nebral, ale vzhledem k tomu, že jsi to na těch 14 řádcích dokázal zprasit, možná by nějaké vyladěné univerzální řešení bylo lepší a ušetřilo by ti starosti.

Zprasit? Proc myslis? Mel jsme pouzit knihovnu? Ne, neni to zapotrebi. Nemel jsem jeste udelat to vic OOP jak je zvykem se na rootu bavit o OOP?