Podle mého jsou určité základy, které musí každý programátor o svém jazyce vědět. Priorita operátorů podle mně patří mezi ně. Argument, že v jazyce XX nebo YY to bylo jinak, je podle mně zcestný. Programovací jazyky jsou natolik jednoduché, že programátor nemůže mít problém si těch pár věcí zapamatovat. Netvrdím, že musíte z hlavy vědět vše o nějakém obskurním jazyku, který používáte jednou za uherský rok, ale pokud se někdo už několik let živí psaním kódu v C#, musí takové věci znát bez zaváhání.
Co všechno by jste tedy měli vědět o svém hlavním programovacím jazyku?
- Priorita operátorů (!, ++, ||, &&, ?:)
- Jak zapsat hodnotu různých datových typů (0xAF, 123 a 123L, 0.12M a 0.12D)
- Základní konverze na string a zpět (například donedávna jsem považoval za samozřejmost, že každý ví jak konvertovat "FFEEDD" na int, ale byl jsem vyveden z omylu)
- Speciální jazykové konstrukce jako anonymní delegáti a lambda funkce
Tento seznam určitě není kompletní, pokud vás napadne něco dalšího, napište to do komentářů.
Pokud tyto základní věci neovládáte, riskujete dva velké problémy: Budete se pomalu orientovat v kódu ("jakého typu je var a = new[] { 1, 10, 100, 1000 };?"), a při psaní budete používat zbytečné ornamenty (if(((age>60)||(disabled==true))&&(balance>limit))). Druhý problém je o dost horší než první, protože při čtení zpomalujete jen sami sebe. Pokud ale kvůli své neznalosti použijete o 8 závorek navíc, ztěžujete práci ostatním, protože znepřehledňujete kód. Je sice pravda, že ostatní pak nemusí používat svn blame, protože už znají váš styl:-) Být poznat podle stylu kódu ale není nic o co by jste měli stát. A taky budete hodně nadávat na StyleCop:-)))
Pokud neovládáte ani naprosto základní věci, jak chcete přesvědčit ostatní o tom, že jste dobří programátoři?
No ja bych se pridal s tim ze hodne lidi tape v tom jak pouzivat vyjimky, jakej je rozdil mezi throw; a (re)throw e;.
Dalsi kapitola je taky pouzivani using().
No a vubec nejcastejsi nedostatek jsou spatne konstrukce diky neznalosti nebo nedostatecnemu vyuzivani principu OOP.
Bohuzel patrim k dryhemu extremu. Me konstrukce v C# jdou take poznat bez blame. Asi by to chtelo vetsi monitor, aby mi ukecanost kodu prestala vadit.
Dobrý seznam napsal Scott Hanselman o tom co by .NET vývojář měl vědět.
What Great .NET Developers Ought To Know
To, ze by mel vyvojar svuj jazyk dobre znat, je bez diskuze. U zavorek v podminkach si ale nejsem jisty, ze duvodem jejich pouzivani je jen neznalost - ja pouzivam vice zavorek, i kdyz priority operatoru znam. Se zavorkami a spravnym odsazenim mi kod pripada prehlednejsi. Take mam dojem, ze pravidlo "neucte se nazpamet nesmysly jako jsou priority operatoru a pouzivejte radeji vzdy zavorky" je soucasti doporuceni nekterych ucebnic C++ (Eckel). Neznalost priority operatoru me u vyvojaru trapi nejmin - spis mi vadi neschopnost rozumne pracovat s vyjimkami, naprosta neznalost idiomu Dispose, zneuzivani kritickych sekci, vytvareni threadu misto pouziti thread poolu apod.
Ahoj Dane, takový pěkně kontroverzní článek hned po ránu? :)
Myslím, že konkrétně s těmi závorkami se dá bezvýhradně souhlasit jen v docela specifických případech. Neděláte žádný JavaScript? Nemáte nějaké skripty z minulosti v PHP nebo ve Visual Basicu? Co podmínky v SQL dotazech? Když hledáš nějaké řešení na webu, nenarazíš třeba na kód v Javě nebo v Pythonu?
Pokud je odpověď na libovolnou otázku "ano", musíš se potýkat s více jazyky a v tom případě může méně závorek znamenat nutnost strávit čtením kódu o trochu více času (v horším případě dokonce nutnost jít do dokumentace daného jazyka a priority ověřit). Chvilka navíc možná není velký problém, ale porušuje mou oblíbenou zásadu "don't make me think". Jako programátor se chci při čtení kódu zaměřit na celkové flow, ne zkoumat, jak se vyhodnotí ten nebo onen logický výraz. Tobě se čte lépe kód s málo závorkami, mně často naopak (např. výraz z článku chápu okamžitě, bez přemýšlení, ačkoliv obsahuje pro tebe absurdně mnoho závorek; asi bych taky tolik závorek nepoužil, ale v zásadě mi nevadí).
Bod, se kterým naopak velmi souhlasím, je ten poslední. Vývojář by měl znát pokročilé vlastnosti jazyka a využívat je. Takové lambdy nebo "var", například, totiž můžou čitelnost kódu významně ovlivnit. Četl jsem např. nějakou knížku, kde se C# používal jako Java, a bylo to utrpení.
Každopádně je zajímavé vidět, jak máme každý jiné preference. Jestli někdy budu žádat o práci v GMC, před pohovorem mám jasno: nastudovat priority operátorů :)
Dane, jak se z
if(((age>60)||(disabled==true))&&(balance>limit))
odstraňuje 8 závorek?
Ja si ani nepamatuju presne prioritu operatoru Scriptovaciho jazyka Tcka a to jsem ho sam psal ...
Jinak nenutnost blamovani setri cas :-)
Ale je jasny, ze je potreba neco znat, o tom zadna.
To Borek: Treba v C++ tymu v GMC meme prijimaci dotaznicek jiny, i kdyz uz sme ho dlouho netestovali a ani nepredpokladam ze by byl brzo potreba.
jak jde tvuj pozadavek na tyhle znalosti dohromady s 'on site customer' a 'pair everything'. jak mam pak ja,jako zakaznik cist&&reviewovat tvuj kod jestli je business korektni?
Borek-super komentar
Ještě dodatek - myslím si, že použití více závorek než je potřeba, není zase takovej problém. Ono stačí na vhodný místa vložit mezery a je to hned čitelnější.
Co si myslím, že je důležitější - znalost frameworku, ve kterým danej člověk pracuje.
Co je horší - zkoumat, proč v tom výrazu je pár závorek navíc, nebo proč tahle třída existuje a proč dělá to stejný, co už danej framework poskytuje od základu. Anebo nevyužití nějaké techniky, protože ten člověk neví, že je to vůbec možný.
Dane, pouze 1 ze 4 tvých podmínek splňuji na 100%. Opravdu musí programátor znát nazpaměť zápis datových typů? A skutečně je tak podstatné umět zkonvertovat FFEEDD na int?
Já prostě pořád věřim tomu, že kód jednoho programu má vypadat tak, jako kdyby ho napsal jeden programátor za jeden den (za předpokladu že dokáže udržet styl alespoň 8 hodin:-))) Kód s konzistentním stylem se daleko líp čte. Proto mě přidávání nadbytečných mezer, závorek, regionů apod. štve, protože se pak nesoustředim na obsah kódu, ale na jeho formu.
Překvapuje mě, že je to pořád kontroverzní téma. Co je špatnýho na tom chtít, aby lidi co spolupracujou na jednom programu, dodržovali domluvené společné zásady? A proč vymýšlet zásady znova a znova, když existují nástroje jako R#, StyleCop?
Pokud se týká základních operátorů o kterých mluvím, jejich priorita je JavaScriptu, SQL a C# stejná.
jenda: copak my nutíme "on site customer" číst kód? Po našich customerech (=PM) chceme zadání pouze z hlediska "business people"
stej: "stačí na vhodný místa vložit mezery" - se StyleCopem by jsi se se zlou potázal:-)
"Dane, jak se z odstraňuje 8 závorek?"
if(age>60 || disabled==true && balance>limit)
Není to přehlednější?
borek: Tohle podle mě do přijímacího pohovoru nepatří. Je to součást domluvenýho stylu pro konkrétní program, může se lišit firmu od firmy (i když by neměl). Jiná věc je znalost frameworku, ten samozřejmě programátor musí znát. Když někdo neví, že decimal se zapisuje s postfixem M, asi v C# moc dlouho nedělá.
nikdo: Parsování hexa čísel nemusí nikdo znát nazpaměť, ale když má někdo k disposici help, MSDN a Google a napíše tohle: http://screencast.com/t/37xByMJff tak je někde problém.
Zkus si toto zkompilovat a spustit. Pointa mé otázky byla v tom, že z výrazu nemůžeš odstranit 8 závorek, ale jen 6.
int balance = 5;
int limit = 10;
int age = 80;
bool disabled = true;
Console.WriteLine("{0}", ((age > 60) || (disabled == true)) && (balance > limit));
Console.WriteLine("{0}", age > 60 || disabled == true && balance > limit);
//anebo
Console.WriteLine("{0}", ((true || true) && (false)));
Console.WriteLine("{0}", true || true && false);
Pak asi přestávám chápat smysl celýho článku :(
Ano, kód, který jsi publikoval dobře znám, ale to neznamená že musíš znát konverzi z FFEEDD na int. Stačí se zamyslet a pak Google, intellisense a rady kolegů dodělají zbytek. Biflování pravidel tady ničemu nepomůže.
stej: jaj, sám jsem se nachytal na past závorek:-))) Spletl jsem ten příklad, z toho co jsem tam napsal se dá opravdu odstranit jen 6 závorek. To je praktická ukázka toho, jaký jsou závorky zlo. Když se to napíše:
(age>60 || disabled==true) && balance>limit
pak je jasný že tam ta závorka je kvůli prioritě operátorů. Když se tam naházej přebytečný závorky:
((age>60)||(disabled==true))&&(balance>limit)
tak člověk musí počítat závorky na obou stranách, aby zjistil co to teda dělá.
Nevydrzel jsem a taky tu musim prihodit nazor. I kdyz, abych se neopakoval, tak naprosto souhlasim s panackem Radkem Matejem.
Napr. lamba fce jsem potkal ve vice jazycich, vyzkousel .. a nikdy nepouzil. Jak se zapisuji ruzne datove typy potrebuju jedno za 2 roky, takze se to fakt nehodlam ucit nazpamet. A rozhodne jsem za par zavorek navic (ovsem s vhodnym odsazenim mezerou), zakazovat tohle je dle meho zbytecny perfekcionismus a hnidopistvi. :)
proc ne:)
Jo tak alibabo, ty me pripadnes jako dalsi typicky cesky programator - vytahnout naky technicky spek typu jak se zkonvertuje FFEEDD na int, nebo decimal s postfixem - veci ktery pouzijes parkat za zivot. Presne tim ukazes jak ses mistr sveta, ale tam venku alibabo (a ted myslim zahranici a svet kolem tebe) se hraje na to jestli umis myslet a aplikovat znalosti, jaky mas prehled. Dobry programator si veci podobneho razeni dohleda, protoze vi, kde je najit.
Bohuzel ale podle me timto zpusobem nezjistis kvalitu, podle me je asi mnohem dulezitejsi jak stavis program a jak resis problem nez nejaka technicka vychytavka.
souhlas.
No, aj ked prioritu operatorov poznam, zatvorky pouzivam. Citatelnost kodu je pre mna dolezitejsia. Staci stredne dlhy logicky vyraz a pri citani po niekom ocenim plne uzatvorkovany vyraz. Usetri mi kopec casu.