Fórum Root.cz

Hlavní témata => Vývoj => Téma založeno: PanVP 30. 05. 2021, 22:26:02

Název: Zlepšení čitelnosti vlastního kódu
Přispěvatel: PanVP 30. 05. 2021, 22:26:02
Tak předně, nepovažuji se za programátora, ale spíš za přeplaceného elitního prasiče.

Ani nepřekvapují komentáře kolegů, které v průběhu let prostě občas přijdou:
Citace
Číst po tobě kód je jako strkat si do zadku zahradního trpaslíka.
nebo
Citace
Tohle mám číst? Kdybys mě vzal cihlou po hlavě, bylo by to milosrdnější!
a nejnovější
Citace
Tohle jsi dělal ty nebo to je výstup obfuskátoru?
Ten poslední komentář se mě vlastně dotknul...  :P

Máte nějakou rozumnou knížku, ze které i prasič pochopí, jak psát čitelněji?

Což mě přivádí k pár věcem:

EDIT: A abych přišel s trochou do mlýna, tyto konvence vesměs dodržuji:
https://github.com/ktaranov/naming-convention/blob/master/C%23%20Coding%20Standards%20and%20Naming%20Conventions.md (https://github.com/ktaranov/naming-convention/blob/master/C%23%20Coding%20Standards%20and%20Naming%20Conventions.md)
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: Skier 30. 05. 2021, 22:45:06
Máte nějakou rozumnou knížku, ze které i prasič pochopí, jak psát čitelněji?
https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: PanVP 30. 05. 2021, 22:51:02

Googlovat umím taky, ale je dobrá? Četl jsi jí?
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: Pixe 30. 05. 2021, 23:10:24
https://martinfowler.com/books/refactoring.html

https://www.youtube.com/playlist?list=PLggcOULvfLL_MfFS_O0MKQ5W_6oWWbIw5

Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: L.. 30. 05. 2021, 23:20:01
Hele, když otevřeš s časovým odstupem (rok, dva) nějaký svůj zdroják, tak ti připadá jasný, srozumitelný a čitelný? Že se na něj podíváš a hned řekneš "jasně, to je tak a tak"?
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: tecka 31. 05. 2021, 00:18:06
Googlovat umím taky, ale je dobrá? Četl jsi jí?
Clean Code není dobrá, naopak až překvapivě špatná.
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: RDa 31. 05. 2021, 01:00:01
Staci par pravidel:
 - veci komentovat
 - promenne ci funkce pojmenovat vystizne, i kdyz to bude delsi
 - veci neflakat:
   - - kamarad rad resi veci copy-paste zpusobem, ja preferuji deduplikaci kodu do funkci/trid/metod
   - - slozitejsi hierarchie/struktura zdrojaku neni na skodu (tridy tam, kde by to slo udelat naprasaka rovnou)
 - nepouzivat cizi kod (stackoverflow copy/paste), v pripade fakt nutnosti prevzeti uvest zdroj/url

Nemam problem se svym starym kodem - vzdy jsem ho psal abych vzdy vedel ktera bije, ne proto, ze me tlaci prace/deadline/sef atd..  samozrejme pod komercnim tlakem je situace jina.
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: mc2js 31. 05. 2021, 01:46:31
Ahoj,
clean code od uncle Boba beru jako povídku :), takovou velmi obecnou, (ne)zcela objektivní kuchařku.
Kniha dává dobrou perspektivu "jak se stát lepším", něco ve stylu "cesta je cil" .

Uncle Bob mě pomohl zlepšit kód a pracovní návyky.
Coding performance díky psaní (smysluplných >> negumovych) testu, sla dolu.
A jako pozitivní side effect, také populace kostlivců v mé git skříni zamířila směrem dolu :)


Clean code můžeš zkusit na mini část kódu, třeba na foo bar cvičení.
Kód s testy pak postupně upravovat, až ti to zacne dávat smysl.
Něco jako "a pochopím za týden, co jsem zde myslel? Musím opravdu mít komentář?"

Jsi na správné cestě, stačí praktikovat a zbytek přijde sám.
Mě to trvalo přes 6 let, než jsem clean code vzal do rukou, a došlo mě co dělám špatně.
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: Petr Jahoda 31. 05. 2021, 06:11:57
Code Complete 2, mam doma, vyborna kniha, presne se dotykajici se tohoto problemu.
https://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670 (https://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670)

Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: Petr Jahoda 31. 05. 2021, 06:28:36
Jeste me napadla takova vec. Kdysi kdesi jsem cetl neco jako "kod by se mel umet cist jako anglicky text".
Od te doby se snazim psat kod takovym stylem a pokud se podivat na kod stary jakkoliv dlouho, okamzite vim, co to dela.
Napriklad neco jako toto... pricemz logovani jsou pro me zaroven komenty.

Kód: [Vybrat]
if (device.Type == "android") {
     logInfo("Main process for " + device.Name + " started")
     var unprocessedData = downloadDataFrom(device)
     logInfo("Unprocessed data with length of  " + unprocessedData.length + " rows downloaded")
     var processedData = processData(unprocessedData)
     logInfo("Data processed with length of  " + unprocessedData.length + ". Ready for saving to database")
     var saveResult = saveDataToDatabase(processedData)
     logInfo("Main process for " + device.Name + " ended with result: " + saveResult)
}
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: Ink 31. 05. 2021, 06:57:12
Už to tady v podstatě padlo. Zkusím to shrnout sám za sebe:

1. Při programování si uvědomím, co se má dít a ne jak se to má dít. Když se člověk soustředí jenom na to, že "to má fungovat", má podle mě menší tendenci psát jasně čitelný kód.

2. Když něco píšu - ať už identifikátory nebo komentáře, podvědomě si představuju, že to píšu pro ostatní, tedy i svoje budoucí já. Když to píšu "zevnitř", je všechno momentálně jasné a nemusím se starat o to, jak to vypadá. Když píšu kód "zvenčí", vidím, jestli je kód srozumitelný.

3. Než kód pošlu dál, nějakou dobu si s ním hraju, přemýšlím, zda něco ještě nestojí za zlepšení - strukturálně, algoritmicky, názvoslovím...

4. Vždycky stojí za to se sám sebe zeptat, zda - kdybych měl dělat review tohoto kusu kódu - bych to pustil dál nebo opřipomínkoval. Jinými slovy, jestli můj kód je dobrým vzorem pro ostatní.
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: PanVP 31. 05. 2021, 10:09:51
Hele, když otevřeš s časovým odstupem (rok, dva) nějaký svůj zdroják, tak ti připadá jasný, srozumitelný a čitelný? Že se na něj podíváš a hned řekneš "jasně, to je tak a tak"?

No...pokud má člověk čas si s tím hrát, tak ano.
Ale často se dělají úpravy ve spěchu nebo člověk vymyslí řešení, které s odstupem let není tak jasné ::)
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: PanVP 31. 05. 2021, 10:11:25

Asi bych se v tom ztratil  ::)
A to jsem příznivcem logování i komentářů.
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: Lukas1500 31. 05. 2021, 10:22:44
Staci par pravidel:
...
 - promenne ci funkce pojmenovat vystizne, i kdyz to bude delsi
...
Slyšel jsem takový bonmot, že vymýšlet smysluplné názvy proměnných a funkcí zabere třetinu času programování :)
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: redustin 31. 05. 2021, 10:30:37
Slyšel jsem takový bonmot, že vymýšlet smysluplné názvy proměnných a funkcí zabere třetinu času programování :)

To je veliká pravda. S tím souvisí potřeba udržovat správné názvy i při refaktoringu a úpravách. A s tím souvisí potřeba používat pořádné vývojové prostředí, které takové úpravy jednoduše a hlavně spolehlivě zvládne. A také jazyk, který těmto změnám neháže klacky pod nohy...
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: xyz 31. 05. 2021, 10:52:32
Jeste me napadla takova vec. Kdysi kdesi jsem cetl neco jako "kod by se mel umet cist jako anglicky text".
Od te doby se snazim psat kod takovym stylem a pokud se podivat na kod stary jakkoliv dlouho, okamzite vim, co to dela.
Napriklad neco jako toto... pricemz logovani jsou pro me zaroven komenty.

Kód: [Vybrat]
if (device.Type == "android") {
     logInfo("Main process for " + device.Name + " started")
     var unprocessedData = downloadDataFrom(device)
     logInfo("Unprocessed data with length of  " + unprocessedData.length + " rows downloaded")
     var processedData = processData(unprocessedData)
     logInfo("Data processed with length of  " + unprocessedData.length + ". Ready for saving to database")
     var saveResult = saveDataToDatabase(processedData)
     logInfo("Main process for " + device.Name + " ended with result: " + saveResult)
}

