No, ale to jsem v podstate napsal - na urcitych pozicich a zamerenich se naopak preferuje kdyz pouzivate takove ficury jazyka, se kterymi umi delat zbytek tymu. Takove obraty v kodu, ktere jsou na prvni pohled pro vetsinu lidi na dane pozici/zamereni jasne, a pripadne budou jasne i potencionalnimu budoucimu "udrzovateli" kodu. Tomu se rika udrzovatelny kod.
Přijímejte na ty pozice profesionály a spousta takových problémů odpadne. Tady je úskalí spíše u managementu, který bývá těžké přesvědčit o tom, že amatér problémy neřeší, ale rozmnožuje, a tedy že ani 10 amatérů nikdy nevyváží jednoho profíka.
Pokud zbytek týmu neumí používat nástroje ke své práci, tak jste holt do zbytku týmu nabrali špatné lidi. Vřele doporučuji ten čas a úsilí tomu věnovat, protože jak už jsem psal výše, ačkoli je v IT neustále nedostatek lidí, i tak se vyplatí vybírat ty, kteří za něco stojí a něco umějí. Což je asi tak každý desátý, který zavolá. U lidí dodávaných personálkami se situace kupodivu stále zlepšuje.
Navíc si jsem jistý, že << není rychlejší než **.
Pokud použitý procesor nemá násobičku, tak vem jed na to, že to rychlejší je. A to tak, že podstatně.
Tobě opravdu nepřijde přirozenější zapisovat umocňování jako umocňování a ne jako bitový posun? V matematických vzorcích také píšeš 1 << N namísto 2^N?
Ano, jakožto programátorovi mi to připadá přirozenější, pokud mám implementovat výpočet v celočíselné nebo fixed-pointové aritmetice. To je právě ta otázka návyků. A naopak - vidím-li v nějakém takovém výpočtu násobení či dělení, hned to upoutá mou pozornost a přemýšlím, nejde-li to šikovněji.
Ono třeba takové Hornerovo schéma taky není tak přirozené, jako když napíšu sumu mocnin. Ale implementovat výpočet nějaké mocninné řady přesně tak, jak se zapisuje v matematice, protože to je přirozené, to je opravdu na kopanec.
410 Odpovědí
52960 Zhlédnutí