JARDABEREZA: "s nějakým programovacím jazykem"
by me zajimalo, jestli meli povolena makra. zkousel jsem hledat, ale zadnou extra odpoved jsem nenasel. s VBA uz se toho da delat docela dost

E2E4: to stejne pro C
The International Obfuscated C Code Contest
https://www.ioccc.org/

JARDABEREZA: no nevím, předpokládám, že v tom Excelu je šampion kdo je nejrychlejší, zatímco hodnotit programování je spíš beauty contest se silnými osobními představami porotců co je krásný a spravny. ;)

ale jinak existovala soutěž most obfuscated Perl contest, a nebo na demoscéne kdo nacpe nejakou funkci do co nejmenšího počtu bajtů..

https://www.cbc.ca/radio/asithappens/2024-excel-world-championships-1.7405512 bylo by fajn vidět něco takového s nějakým programovacím jazykem :-D

https://www.nytimes.com/2025/01/20/us/microsoft-excel-world-championships.html

ALMAD: Na Nyxáky mám ty nejvyšší nároky;

ALMAD: Ja se hlasim do teamu ignorantu (fachidiotu?). TIL GL :-)

MAIMONIDES: Pardon za mansplaining, ale moje zkusenost s tim ze vsichni po 40 znaj GL a dokonce se podle toho i chovaj je…nerovnomerna.

ALMAD: Tak, jsme tu 40+, GL všichni znají. Popsat problémy umíme jak nikdo mladší. Hledat jejich praktický řešení je to zajímavý.

MAIMONIDES: Souhlas, a tohle jde zobecnit a zformalizovat :)

Goodhart's law - Wikipedia
https://en.m.wikipedia.org/wiki/Goodhart%27s_law

A když myslím "neví", tak to znamená nedělat přímé závěry z těch měření. Používat je spíš jako podněty k zaměření kvalitativně orientované pozornosti nějakým směrem.

MLEKAR_STEIN: To je nutná podmínka všeho měření, že nesmí nikoho obtěžovat. Ideální taky je, když o něm vývojáři vzásadě neví, aby neměli potřebu naplňovat očekávání měření místo dodávání. Chápu, že to zní paradoxně, ale je to tak.

MAIMONIDES: aspoň že se to dělá relativně samo a není u toho potřeba točit tejden klikou

MLEKAR_STEIN: jak dlouho od otevreni do zavreni, failure rate, jak dlouho v backlogu. Automaticky generovany cisla, kteryma vyvojare moc neobtezujem, protoze jsou uzitecny jen pro srovnani fearurre tymu na stejnym projektu v delsi casove rade a to nemame.

SATAI: Geniální, můžeš splnit pětiletku za půl roku. A pak to promažeš a můžeš zase plnit!

SULTHAN: Jo, to muzu potvrdit, mam kolegy co s prazdnymi radkami setri jak kdyby za ne museli platit. Ale vyrazy se nedelily ani predtim. Takhle alespon mame ty elementarni formatovaci problemy z krku a muzeme se soustredit na to dat pripadne komentare na ty veci co automatizace chytnout nedokaze.

Asi vám závidím. Představuju si, že vše ostatní je fajn a horkotěžko si vymýšlíte co ještě vykazovat a tak prostě řádky.
My nic z tohodle neměříme, maximálně statistiky životního cyklu ticketu v jiře a i to je .. neužitečný. Coding standardy jsou záležitostí týmu a neexistuje tým, který by tam chtěl mít bordel, ale jestli chtěj to nebo ono, to je jedno.


RUDOLF: Relativně ve smyslu, že jsou i horší. Asi jako u poprav.

VOY: Co považuju za problém, že si programátoři moc navykli na "formátovač za mě udělá všechno" a pak musíme při review řešit věci jako "mohl bys tohle oddělit do proměnné", "mohl bys tenhle výraz rozdělit, aby se to dalo přečíst" apod.

Jinak jeden z velkých problémů pro čitelnost je třeba to, když v kódu chybí na specifických místech prázdné řádky. Prettier prázdné řádky neřeší vůbec. Proto říkám, že prettier by se měl minimálně kombinovat s ESLintem, kde si můžeš některé věci donastavit - my třeba máme pravidlo jednoho prázdného řádku mezi bloky kódu (tj. nemáš na sebe nalepené dva ify apod.)

SULTHAN: Citelnost kodu je do znacne miry vec zvyku a co prettier vygeneruje muzes trochu ovlivnit tim jak to zapises. Kazdopadne ale stejne zformatovany kod od vsech contributoru me podle me vetsi hodnotu nez nejaka posledni mile prace, ktera by ten kod udelala o 5% citelnejsi. Chapu, ze se ti nemusi vystup zcela libit, ani mne ne, ale byl bych sokovany, kdyby to automatizovane formatovani cloveka zpomalilo ve cteni nejak vyrazne.