Trochu si rypnu. Ten if (device.Type == "android")  je stoprocentne pouze na jednom miste v programu :-)
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: nullpainter 31. 05. 2021, 11:16:46
Tak předně, nepovažuji se za programátora, ale spíš za přeplaceného elitního prasiče.

Ani nepřekvapují komentáře kolegů, které v průběhu let prostě občas přijdou:
Citace
Číst po tobě kód je jako strkat si do zadku zahradního trpaslíka.
nebo
Citace
Tohle mám číst? Kdybys mě vzal cihlou po hlavě, bylo by to milosrdnější!
a nejnovější
Citace
Tohle jsi dělal ty nebo to je výstup obfuskátoru?
Ten poslední komentář se mě vlastně dotknul...  :P

Máte nějakou rozumnou knížku, ze které i prasič pochopí, jak psát čitelněji?

Což mě přivádí k pár věcem:
  • Jak zlepšit čitelnost vlastního kódu?
  • Jak psát tak, abyste se chytli i po dvou letech?
  • Máte oblíbené "krásné" zdrojáky, jejichž čtení vám přivodí extázi a snažíte se psát podobně?

EDIT: A abych přišel s trochou do mlýna, tyto konvence vesměs dodržuji:
https://github.com/ktaranov/naming-convention/blob/master/C%23%20Coding%20Standards%20and%20Naming%20Conventions.md (https://github.com/ktaranov/naming-convention/blob/master/C%23%20Coding%20Standards%20and%20Naming%20Conventions.md)

Tvůj problém je zjistit co se blbě čte či chápe cizím:

- Zeptej se co jim vadí.
- Přečti si po sobě nějaký kód cos psal a který už nemáš v hlavě. Co luštíš?
- Pozor na to co ti říkají že jim vadí. Ze zkušenosti kodéři vytýkají především triviality (závorky, mezery ...) a uchází jim podstatný chyby (leak paměti ...). Setkal jsem se i s tím že mi vytkli že je něco prasárna a až to pak používali tak přišli že to je super - to chápu tak že občas "prasárna = něco co nechápu".

Knížky bych nečet, akorát ti daj do hlavy problémy který nemáš ty ale měl autor. A některý radej pitchoviny (Clean Code je o tom psát milión malých funkcí -> totální špagety kód)
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: premekv 31. 05. 2021, 11:39:20
Jeste me napadla takova vec. Kdysi kdesi jsem cetl neco jako "kod by se mel umet cist jako anglicky text".
Od te doby se snazim psat kod takovym stylem a pokud se podivat na kod stary jakkoliv dlouho, okamzite vim, co to dela.
Napriklad neco jako toto... pricemz logovani jsou pro me zaroven komenty.

Kód: [Vybrat]
if (device.Type == "android") {
     logInfo("Main process for " + device.Name + " started")
     var unprocessedData = downloadDataFrom(device)
     logInfo("Unprocessed data with length of  " + unprocessedData.length + " rows downloaded")
     var processedData = processData(unprocessedData)
     logInfo("Data processed with length of  " + unprocessedData.length + ". Ready for saving to database")
     var saveResult = saveDataToDatabase(processedData)
     logInfo("Main process for " + device.Name + " ended with result: " + saveResult)
}

Podepisuju, myslím, že to bylo v pragmatic programmer? a z té knížky jsem si odnesl zejména toto.

Pro mne jsou tedy základ jsou menší třídy/metody s výstižným pojmenováním (byť někdy delším), nemíchat "granularitu" (jako to má kolega výše, metoda říká provedou se kroky A, B, C a detaily těch kroků v dalších "low level" metodách - ty jsou definované níže po této "high level" metodě, aby se kód četl "seshora dolu").

Dále: komentáře považuji za přeceňované. Když cítím potřebu psát komentář, zkusím se zamyslet nad tím, jestli se kód nedá nějak zlepšit (a nebo testy přidat/zlepšit), aby ten komentář nebyl potřeba.  Ideálně by měla jít funkčnost vyčíst z kódu a z testů (ty by měly dokumentovat, co od kódu čekám a jak reaguje na různé vstupy ). Velmi často pomůže rozdrobení kódu do menších celků a přepis viz odstavec výše. Hodně nepříjemnou vlastností komentářů je totiž to, že zastarávají. Není nic "lepšího" než číst komentář a vidět, že kód (už) dělá očividně něco úplně jiného než je v tom komentáři.

Dále: v zájmu zachování čitelnosti kódu je potřeba někdy spolknout inovativní slinu a "nesnažit se být moc chytrý". Jednak (zne)užití konstruktů jazyka Např. lambda streams - někdy to dramaticky zkrátí a zčitelní kód, ale někdy vidím až příliš  komplexní konstrukce, které by šly přepsat do lidsky čitelnější podoby (i když ten funkcionální zápis je krásný a "co na tom nechápeš"); dále advanced věci (různé binární operace atd.) a zápisy využívajících okrajové vlsatnosti nebo internality jazyka (ano, koukám na vás javascriptaři! :)) Kolega, nebo moje já za rok, spíš ocení třeba delší a "primitivnější", ale čitelnější kód.

Dále: 80 znaků je archaismus, ale občas to řádky zalomit chce (mluvím k sobě, mám máslo na hlavě, kolega řešící diff nějakého mého kódu mi za to nedávno nedával...)
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: sudoguy 31. 05. 2021, 11:40:02
Naštěstí pro mě, když se ke svému kódu vracím, tak se velmi rychle zorientuji v tom co dělá. Kolegové si mi nikdy nestěžovali, naopak mám i zpětnou vazbu, že můj kód se čte příjemně. Uvedu za sebe pár tipů co mě teď napadají z hlavy a není to na slohovou práci.

1. Proměnné vždy nějak výstižně pojmenovat i když to může být dlouhé. Včetně dočasných proměnných ve foreach loopech apod.

To už tu sice padlo, ale chtěl jsem zdůraznit že je třeba je používat opravdu všude. Vždycky miluju, když prolítávám něčí vesměs čitelný kód a vidím tam pak něco takového (viz. příklad). Místo toho abys to prolítl, tak pak vyšetřuješ co tam asi tak může být.

Špatně:
Kód: [Vybrat]
foreach($values as $k => $v){
Lépe:
Kód: [Vybrat]
foreach($persons as $name => $age){
2. Komentáře
Shrnující - Aby člověk pochopil co kód dělá bez toho aniž by ho vůbec četl. U větších projektů k nezaplacení - jdeš prostě po komentářích a neluštíš nic. Čteš to jako knihu :) .
Technické - komentáře k fungování samotného kódu.

Příklad (všimni si, že vůbec nepotřebuješ vidět kód a vidíš co se děje):
Kód: [Vybrat]
# assign variables
...
.
$data = json_decode($_POST['data'],true); # true - get json string into array not object (technicky komentar k prepinaci, aby si nemusel listovat dokumentaci a zjistovat co to dela)
.
...

# verify input
...
.
.
...

# errors detected - return 400 bad request
...
.
.
...

# no errors - put values into DB, return 200 ok
...
.
.
...
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: Petr Jahoda 31. 05. 2021, 11:51:12
Jeste me napadla takova vec. Kdysi kdesi jsem cetl neco jako "kod by se mel umet cist jako anglicky text".
Od te doby se snazim psat kod takovym stylem a pokud se podivat na kod stary jakkoliv dlouho, okamzite vim, co to dela.
Napriklad neco jako toto... pricemz logovani jsou pro me zaroven komenty.

Kód: [Vybrat]
if (device.Type == "android") {
     logInfo("Main process for " + device.Name + " started")
     var unprocessedData = downloadDataFrom(device)
     logInfo("Unprocessed data with length of  " + unprocessedData.length + " rows downloaded")
     var processedData = processData(unprocessedData)
     logInfo("Data processed with length of  " + unprocessedData.length + ". Ready for saving to database")
     var saveResult = saveDataToDatabase(processedData)
     logInfo("Main process for " + device.Name + " ended with result: " + saveResult)
}

Trochu si rypnu. Ten if (device.Type == "android")  je stoprocentne pouze na jednom miste v programu :-)

To jsem si vymyslel za chodu, to neni z zadneho programu. Normalne by byl android nejaky enum, ale pro citelnost teto kratke ukazky jsem tam nechal "android" aby jakoze bylo jasne, co se oproti cemu kontroluje.
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: technomaniak 31. 05. 2021, 12:20:13
Hele, když otevřeš s časovým odstupem (rok, dva) nějaký svůj zdroják, tak ti připadá jasný, srozumitelný a čitelný? Že se na něj podíváš a hned řekneš "jasně, to je tak a tak"?

