Programator se IMO ma snazit nemit svuj program zbytecne dlouhy
Podstatné je tam to
zbytečně (což se zároveň těžko měří). Ale stejně, jako by program neměl být zbytečně dlouhý, neměl by být ani zbytečně neefektivní. Podle mého názoru je z tohohle pohledu ta transpozice matice už za hranou (pokud by nešlo o prototyp).
smozrejme, se to nesmi prehnat, aby zase neutrpela citelnost
Já to vnímám spíš opačně – program by se měl zkrátit, pokud se tím zlepší čitelnost. A pokud se tím zlepší čitelnost, měl by se naopak prodloužit (pokud to není místo kritické na výkon). Proto by ty výše uvedené příklady, které matici procházejí pomocí cyklů, byly mnohem čitelnější, kdyby tam místo vnořených cyklů byly čtyři funkce pro procházení pole ve čtyřech směrech.
Po pravde vice necitelne mi prijde treba if-else roztahane na 5 radku, prestoze obe vetve vraci trivialni vyraz -> po prevedeni na podm. vyraz v return je to na jeden radek misto 5, kde vice jak polovina jsou zbytecne (priklad z pouzivani JS a bezneho stylu vynucenych slozenych zavorek u if a else).
Tohle já vnímám přesně opačně. Podmíněným výrazům se vyhýbám, pokud to není jednoduchá podmínka a dvě konstanty. Jinak z toho vznikají tři složité výrazy na jednom řádku, je to nepřehledné, musí se řešit priorita operátorů, špatně se to debuguje nebo upravuje. Vynechání složených závorek u triviálních výrazů považuju za chybu – už jsem viděl tolik chyb způsobených tím, že to vypadalo, že je v podmínce složený příkaz, ale on to byl jednoduchý výraz a zbytek pokračoval za ifem…
Jak jsem psal - zadani to splnuje, pro zadana data to funguje, o nejakem skalovani ci omzenenich neni v zadani ani slovo.
Ano, ale to je problém školních úloh, že zadání splňují i velmi hloupá řešení, a často naopak chytrá řešení zadání školní úlohy nesplní (přestože by se v praxi dala použít).
To, co pise nekdo s parserem v Pythonu, to vidim jako chybu zadani
Tohle je ovšem věc, kterou musí umět každý analytik, a také každý programátor, který není jen lepič kódu – rozpoznat, co v zadání je špatně nebo co by tam mohlo chybět, a případně si to se zadavatelem vyjasnit. Zadavatel vždy v zadání požaduje něco jiného, než co chce, a chce něco jiného, než co potřebuje. Ideální je, když nakonec dostane to, co potřebuje, ne to, co chtěl nebo co požadoval.
V praxi se nesetkavam s tim, ze mam presne predepsany algoritmus (ale priznavam, ze to se muze dost lisit, asi jsem spis dev, nez programator, pracuju v male firme, na projektu doslova par lidi, klient setri jak muze a asi bude hrat roli jeste vice faktoru) - vetsinou jde o vyreseni ukolu, ne o implementaci presne zadaneho algoritmu. Stejne tak nemivam zadane vnitrni struktury, omezeni na pouzivane oprace atp. Pokud knihovna vyrazne zkrati dobu implementace, tak navrhnu jeji pouziti a ve vetsine pripadu je to schvalene (maloco z obecnych veci si opravdu musim implementovat sam).
Ano, tohle je dost podstatné a moc nechápu, proč se dnes u programátorů často řeší jenom algoritmy, když už jsou stejně
všechny naprogramované v knihovnách a programátor často potřebuje vědět především to, kde tu implementaci najde hotovou a hlavně jak si ověřit předpoklady té knihovny a jak ji správně propojit se svým kódem a s dalšími knihovnami.
Zobrazit příspěvky
