AXTHEB: S pristupem, ze existuje jedine spravne reseni (design projektu) a cokoliv jineho je spatne jsem se setkal. Malokdy ale u 40+. Mas predsudky a nejsou spravne.

Ten slozity format specku ma-ISO normu. Jmenuje se C++ a cist standard je pro valnou vetsinu veci ten nejhorsi zpusob zkoumani jak to funguje.

Vynucovat 1:1 pojmenovani prvku abstrakce proti nejakemu teoretickemu modelu znemoznuje mit kdy abstrakci popisujici cokoliv obecnejsiho nez presne ty entity ktere ten jeden dany model obsahuje. Takze nemit to tak udelane naopak dava perfektni smysl.

QWWERTY: Chápu, je lepší mít jednu nohu než žádnou.

AXTHEB: oh sweet summer child... mimo profesni sw development vypada napr. u nas situace tak, ze:
- kolega radsi vsechno testuje manualne, nez aby vzal kus logu a napsal si test case. naprostou vetsinu lidi, co u nas pisou skripty, se mi nepovedlo presvedcit, ze testy jim usnadni zivot, i kdyz to znamena psat vic kodu. a to i pres to, ze tam maji treba X zanorenych podminek, takze manualni pretestovani je pain
- kolega napsal funkcni script na automaticky troubleshooting. fakt uzitecny tool. a je to ten stejny clovek, co hledal 20 minut, jak vypnout output na stdout, ackoliv o 3 radky niz mel print("")... konverzace vypadala jako "ono se to tam nekde vypisuje". "ok, ukaz mi, ktery radek kodu se spusti, kdyz se to vypise". "no to ja nevim"
- dalsi kolega mi rekl, ze nepise ani komentare, protoze nema dobrou anglictinu a nema mentalni kapacitu na psani komentare, aby v EN daval smysl. kdyz jsem mu rikal, at je pise CZ/SK, protoze lepsi neco nez nic, tak vypadal ochotnejsi zacit aspon uvazovat o jejich psani

a protoze nejsme devs, tak programovani nemame v popisu prace => kvalita kodu se neda pouzit jako metrika pro osobni hodnoceni
aktualne beru kazdy komentar, ktery nekdo nekdy nekam napise. i kdyby byl outdated, tak aspon napovi, co se tam ten clovek snazil delat


moje jedina nadeje je, ze se nas ted snazi zapojit do vetsiho externiho projektu a ten uz ma dopredu nastaveny standardy, takze kdo se zapoji, tak je bude muset dodrzovat

OMNISLASH: myslim ze tihle pro nas delali jako kontraktori. Odevzdali kod uplne nahovno, rozbili co slo ale argumentovali tim, ze naprogramovali presne to co sme zadali a ty veci okolo rozbili de facto schvalne, aby jim jejich kod nejak fungoval. I kdyz nefungoval dobre. A pak se jeden jejich tester hlasil k nam do firmy a hrde poukazoval na to, ze ten kod testoval on

Ja mam teda s komentarema asi dost jinou zkusenost nez vetsina… prijdou mi k nezaplaceni.

Napr. se parsuje syntakticky velmi slozity vstup-mit nad funkci parseFoo popsany format Foo a jeste treba malou ukazku je imo super.

Podobne kdyz je nejaka specka a ted je to implementovano jako par stovek trid, tak mit tak nejak lidsky napsano jakou entitu ze specky trida s podobnym ale ne uplne stejnym nazvem modeluje je zase k nezaplaceni.

Podobne u slozitejsich algoritmu-proste si precist, ze hledame connected components v grafu a stavime z nich jiny graf a jeste jsme prisli na genialni optimalizaci ktera nam zadarmo prekvapive zajisti nejakou vlastnost toho novyho grafu je proste 100x lepsi nez se dozvedet, ze deklarujeme worklist a vrhneme ho do 100-radkovy bohate vetveny smycky…

RUDOLF: U nas ma kazdy package svoji dokumentaci, ktera se meni s kodem, nebo alespon by se mela. Dokumentace celeho produktu se pak builduje z tech partial dokumentaci. Pri buildu se validujou vsechny relativni linky.

AXTHEB: Osobně jsem si jednu dobu myslel něco obdobného, ale změnil jsem názor. Vhodný komentář na příhodném místě může ušetřit spousty času při hledání chyb.

PISKVOR: Rekl bych ze to je presne ten typ komentare ktery u nas nejcasteji piseme.

Tj situace kde na prvni pohled by byla chut to refaktorovat / zjednodust protoze to prece nedava smysl. Ale je tam bohuzel nejaky skryty duvod, at uz je produktovy nebo ciste technicky.

Ostatni situace se snazim radeji samo-dokumentovat treba trochu vic verbose namingem, pokud to jde.