No...pokud má člověk čas si s tím hrát, tak ano.
Ale často se dělají úpravy ve spěchu nebo člověk vymyslí řešení, které s odstupem let není tak jasné ::)

No myslím, si že L to myslel tak že jestli se v tom zdrojáku zorientuješ např. okamžite, po 10 sekundách, 1 minutě, po 1 hodině či déle.  Já např. mám zkušenost, že doba zorientování je závislá na době co jsem ten zdroják neviděl. Čím starší zdroják tím déle mi trvá než se v něm zorientuji.

Ale to nemění nic na faktu, že mám pomocnou dokumentaci (txt,doc,pdf) k projektu nebo zdrojáku, uvnitř komentáře popisující lokální části kódu,  apod..

Ale nejdůležitější u popisu je hlavně to umět vůbec vyjádřit. Mě se osvědčilo to popisovat co nejstupidněji, pokud možno vyhýbat se odborným termínům(protože se jejich význam v čase může měnit) tak aby to pochopilo i malé dítě nebo debil. I za cenu toho, že popis či komentář bude větší.
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: Lukas1500 31. 05. 2021, 12:23:30
Užitečný komentář :D
Citace
$pomx = $i; //prirazeni indexu do pomocne promenne X
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: Ink 31. 05. 2021, 12:43:44
Užitečný komentář :D
Citace
$pomx = $i; //prirazeni indexu do pomocne promenne X

Tak ono ten příklad kolegy výše (no offense) je trochu podobný:

Kód: [Vybrat]
$data = json_decode($_POST['data'],true); # true - get json string into array not object
Napřed si vymyslím identifikátor, který nic neříká ($data) a pak ještě vysvětluju, jaký význam má true ve 2. parametru funkce json_decode()...
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: Pixe 31. 05. 2021, 14:46:04
Pokud v komentáři popisuju kód, je to špatně a prasácky napsané. Je třeba ho psát způsobem, aby byl self-explaining (pojmenování, jednotná úroveň abstrakce napříč metodou,...).

Nemá smysl komentovat "jak" a "co", ale pokud je to nutné, hodí se budoucímu čtenáři vysvětlit "proč" - komunikovat záměr.

Spoléhat se na pomocnou dokumentaci někde v texťáku, confluence, pdfku... Hodně štěstí  :) Reálně ji ale nikdo neudržuje. To samé platí pro komentáře - lepší žádný komentář, než starý/zavádějící komentář.
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: Jiří Havel 31. 05. 2021, 16:16:05
Pro mne jsou tedy základ jsou menší třídy/metody s výstižným pojmenováním (byť někdy delším), nemíchat "granularitu" (jako to má kolega výše, metoda říká provedou se kroky A, B, C a detaily těch kroků v dalších "low level" metodách - ty jsou definované níže po této "high level" metodě, aby se kód četl "seshora dolu").
Tady bacha, je třeba se zastavit na granularitě, kdy ty low level metody dávají smysl samy o sobě. Pokud se řeže dál, tak to sice jde, ale ty metody jsou silně provázané mezi sebou. Jemně mleté špagety jsou taky špagety.
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: redustin 31. 05. 2021, 16:53:31
Metoda může být klidně použita jen na jednom místě a slouží třeba k vhodnému pojmenování bloku kódu. Navíc se to pak rychleji krokuje při ladění.
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: kanoe22 31. 05. 2021, 18:37:37
1) samo vysvetlujuce pomenovanie premennych, metod a tried

2) nepisat sialene dlhe metody (mal som tu cest s kodom kde som refaktoroval metodu dlhu 600 riadkov kodu, opakujem, kodu, nie kodu + komentarov). Takisto nepisat metody ktorych jedinou ulohou je zabalit volanie dvoch inych metod do jedneho riadku, pretoze povodna metoda bola o riadok dlhsia ako XX maximalne dovolenych riadkov. -> ak s tym ma niekto pri review problem, treba si proste dupnut, vyplati sa to, zvysi sa citatelnost, nebude tam milion metod s cudnymi menami (lebo tie dobre a zrozumitelne su uz zabrane) a kod bude kludne o X percent kratsi.

3) Rozumna struktura tried (podobne ako bod 2, najma jeho druha cast, nemat zbytocne kratke/male veci). Na primitivnu aplikaciu typu konzolova kalkulacka ktoru mate urobit v skole nepotrebujete 25tried aby ste ukazali ze poznate OOP koncept. Stacia vam dve, input_parser a calculator ak uz v zadani po vas OOP chcu. Proste naco mi je trieda ktora ma 2 premenne a k tomu dake 4 metody pracujuce s nimi, ktore su sice ako tak spolu logicky zgrupene ked ich stale mozem mat vo vyssej triede a nenarobi to ziaden problem (musia tam pravdaze logicky pasovat, islo mi o to poukazat ze rozbijat veci na mensie za kazdu cenu lebo "potom to je jasnejsie" je od urcitej hlbky struktury kontraproduktivne).

4) Mysliet pri pisani kodu na to ako sa bude testovat (nehovorim nutne o pouziti TDD, ale mat v hlave aspon matnu predstavu o tom ako na to bude napisany unit/integration test je tiez dobre). Na druhu stranu k tomuto, plati bod 3, pricuchol som si ku kodu, kde sa ocividne vyblaznili a skusali rozne sialenosti, rozne moznosti na aplikovanie DI, struktura tak hlboka ze som myslel ze som si nechal vypisat "tree /" (rozbijali vsetko na co najmensie kusky, aj ked to uz davno nedavalo zmysel). Pridanie akehokovlek kodu bolo tak 50% casu pridavanim novej funcionality, 50% casu opravovanie rozbitych testov. Normalne som sa cudoval ze to je schopne vobec bezat.

5) Komentare na komplikovanejsie casti kodu - nemusi vsetko byt v officialnej dokumentacii metody, ani pred kazdou podmienkou/cyklom/... Je skvele ked su komplikovanejsie metody popisane kludne v ramci jednoho dlheho komentara v tele metody, ala:

//offiko dokumentacia, robim (strucne) toto, vraciam toto
//vstupne parametre a ich popis
NejakaTrieda nejakaMetoda(...){
//tu bude ten spominany dlhy koment
//proste nieco co ludsky vysvetli oc tu kraca aj bez potreby studovania a debugovania kodu
//pretoze niekedy kod nejde napisat tak aby bol zrozumitelny na prvy pohlad

sialene_zlozity_kod();
...
return nejakaTrieda;
}
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: nehalem 31. 05. 2021, 21:08:38
...
<trolling>Možno sú tvoji kolegovia iba LOPATY ktorým robí trochu zložitejší kód problémy a mýlia si ho so zlým kódom.Čo sa dá čakať od lopat ktoré robia za kilo mesačne a dokonca až 8 hodín denne za takú almužnu. Nelopata robí za 300k 4 hodiny MAX! (viac to aj tak mozog profíka NELOPATY nedáva a musí sa odpočívať, šustaním stredoškoláčok, prechádzkami po svojej súkromnej pláži ktorú ako nelopata si kúpite v pohode za hotové alebo šňupaním kvalitnej koky priamo z Kolumbijskej plantáže) a zložitejší kód si v pohode píše na papier kľudne aj za volantom svojho Bugatti Chiron na semafore keď mu napadne niečo geniálne a to si samozrejme počíta do pracovnej doby. Komentáre sú len pre lopaty, rovnako ako dlhé názvy premenných, profíkovi stačí len "val x" a z kontextu je mu okamžite jasné, čo ten kód robí. S pozdravom JavamanSK</trolling>
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: PanVP 31. 05. 2021, 21:31:58

Moc hezký...hezký...
Ale vyřídíme to rychle.
Chceš 55 Euro na hodinu na ŽL?
90% remote. Java? ...pokud máš certifikát z Ajiny, minimum je C1.
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: Mudvy 01. 06. 2021, 00:13:57
Já například čerpám z návyků co jsem se naučil při výrobě rozvaděčů. V elektroplánech je celkem jasná logika jak jsou tvořeny a dá se to aplikovat i na archytekturu a tvorbu zdrojového kódu.

V podstatě je to nemíchání jablek a hrušek ale mít smyslově oddělené oblasti aby bylo jasné kam kouknout když něco hledám. Samozřejmě i za cenu větší pracnosti.

Další inspirací pro mě byla práce konstruktéra. Když děláte velké sestavy a často je editujete také si tvoříte malé celky které jse snáze upravují než když to tvoříte jako jednoúrovňový strom. Navíc například Catie vás dost vyškolí co je a není dobrý přístup. Přijdou změny a člověk zjistí jak špatně si to vymyslel.

