Daniel Kolman

Co by měl každý programátor vědět

| 18 comments |

Občas mě zarazí, že i lidi, které považuju za dobré programátory, neznají základy programovacího jazyka, ve kterém píšou 95% kódu. Například nedávno v naší kanceláři proběhla debata, proč si StyleCop stěžuje na to, že jsou v kódu nadbytečné závorky. Šlo o složenou podmínku v příkazu if, kde si dotyčný pomáhal závorkami, protože si nebyl 100% jistý s prioritou operátorů && a ||. Co na to říct?

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?

(18) Comments

  1. gorline

    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.

    27. října 2009 v 7:03
  2. MicTech said...

    Dobrý seznam napsal Scott Hanselman o tom co by .NET vývojář měl vědět.

    What Great .NET Developers Ought To Know

    27. října 2009 v 7:09
  3. Rene said...

    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.

    27. října 2009 v 7:29
  4. Borek said...

    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ů :)

    27. října 2009 v 9:36
  5. stej said...

    Dane, jak se z
    if(((age>60)||(disabled==true))&&(balance>limit))
    odstraňuje 8 závorek?

    27. října 2009 v 16:42
  6. Bobris

    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.

    27. října 2009 v 21:31
  7. jenda

    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

    27. října 2009 v 22:44
  8. stej said...

    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ý.

    29. října 2009 v 10:16
  9. Radek Matěj said...

    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?

    29. října 2009 v 11:14
  10. Ali Baba said...

    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.

    29. října 2009 v 18:27
  11. stej said...

    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 :(

    29. října 2009 v 21:56
  12. Radek Matěj said...

    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.

    30. října 2009 v 9:15
  13. Ali Baba said...

    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á.

    30. října 2009 v 12:32
  14. Jirka bianco Vágner said...

    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. :)

    31. října 2009 v 13:21
  15. Anonymous

    proc ne:)

    27. ledna 2010 v 14:46
  16. Anonymous

    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.

    13. února 2010 v 1:29
  17. Anonymous

    souhlas.

    30. června 2010 v 22:03
  18. Brano Goga said...

    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.

    8. dubna 2012 v 21:07

Leave a Response