Další věc co mě hodně pomáhá je IDE. Používám Visual studio 2017 a když si vzpomenu jak jsem psal v pascalu na střední tak je to nesrovnatelný rozdíl. Tehdy jsem ani nechtěl být programátorem a cokoliv napsat bylo jen procházení dokumentací a hledání syntaxe. Dnes je doba zase dál a už vám ide nehází klacky pod nohy, což hodně pomáhá mít uklizený kód.

Další možnost je vžít se do role zákazníka a jít podle toho co dodám něco vyrábět / používat dál. Například v konstrkuci na féra vzít výkresy a jít si to vyrobit. To pak zažijete osvětu toho jak omezenou představu o srozumitelnosti vaší práce máte. Co je však odlišné od konstrukce je to, že výkresama všechno začíná kdežto napsaným zdrojovým kódem práce končí :D.

Občas na školení používám přirovnání lidského těla k ideální architektůře zdrojového kódu. V lidkém těle také nemáte zaimplementované plíce přes střeva a dolní končetini. Všechno má jasnou funkci, přenos, struktura, data, vstup, výstup apod. A dalo by se říct že je to miliony let laděný systém :).

Ostatně moje zkušenosti jsou jen z projektů které byly v rozsahu do 10 000 řádků. Neumím si představit že bych svým stylem spravoval projekty co mají miliony řádků.


 







Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: redustin 01. 06. 2021, 09:55:43
Srovnání s orgány v těle je pěkné a skoro by to i vypadalo, že se rozdělení bloků v softwaru také není žádná věda. Jenže ty orgány mají ještě řídící vrstvu, kde každý nerv vede pěkně samostatně do centrálního kontroléru - mozku. Co jsem si našel, v krční míše je minimálně milión nervů. Plus některé orgány mají vlastní mini kontroléry přímo u sebe (např. srdce) A to už tak pěkné oddělení do bloků není.  Oddělit datové toky, to je většinou snadné, ale vyřešit distribuované řízení, aby navíc bylo rychlé a efektivní (tj. ne message pro každý signál), to bývá největší starost.

Rozdělení do bloků a vytvoření elegantního API je dle mého názoru na programování to nejobtížnější a vyžaduje cit a zkušenosti.
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: anonacct 01. 06. 2021, 10:54:19
Pokud nějaký jedinec dělá chyby opakovaně a řeší se na každém code review - a tady myslím i to, že nedokáže dát na review kód, který by splňoval nějaké firemní guidelines a coding style, tak vidím jen jedno řešení - pá pá.
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: Kit 01. 06. 2021, 11:54:11
Trochu si rypnu. Ten if (device.Type == "android")  je stoprocentne pouze na jednom miste v programu :-)

To jsem si vymyslel za chodu, to neni z zadneho programu. Normalne by byl android nejaky enum, ale pro citelnost teto kratke ukazky jsem tam nechal "android" aby jakoze bylo jasne, co se oproti cemu kontroluje.

Taky by se dalo napsat
Kód: [Vybrat]
if (device.IsAndroid) ...
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: Kit 01. 06. 2021, 12:08:37
Dále: 80 znaků je archaismus, ale občas to řádky zalomit chce (mluvím k sobě, mám máslo na hlavě, kolega řešící diff nějakého mého kódu mi za to nedávno nedával...)

80 znaků je dobrý softlimit, ještě lepší je 65 znaků. Lépe se to čte.

Zalamování se snažím vyhýbat, raději řádek rozdělím do proměnných, jejichž názvy poslouží jako komentáře a poté je použiji ve výsledném příkazu, který je pak kratší.

Alternativou je důsledné zalomení parametrů volané funkce či metody, aby byly hezky pod sebou, ale tam pak chybí ty komentáře v názvech proměnných.
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: Jiří Havel 01. 06. 2021, 12:26:40
Občas na školení používám přirovnání lidského těla k ideální architektůře zdrojového kódu. V lidkém těle také nemáte zaimplementované plíce přes střeva a dolní končetini. Všechno má jasnou funkci, přenos, struktura, data, vstup, výstup apod. A dalo by se říct že je to miliony let laděný systém :).
Lidské tělo je ukázkový příklad toho, jak vypadá výsledek milionů let flíkování a hákování :)

Světlo jde ke světlocitlivým buňkám v oku skrz vrstvu neuronů a místa, kde díky tomu nic nevidíme, doplňuje "firmware". Třeba chobotnice mají oči navržené příčetně.

Nerv k hrtanu nám vede dolů, kolem aorty a pak zase zpátky nahoru :)

A co za divočiny dělá náš mozek proto, abychom si nevšimli, že při změně směru pohledu chvíli nic nevidíme by vydalo na knihu.
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: Pixe 01. 06. 2021, 12:57:40
Tohle především nemají řešit lidi, ale stroje a nástroje (eslint, checkstyle,...) - ideálně nastavené napříč organizací. Jejich (opodstatněné) porušení pak řešit anotací/při code review.

Počet znaků je pak přímo úměrný velikosti monitorů které vyfasujete ;)

Dále: 80 znaků je archaismus, ale občas to řádky zalomit chce (mluvím k sobě, mám máslo na hlavě, kolega řešící diff nějakého mého kódu mi za to nedávno nedával...)

80 znaků je dobrý softlimit, ještě lepší je 65 znaků. Lépe se to čte.

Zalamování se snažím vyhýbat, raději řádek rozdělím do proměnných, jejichž názvy poslouží jako komentáře a poté je použiji ve výsledném příkazu, který je pak kratší.

Alternativou je důsledné zalomení parametrů volané funkce či metody, aby byly hezky pod sebou, ale tam pak chybí ty komentáře v názvech proměnných.
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: JurajP 01. 06. 2021, 14:11:51
Oplati sa citat knizky od Fawlera?
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: luvar 01. 06. 2021, 15:15:28
Dobry den,
ospravedlnujem sa za nasledovne, ale imho:
Predosle komentare su irelvantne!

Otázka bola, ako písať lepší kód s cieľom, aby kolegovia nespomínali trpazlíkov a anláne otvory... K tomuto je imho jediná cesta. Získať od nadriadeného súhlas s 40 clovekohodinami na mesiac. 20 hodín od pýtajúceho sa a 20 hodín od autora výroku s trpazlíkom. Následne riešiť párové programovanie a diskutovať pri tom na úrovni. Stručné zásady, ktoré si spomínam zhlavy:


PS: S mensou efektivitou je mozne dosiahnut ciastocne rovnaky efekt aj cez code review.
PS2: Je nutné, aby aspoň trochu chcenia bolo aj na druhej strane a aby bol cielom kúsok lepší kód, ako keby ho písal len jeden človek...
PS3: Ak sa rozhodnete pre tento smer, odporúčam venovať cca 1MD naštudovaniu, ako robiť párové programovanie... Ak by to malo byť na viac ako mesiac, tak tomu kludne po mesiaci obetovať aj viac času...
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: Kit 01. 06. 2021, 15:21:05
Tohle především nemají řešit lidi, ale stroje a nástroje (eslint, checkstyle,...) - ideálně nastavené napříč organizací. Jejich (opodstatněné) porušení pak řešit anotací/při code review.

Počet znaků je pak přímo úměrný velikosti monitorů které vyfasujete ;)

Stroj (zatím) nedovede smysluplně pojmenovat proměnnou nebo funkci, která by vznikla rozpadem dlouhého příkazu na větší množství krátkých.

Na velikosti monitoru by vůbec nemělo záležet. Co když si to pak chci číst na tabletu nebo na mobilu?
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: PanVP 01. 06. 2021, 15:54:43

To mi přijde jako velmi rozumný nápad.
Totiž, codereview se nedělá "v grupě", ale jen s vedoucím daného projektu a na refaktorizaci obvykle není ...čas/chuť/zákazník to nechce zaplatit/...
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: Jiří Havel 01. 06. 2021, 16:47:44
Na velikosti monitoru by vůbec nemělo záležet. Co když si to pak chci číst na tabletu nebo na mobilu?
Co by mělo a nemělo je celkem jedno. Záleží nejen na velikosti ale i na dalších aspektech ovládání. I jeden velký monitor je dost bída. Číst kód na mobilu je těžká nouzovka, pro kterou nemá smysl optimalizovat formátování a tím házet vidle do běžného použití.

Pro takovéhle "divné" situace si to můžete prohnat nějakým automatickým formátovačem.
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: listoper 01. 06. 2021, 17:36:55
Na velikosti monitoru by vůbec nemělo záležet. Co když si to pak chci číst na tabletu nebo na mobilu?
Co by mělo a nemělo je celkem jedno. Záleží nejen na velikosti ale i na dalších aspektech ovládání. I jeden velký monitor je dost bída. Číst kód na mobilu je těžká nouzovka, pro kterou nemá smysl optimalizovat formátování a tím házet vidle do běžného použití.

Pro takovéhle "divné" situace si to můžete prohnat nějakým automatickým formátovačem.

Na mobilu sem delal code review jednou... bez toho se obejdu. Ale co treba takovy 3-way diff treba pri merge conflictu?
To mam kazdou chvliku a hrozne me rozciluje kdyz kvuli tomu musim horizontalne scrollovat.
Vetsinou se vejdu do 80 znaku bez premysleni a jsem za to rad.
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: Idris 01. 06. 2021, 17:46:58
Literate programming od Knutha obsahuje zajímavé myšlenky.
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: Pixe 01. 06. 2021, 19:37:45
To ale nikde netvrdím :) - série příspěvků na kterou jsem reagoval byla o počtu znaků, zalamování, zarovnávání... Ostatně to samé platí i pro úvodní příspěvek a v něm odkazované naming-conventions, které za vývojáře taky ohlídá počítač.

Stroj (zatím) nedovede smysluplně pojmenovat proměnnou nebo funkci, která by vznikla rozpadem dlouhého příkazu na větší množství krátkých.

...
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: Jiří Havel 01. 06. 2021, 20:38:20
Na velikosti monitoru by vůbec nemělo záležet. Co když si to pak chci číst na tabletu nebo na mobilu?
Co by mělo a nemělo je celkem jedno. Záleží nejen na velikosti ale i na dalších aspektech ovládání. I jeden velký monitor je dost bída. Číst kód na mobilu je těžká nouzovka, pro kterou nemá smysl optimalizovat formátování a tím házet vidle do běžného použití.

Pro takovéhle "divné" situace si to můžete prohnat nějakým automatickým formátovačem.

Na mobilu sem delal code review jednou... bez toho se obejdu. Ale co treba takovy 3-way diff treba pri merge conflictu?
To mam kazdou chvliku a hrozne me rozciluje kdyz kvuli tomu musim horizontalne scrollovat.
Vetsinou se vejdu do 80 znaku bez premysleni a jsem za to rad.
Tak využít celou šířku monitoru není dobrý nápad nejen kvůli diffům :) Pokud je takových dlouhých řádků nějak moc, tak to smrdí.
Já řešil čistě tu myšlenku, že bych měl u formátování kódu řešit jak to bude vypadat na mobilu nebo tabletu.
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: JurajP 02. 06. 2021, 10:05:33
Q1: Su knizky od Fawlera hodne citania?
Q2: Robit code review v grupe alebo samostatne?
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: Ink 02. 06. 2021, 10:24:24
Q2: Robit code review v grupe alebo samostatne?

Co je code review v grupě? Všichni koukají do stejného kódu najednou a dohadují se, jak to má být?
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: JurajP 02. 06. 2021, 10:54:01
ano, presne tak. skupinka povedzme 4 developerov prezera kod.
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: luvar 02. 06. 2021, 13:03:30
ano, presne tak. skupinka povedzme 4 developerov prezera kod.

Moj subjektivny nazor na toto je, ze je to prilis neefektivne. Jeden schopny koder (poznajuci jazyk, problemovu domenu a idealne i projekt) by mal plne stacit. Pri 4 developroch za jednym monitorom sa to imho zvrhne na offtopic velmi rychlo :)

PS: Ale code review dvoch, ci troch, po sebe iducich ludi by nemusel byt celkom strata casu (ak ide naozaj o extra kvalitu kodu, ktora ma opodstatnenie v letectve, medicine, ci podobne).
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: listoper 02. 06. 2021, 13:17:42

...

PS: Ale code review dvoch, ci troch, po sebe iducich ludi by nemusel byt celkom strata casu (ak ide naozaj o extra kvalitu kodu, ktora ma opodstatnenie v letectve, medicine, ci podobne).

U nas delame code review vzdycky tak 3-4 (nadpolovicni vetsina vyvojaru v tymu + nekdo z venku) i kdyz nejsme mission/life critical.
Code review ma jeste jine benefity krom kvality kodu:
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: PanVP 02. 06. 2021, 13:36:28
skupinka povedzme 4 developerov prezera kod.

A proč ne třeba celá firma?  ::)

toto je, ze je to prilis neefektivne
Přesně tak.

Code review, aby mělo smysl, musí nějakou dobu trvat a účastníci se na něj mají připravit, pročíst si kód.
Představa, že procházím cizí kód za týden - OD ČTYŘ LIDÍ - vlastně pěti (i svůj), protože na codereview se člověk prostě trochu připraví = zabiju tím 5 lidí * 1-2 hodiny každý = celý pracovní den. Resp. zabiju PĚT člověkodní, protože to stejné musí udělat i ti ostatní. Takže jsem ztratil pět člověkodní a to to ještě nezačalo. Plus - nějakou dobu to trvá, takže celkem pět lidí se svým kódem, každý 40 minut? A pak nějaký čas na finální opravy? I kdybych to všechno stihl za jeden den, pořád to musí udělat všech pět lidí a je zabitých 5 pracovních dnů.

Jestli to takhle někdo skutečně dělá, tak musí pracovat leda ve státním.
Nebo plácá.
Nebo tam ty lidi jsou, ale s kódem kolegů se předem neseznámili a vlastně jim je ukradený a chrápou, než na ně přijde řada. Mě teda 1 to 1 přijde jako rozumnější.

A ještě jedna věc, kolegové mají úplně jiný styl.
Často se podívám na kód a vím, kdo ho tam naprasil.
Jejich kód je nejlepší a pak to cpou ostatním, že oni to dělají nejlépe.  ::)

...ale mohu se plést, pletu se často a pletu se rád....
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: xPoli 03. 06. 2021, 19:39:41
Na jednom kontraktu nás bylo v týmu 5 programátorů + leader a code review dělalo většinou ještě víc lidí, než programátorů. Typicky ale byli alespoň 3 programátoři z týmu + leader + architekt. Jelo se podle přísných regulí (MISRA a další), takže něco jako vlastní code style každého jednotlivce neexistovalo, možnost poznat autora podle kódu byla velice omezená. Konkrétně tento projekt nebyl life-critical, ale společnost takové produkty dělá, takže byla laťka dost nahoře.

Pro aspoň 95% programování je tento režim overkill, ale něco to do sebe mělo. Každý pár očí vidí něco jiného, každý vidí různá úskalí - složitost algoritmu v různém zatížení, paměťová náročnost, rizika při paralelním přístupu, priority vláken atp. Pokud se má dělat code review v pravém slova smyslu (ne pečlivý git add -p, když člověk dělá solo), tak osobně bych po výše uvedené zkušenosti šel alespoň na 2:1, protože ten vícenásobný pohled na věc je něco, co se většinou vyplatí a ten čas tím strávený není promrhaný - viz zmiňované distribuované povědomí o kódu, odhalení chyb před začleněním atp. Něco pokryjí testy, ale obecně je kód pouze tak dobrý, jak dobré jsou testy a pokrytí kódu testy ještě nic neříká o tom, že se otestují všechny okrajové podmínky, které v nasazení mohou nastat.
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: Sam Samovic 03. 06. 2021, 20:40:46
No ja nevim ;-) komentare jsou tu a presto imho 99.9% lidi bez explainu netusi ktera bije.

float Q_rsqrt( float number )
{
   long i;
   float x2, y;
   const float threehalfs = 1.5F;

   x2 = number * 0.5F;
   y  = number;
   i  = * ( long * ) &y;                       // evil floating point bit level hacking
   i  = 0x5f3759df - ( i >> 1 );               // what the fuck?
   y  = * ( float * ) &i;
   y  = y * ( threehalfs - ( x2 * y * y ) );   // 1st iteration
//   y  = y * ( threehalfs - ( x2 * y * y ) );   // 2nd iteration, this can be removed

   return y;
}
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: Pavel Stěhule 03. 06. 2021, 20:42:55

Code review, aby mělo smysl, musí nějakou dobu trvat a účastníci se na něj mají připravit, pročíst si kód.
Představa, že procházím cizí kód za týden - OD ČTYŘ LIDÍ - vlastně pěti (i svůj), protože na codereview se člověk prostě trochu připraví = zabiju tím 5 lidí * 1-2 hodiny každý = celý pracovní den. Resp. zabiju PĚT člověkodní, protože to stejné musí udělat i ti ostatní. Takže jsem ztratil pět člověkodní a to to ještě nezačalo. Plus - nějakou dobu to trvá, takže celkem pět lidí se svým kódem, každý 40 minut? A pak nějaký čas na finální opravy? I kdybych to všechno stihl za jeden den, pořád to musí udělat všech pět lidí a je zabitých 5 pracovních dnů.

...ale mohu se plést, pletu se často a pletu se rád....

U kritických aplikací se tohle běžně dělá - nicméně jsou to úplně jiné ceny. U Postgresu se dělá review každého patche na několika úrovních a běžně se kód přepisuje 10-100x. Nicméně ten kód pak budou používat milióny lidí. Review kódu odděluje okresní přebor od první ligy. Je to jeden z ukazatelů, jak poznat slušnou firmu. V několika firmách v republice jsem to zažil. Samozřejmě, že pokud má firma na jednom produktu jednoho programátora, tak nemá cenu dělat code review, ale tam těžko bude kdokoliv za cokoliv ručit. Máte aplikace, kdy za neplánovaný výpadek se platí penále v jednotkách miliónů, a code review je základ pro kvalitní kód. Záleží, kdo code review dělá a jak. Ale i tak, je tam psychologické hledisko. Špičkový programátor neprasí, ale takových je málo. Normální programátor neprasí, pokud ví, že jeho kód bude číst někdo jiný, a že pokud ho neodsouhlasí, tak ho bude přepisovat.
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: xyz 03. 06. 2021, 23:28:32
No ja nevim ;-) komentare jsou tu a presto imho 99.9% lidi bez explainu netusi ktera bije.

float Q_rsqrt( float number )
{
   long i;
   float x2, y;
   const float threehalfs = 1.5F;

   x2 = number * 0.5F;
   y  = number;
   i  = * ( long * ) &y;                       // evil floating point bit level hacking
   i  = 0x5f3759df - ( i >> 1 );               // what the fuck?
   y  = * ( float * ) &i;
   y  = y * ( threehalfs - ( x2 * y * y ) );   // 1st iteration
//   y  = y * ( threehalfs - ( x2 * y * y ) );   // 2nd iteration, this can be removed

   return y;
}

Protoze jsou blbe pojmenovane promenne. Nazvat promennou number muze jen uplny zacatecnik.
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: anonacct 03. 06. 2021, 23:45:11
Legendární Quake rsqrt - ten komentář tam je jen pro lidi, kteří chápou, co se tam děje :)
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: anonacct 03. 06. 2021, 23:48:18
Code review je důležitý - minimálně 2 lidi by ho měli dělat (1 je většinou málo, ale záleží i na velikosti teamu)

Code review tě naučí psát kód tak, aby prošel, a taky tě naučí unést kritiku, což je pro některé jedince celkem důležité.
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: Ink 04. 06. 2021, 06:48:34
No ja nevim ;-) komentare jsou tu a presto imho 99.9% lidi bez explainu netusi ktera bije.

float Q_rsqrt( float number )
{
   long i;
   float x2, y;
   const float threehalfs = 1.5F;

   x2 = number * 0.5F;
   y  = number;
   i  = * ( long * ) &y;                       // evil floating point bit level hacking
   i  = 0x5f3759df - ( i >> 1 );               // what the fuck?
   y  = * ( float * ) &i;
   y  = y * ( threehalfs - ( x2 * y * y ) );   // 1st iteration
//   y  = y * ( threehalfs - ( x2 * y * y ) );   // 2nd iteration, this can be removed

   return y;
}

Protoze jsou blbe pojmenovane promenne. Nazvat promennou number muze jen uplny zacatecnik.

Jo, psal to nějaký Carmack nebo kdo.  ;D

Na druhou stranu bych si tipnul, že dnes to vidí jinak než v devadesátkách. Nejenom co se týče stylu psaní, ale dost vyzdvihnul výhody psaní v Rustu. Ta odmocnina je vcelku sranda, jelikož se tam nešachuje s pamětí, nemutují data apod. a je vcelku zřejmé, co dělá (zadání) i zda to dělá dobře (podle výsledků). V takovém kódu snad ani ty identifikátory nejsou špatně (byť nejsou v souladu s rozumnými obecnými konvencemi).
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: xyz 04. 06. 2021, 09:08:10
No ja nevim ;-) komentare jsou tu a presto imho 99.9% lidi bez explainu netusi ktera bije.

float Q_rsqrt( float number )
{
   long i;
   float x2, y;
   const float threehalfs = 1.5F;

   x2 = number * 0.5F;
   y  = number;
   i  = * ( long * ) &y;                       // evil floating point bit level hacking
   i  = 0x5f3759df - ( i >> 1 );               // what the fuck?
   y  = * ( float * ) &i;
   y  = y * ( threehalfs - ( x2 * y * y ) );   // 1st iteration
//   y  = y * ( threehalfs - ( x2 * y * y ) );   // 2nd iteration, this can be removed

   return y;
}

Protoze jsou blbe pojmenovane promenne. Nazvat promennou number muze jen uplny zacatecnik.

Jo, psal to nějaký Carmack nebo kdo.  ;D

Na druhou stranu bych si tipnul, že dnes to vidí jinak než v devadesátkách. Nejenom co se týče stylu psaní, ale dost vyzdvihnul výhody psaní v Rustu. Ta odmocnina je vcelku sranda, jelikož se tam nešachuje s pamětí, nemutují data apod. a je vcelku zřejmé, co dělá (zadání) i zda to dělá dobře (podle výsledků). V takovém kódu snad ani ty identifikátory nejsou špatně (byť nejsou v souladu s rozumnými obecnými konvencemi).

Ok, beru zpatky, jsem se trochu unahlil :-))
- Carmack neni az tak uplny zacatecnik asi :)
- nazev number v matematicke funkci je ok.
- vyvoj her je specificky a kdyz by ke kazde funkci psali komentar ve stylu doxygen (javadoc), tak by to dodelali nekdy za 50 let.

Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: xyz 04. 06. 2021, 09:21:17
No ja nevim ;-) komentare jsou tu a presto imho 99.9% lidi bez explainu netusi ktera bije.

float Q_rsqrt( float number )
{
   long i;
   float x2, y;
   const float threehalfs = 1.5F;

   x2 = number * 0.5F;
   y  = number;
   i  = * ( long * ) &y;                       // evil floating point bit level hacking
   i  = 0x5f3759df - ( i >> 1 );               // what the fuck?
   y  = * ( float * ) &i;
   y  = y * ( threehalfs - ( x2 * y * y ) );   // 1st iteration
//   y  = y * ( threehalfs - ( x2 * y * y ) );   // 2nd iteration, this can be removed

   return y;
}

Protoze jsou blbe pojmenovane promenne. Nazvat promennou number muze jen uplny zacatecnik.

Jo, psal to nějaký Carmack nebo kdo.  ;D

Na druhou stranu bych si tipnul, že dnes to vidí jinak než v devadesátkách. Nejenom co se týče stylu psaní, ale dost vyzdvihnul výhody psaní v Rustu. Ta odmocnina je vcelku sranda, jelikož se tam nešachuje s pamětí, nemutují data apod. a je vcelku zřejmé, co dělá (zadání) i zda to dělá dobře (podle výsledků). V takovém kódu snad ani ty identifikátory nejsou špatně (byť nejsou v souladu s rozumnými obecnými konvencemi).

Ok, beru zpatky, jsem se trochu unahlil :-))
- Carmack neni az tak uplny zacatecnik asi :)
- nazev number v matematicke funkci je ok.
- vyvoj her je specificky a kdyz by ke kazde funkci psali komentar ve stylu doxygen (javadoc), tak by to dodelali nekdy za 50 let.

Jeste bych dodal, ze jestli jsem to pochopil spravne, tak jde o nejakou aproximaci SQRT, tak aby byla co nejrychlejsi a davala rozumne vysledky.
Pokud by to bylo treba v nejake numericke knihovne, tak by si to komentar zaslouzilo. Na cem je ten trik zalozen atd....
Ale ve vyvoji her na to neni cas.
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: Petr Jahoda 04. 06. 2021, 09:33:06
Tady je to pekne vysvetleno https://www.youtube.com/watch?v=p8u_k2LIZyo (https://www.youtube.com/watch?v=p8u_k2LIZyo)
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: Jiří Havel 06. 06. 2021, 16:12:13
No ja nevim ;-) komentare jsou tu a presto imho 99.9% lidi bez explainu netusi ktera bije.

float Q_rsqrt( float number )
{
   long i;
   float x2, y;
   const float threehalfs = 1.5F;

   x2 = number * 0.5F;
   y  = number;
   i  = * ( long * ) &y;                       // evil floating point bit level hacking
   i  = 0x5f3759df - ( i >> 1 );               // what the fuck?
   y  = * ( float * ) &i;
   y  = y * ( threehalfs - ( x2 * y * y ) );   // 1st iteration
//   y  = y * ( threehalfs - ( x2 * y * y ) );   // 2nd iteration, this can be removed

   return y;
}

Protoze jsou blbe pojmenovane promenne. Nazvat promennou number muze jen uplny zacatecnik.
Nee, problém není v pojmenování proměnných ale v komentářích co jsou úplně na hovno.

Kdyby v těch komentářích bylo že tím shiftem dělí exponent dvěma, jak došel k té magické konstantě kterou vylepšuje tu počáteční aproximaci (klidně pokus omyl, co já vím) a že je to iterace Newton-Raphson metody, tak se v tom vyzná i ne úplně hvězdný programátor.

Edit : Koukám, že jdu s vysvětlením pozdě. Pišu si dočíst thread až do konce :D
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: A.P.Hacker 06. 06. 2021, 16:23:34
Ja jsem velky zastance doctestovych komentaru. Jakekoliv komentare s vyjimkou doctestu a typovych anotaci jen duplikuji kod, stavaji se casem neaktualni.

ocenil bych v teto diskuzi odkazy na konkretni projekty na githubu, za me treba standardni knihovna cpythonu pouziva doctesty.

https://github.com/python/cpython/blob/main/Lib/collections/__init__.py
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: Idris 06. 06. 2021, 22:07:39
Co je code review v grupě?
Je to jako review v monoidu, jen méně obecně.
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: urvaru 07. 06. 2021, 06:35:51
Ja jsem velky zastance doctestovych komentaru. Jakekoliv komentare s vyjimkou doctestu a typovych anotaci jen duplikuji kod, stavaji se casem neaktualni.

ocenil bych v teto diskuzi odkazy na konkretni projekty na githubu, za me treba standardni knihovna cpythonu pouziva doctesty.

https://github.com/python/cpython/blob/main/Lib/collections/__init__.py

Tu je obsirny framework https://github.com/Tapyr/tapyr (https://github.com/Tapyr/tapyr), kde su vsetky testy spravene len cez doctesty. Priklad: https://github.com/Tapyr/tapyr/blob/4235fba6dce169fe747cce4d17d88dcf4a3f9f1d/_TFL/Filename.py#L106.
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: Jan Karasek 07. 06. 2021, 14:03:48
kdyz jsem procital diskuzi, tak jsem si rikal, jestli je rok 1980.

Ale tenkrat vlstne root jeste neexistoval. No nic, asi ten vyvoj nejde tak rychle - tedy jak jsem si to ja kdysi predstavoval.

Pred nedavnem jsem byl u znameho ve firme. Tam jsem ve vyrobni hale na stolech videl taky takove predpisy, navody, pracovni postupy, jak je co treba delat. Rikali tam tomu vykres. Bylo dost prekvapive, ze kazdy tem navodum rozumnel - dokazal je cist. A dokonce ani neznali toho, kdo ty navody(programy  :)) ) psal.
Ani tam nepouzivali tu metodu, jak ji tady nekdo propaguje v diskuzi, totiz ze by u soustruhu stali 2 zamestnanci a delali by na jedne veci spolecne.
Co je podobne je ten review - to u tech vykresu taky nekdo dela, je tam dokonce kolonka, kde ten kontroler napise jmeno a datum. Ale jenom jeden a asi to kontroloval jen na jedne urovni , ne jako u toho postgresql.
Co jsem take nevidel byly  komentare. A kdyz, tak jsou porad stejne ... to je divne ???
 
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: BoneFlute 07. 06. 2021, 14:19:06
kdyz jsem procital diskuzi, tak jsem si rikal, jestli je rok 1980.

Ale tenkrat vlstne root jeste neexistoval. No nic, asi ten vyvoj nejde tak rychle - tedy jak jsem si to ja kdysi predstavoval.

Pred nedavnem jsem byl u znameho ve firme. Tam jsem ve vyrobni hale na stolech videl taky takove predpisy, navody, pracovni postupy, jak je co treba delat. Rikali tam tomu vykres. Bylo dost prekvapive, ze kazdy tem navodum rozumnel - dokazal je cist. A dokonce ani neznali toho, kdo ty navody(programy  :)) ) psal.
Ani tam nepouzivali tu metodu, jak ji tady nekdo propaguje v diskuzi, totiz ze by u soustruhu stali 2 zamestnanci a delali by na jedne veci spolecne.
Co je podobne je ten review - to u tech vykresu taky nekdo dela, je tam dokonce kolonka, kde ten kontroler napise jmeno a datum. Ale jenom jeden a asi to kontroloval jen na jedne urovni , ne jako u toho postgresql.
Co jsem take nevidel byly  komentare. A kdyz, tak jsou porad stejne ... to je divne ???

Dělal jsem čtyři roky ve fabrice. Když jsem nastupoval, ptal se mě ředitel, zda rozumím výkresům - no, učil jsem se to, no.
Pak jsem pravidelně chodil za mistrem s tím, ať zavolá zadavateli, že na tom plánu jsou tyhle kóty dvakrát, rozporné, a tady zase rozměr chybí.

Tož asi tolik k tvému příspěvku :-)
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: Ink 07. 06. 2021, 15:35:25
kdyz jsem procital diskuzi, tak jsem si rikal, jestli je rok 1980.

Ale tenkrat vlstne root jeste neexistoval. No nic, asi ten vyvoj nejde tak rychle - tedy jak jsem si to ja kdysi predstavoval.

Pred nedavnem jsem byl u znameho ve firme. Tam jsem ve vyrobni hale na stolech videl taky takove predpisy, navody, pracovni postupy, jak je co treba delat. Rikali tam tomu vykres. Bylo dost prekvapive, ze kazdy tem navodum rozumnel - dokazal je cist. A dokonce ani neznali toho, kdo ty navody(programy  :)) ) psal.
Ani tam nepouzivali tu metodu, jak ji tady nekdo propaguje v diskuzi, totiz ze by u soustruhu stali 2 zamestnanci a delali by na jedne veci spolecne.
Co je podobne je ten review - to u tech vykresu taky nekdo dela, je tam dokonce kolonka, kde ten kontroler napise jmeno a datum. Ale jenom jeden a asi to kontroloval jen na jedne urovni , ne jako u toho postgresql.
Co jsem take nevidel byly  komentare. A kdyz, tak jsou porad stejne ... to je divne ???

Až na to, že programování není soustružení. Narýsovat hřídel je rutinní záležitost a obrobit podle výkresu válcovitý dílec v zásadě taky. Jenže u programování se nejen vždy znovu vynalézá kolo, to se montuje do celé sestavy a to často za běhu motoru a s cestujícími na palubě, ale během cesty se z původního stroje stává často něco zcela jiného, než bylo původně zamýšleno a zdokumentováno.
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: Jan Karasek 07. 06. 2021, 16:23:41

Dělal jsem čtyři roky ve fabrice. Když jsem nastupoval, ptal se mě ředitel, zda rozumím výkresům - no, učil jsem se to, no.
Pak jsem pravidelně chodil za mistrem s tím, ať zavolá zadavateli, že na tom plánu jsou tyhle kóty dvakrát, rozporné, a tady zase rozměr chybí.

Tož asi tolik k tvému příspěvku :-)

ano, je to presne jak pises. Aniz by si znal toho zadavatele si mohl okamzite zjistit kde jsou v tom kodu chyby a samozrejme si take chapal o co jde. A i ten mistr a ti ostatni tomu take rozumneli ... atd , atd ...

Uprimne receno jsem ani necekal, ze nekdo ty moje myslenky podpori.
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: Jan Karasek 07. 06. 2021, 16:28:41

.... Jenže u programování se nejen vždy znovu vynalézá kolo, to se montuje do celé sestavy a to často za běhu motoru a s cestujícími na palubě, ale během cesty se z původního stroje stává často něco zcela jiného, než bylo původně zamýšleno a zdokumentováno.

a tenhle nesmyslny styl prace vylepsime tedy tim, ze budeme psat srozumitelnejsi komentare, budeme psat jen 65 znaku na radku .... ?
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: BoneFlute 07. 06. 2021, 17:26:15

.... Jenže u programování se nejen vždy znovu vynalézá kolo, to se montuje do celé sestavy a to často za běhu motoru a s cestujícími na palubě, ale během cesty se z původního stroje stává často něco zcela jiného, než bylo původně zamýšleno a zdokumentováno.

a tenhle nesmyslny styl prace vylepsime tedy tim, ze budeme psat srozumitelnejsi komentare, budeme psat jen 65 znaku na radku .... ?

Ano.
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: Idris 07. 06. 2021, 18:58:15

.... Jenže u programování se nejen vždy znovu vynalézá kolo, to se montuje do celé sestavy a to často za běhu motoru a s cestujícími na palubě, ale během cesty se z původního stroje stává často něco zcela jiného, než bylo původně zamýšleno a zdokumentováno.
a tenhle nesmyslny styl prace vylepsime tedy tim, ze budeme psat srozumitelnejsi komentare, budeme psat jen 65 znaku na radku .... ?
Ano.
Lepením k lepším zítřkům, aneb s 65 znaky na řádek budeme lepit lépe a radostněji :)
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: Ink 07. 06. 2021, 19:26:14

.... Jenže u programování se nejen vždy znovu vynalézá kolo, to se montuje do celé sestavy a to často za běhu motoru a s cestujícími na palubě, ale během cesty se z původního stroje stává často něco zcela jiného, než bylo původně zamýšleno a zdokumentováno.

a tenhle nesmyslny styl prace vylepsime tedy tim, ze budeme psat srozumitelnejsi komentare, budeme psat jen 65 znaku na radku .... ?

Ten "nesmyslný styl práce" je dán byznysovým nastavením, na to má programátor malý nebo žádný vliv. Může se, v rámci svých kompetencí, snažit situaci zlepšit na vymezeném prostoru.

Je samozřejmě možné, že jsem nepochopil, co jsi chtěl říci, ale za pravděpodobné považuju, že jsi zvolil špatný příměr a tudíž bych byl rád, kdybys přišel s lepším vysvětlením, jak si představuješ správné psaní kódu a jak to v reálu zajistit.
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: registrovany_ava 09. 06. 2021, 09:30:18
Přidám ještě jednu věc, o které se divím, že tu explicitně nepadla: Psát unit testy a nemilosrdně refaktorovat.

Unit testy tě donutí kód psát znovupoužitelně a rozdělit ho na smysluplné části (protože je tím pádem nutné ho použít alespoň ze dvou míst, z produkčního kódu a z testovacího kódu). To je hrozně důležitý.

Unit testy ti umožní refaktorovat kód, který se ti nelíbí - a to se stává pořád - vrátíš se ke staršímu kódu, nerozumíš mu, protože už to nemáš tolik v hlavě, nebo se ti něco nelíbí něco čeho sis nevšiml, tak to upravíš tak, aby to dávalo lepší smysl. Tohle neustálé vylepšování je podle mě povinnost, bez které se z projektu časem stane břečka. Super kód se často nepíše na první dobrou, ale iteruje se k němu. Nebo něco, co byl super kód dřív, přestane dávat smysl a musí se to trochu předělat kvůli novým byznys požadavkům. Unit testy ti dají důvěru a svobodu nutnou k tomu, aby jsi mohl kód upravovat a nebál se, že něco rozbiješ. To je hrozně důležitý.
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: kotelgg 16. 06. 2021, 11:49:58
Zlepšení přijde samo, pokud se ke kódu musíš vracet a přidávat nové věci. A občas se musí napsat aplikace znovu, když ti investor nebyl schopný říct reálný stav věci a jelo se to hurá stylem  ;D  (jakože to měl být jen import katalogu do účetnictví a nakonec je z toho srovnávač cen alá heuréka a když je v to v jednom souboru, tak se to celkem blbě spravuje)
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: PanVP 22. 06. 2021, 12:54:05

Dovoluji si citovat z jiného vlákna:

https://www.sqlstyle.guide/

Moc pěkně a uceleně napsaný popis pro SQL.
(Zatím jsem to jen prolétl očima, ale naformátované to vypadá výrazně lépe, než dlouhá špageta.)
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: nehalem 22. 06. 2021, 16:36:13
Přidám ještě jednu věc, o které se divím, že tu explicitně nepadla: Psát unit testy a nemilosrdně refaktorovat.

Unit testy tě donutí kód psát znovupoužitelně a rozdělit ho na smysluplné části (protože je tím pádem nutné ho použít alespoň ze dvou míst, z produkčního kódu a z testovacího kódu). To je hrozně důležitý.

Unit testy ti umožní refaktorovat kód, který se ti nelíbí - a to se stává pořád - vrátíš se ke staršímu kódu, nerozumíš mu, protože už to nemáš tolik v hlavě, nebo se ti něco nelíbí něco čeho sis nevšiml, tak to upravíš tak, aby to dávalo lepší smysl. Tohle neustálé vylepšování je podle mě povinnost, bez které se z projektu časem stane břečka. Super kód se často nepíše na první dobrou, ale iteruje se k němu. Nebo něco, co byl super kód dřív, přestane dávat smysl a musí se to trochu předělat kvůli novým byznys požadavkům. Unit testy ti dají důvěru a svobodu nutnou k tomu, aby jsi mohl kód upravovat a nebál se, že něco rozbiješ. To je hrozně důležitý.
Unit testy su uplny zaklad, ale realita je tragicka. Bud sa na to vo firmach uplne serie alebo mas programatorov, ktori si mylia unit testy s integracnym a funkcionalnymi testami a nedochadza im, ze unit testy sice v nazve maju slovo 'test', ale je to skor taka pomocka ako navrhnut dobre API, metody, rozhrania, zapuzdrenost atd. Dalsia vec, kedy uz konecne na trh pridu programatori ktori budu chapat, ze otestovatelnost je uplne legitimna poziadavka na kod a dobry kod by ju mal splnat. V praxi som vzdy videl iba uplne spraseny kod pri ktorom nikto nemyslel na to, ze by bolo fajn ho napisat tak aby sa dal aj pomerne dobre otestovat a na tom sa aj krasne ukazuje ako unit testy pomahaju dobre navrhnut rozhrania pretoze kod ktory sa zle testuje je na 90% hovnokod.

Ono celkovo je realita co sa tyka testovania neskutocne tragicka pritom dobre testy vedia v dlhodobom horizonte vyvoj velmi urychlit a zabezpecit podla mna lepsie prijmy pre firmu ktora nebude musiat plytvat mandaymi na fixovanie blbosti ktore by testy hravo odhalili. Ale to by zas musel niekto chapat, ze setrit na testoch je ukazkovy priklad setrenia na nespravnom mieste, ale deje sa to furt, ak pracujete niekde, kde sa to nedeje, tak si tu pracu vazte a budte radi, ja som na vlastnej kozi zazil aj takych "expertov" co zamergovali do mastru kod ktory si ani neskusili zbuildit a tak to aj vyzeralo. A pritom toto su take veci, ze mne to pride ako uplny zaklad, ani by mi nenapadlo v zivote zamergovat nieco do ostrej branche co som si ani neskusil zbuildit a rucne pretestovat, nechapem odkial sa ti ludia beru a ako je mozne, ze im niekto da peniaze za taku "pracu".

"Unit testy ti dají důvěru a svobodu nutnou k tomu, aby jsi mohl kód upravovat a nebál se, že něco rozbiješ. To je hrozně důležitý."
toto plati obecne o testoch a nie len unit testoch. zazil som to len raz, ale je omnoho lepsie robit zmeny, ked viem, ze mam komplet integracnu, regresnu a unit sadu testov takze ak by som nedopatrenim nieco rozbil tak sa to neukaze az v produkcii, ale krasne pocas vyvoja, len to este vysvetlit tym ludom ktori rozhoduju o tom na com sa bude robit a ako alokovat programatorov.
Název: Re:Zlepšení čitelnosti vlastního kódu
Přispěvatel: luvar 22. 06. 2021, 16:47:45
Přidám ještě jednu věc, o které se divím, že tu explicitně nepadla: Psát unit testy a nemilosrdně refaktorovat.

Unit testy tě donutí kód psát znovupoužitelně a rozdělit ho na smysluplné části (protože je tím pádem nutné ho použít alespoň ze dvou míst, z produkčního kódu a z testovacího kódu). To je hrozně důležitý.

Unit testy ti umožní refaktorovat kód, který se ti nelíbí - a to se stává pořád - vrátíš se ke staršímu kódu, nerozumíš mu, protože už to nemáš tolik v hlavě, nebo se ti něco nelíbí něco čeho sis nevšiml, tak to upravíš tak, aby to dávalo lepší smysl. Tohle neustálé vylepšování je podle mě povinnost, bez které se z projektu časem stane břečka. Super kód se často nepíše na první dobrou, ale iteruje se k němu. Nebo něco, co byl super kód dřív, přestane dávat smysl a musí se to trochu předělat kvůli novým byznys požadavkům. Unit testy ti dají důvěru a svobodu nutnou k tomu, aby jsi mohl kód upravovat a nebál se, že něco rozbiješ. To je hrozně důležitý.

Amen...

Unit testy nútia k rozumným konštruktorom a potláčajú zverstvá ako posúvanie dát cez environment property (či inú ľudovú tvorivosť) a ich prítomnosť dáva určitú istotu pri refaktoringu. TO je tiež dôležité (ako už bolo napísané).