Ač mám nějaké výhrady, tak bych si rád taky Go vyzkoušel na nějakém hobby projektu, kdybych měl víc času. Některé koncepty - např. gorutiny - se mi hodně líbí a v pozadí hlavy tak trochu přemýšlím, jak se z toho poučit pro zlepšení stávajících projektů.
Je tu ale jedna věc, která mne prakticky odrazuje od jakéhokoliv většího nasazení. Upozorňuji ale, že se to týká něčeho, co je hodně kontroverzní, takže jakékoliv reakce zavánějící flamewarem budu kompletně ignorovat a žádám ostatní komentátory o totéž. Tím je automatické formátování. Resp. to by mi vlastně vůbec nijak nevadilo, ale mám problém s jednou konkrétní volbou - začátek bloku na stejném řádku, jako podmínka, cyklus, funkce, atd. Z určitých důvodů teď pracuji na Drupalu (PHP) a čistě z důvodu konzistence jsem si v IDE (pro vlastní moduly) nastavil automatické formátování dle jejich konvencí, které pracují s bloky stejně, jako Go. A za boha si na to nemohu zvyknout - ten kód je pro mne mnohem méně čitelnější a nijak se mi nezdá, že by se to den-ode-dne zlepšovalo. Když se projeví chyba, tak u běžných programů mám automaticky pocit „ok, tak jdeme na to, stack-trace, popis chyby, ok, ...“, kdežto v tomto projektu to je spíš „néééé, nechci se v tom hrabat“ - i když jsem to napsal před 10 minutami... Zbývající rozhodnutí ohledně formátování jsou mi ale totálně šumák. Už před nějakou dobou mi začalo být jedno jestli mezery nebo taby (ale u nás ve firmě si myslím, že by byly lepší taby, protože kolegové kašlou na auto-formátování a ignorují, když jim tam přibude nebo zmizí nějaká ta mezera a blok se posune), nebo zda 2 mezery VS 4 (Drupal používá 2 a na to jsem si zvykl takřka okamžitě i přesto, že používám 4 mnohá léta). Jen ty bloky nejsem schopný do svého mozku namlátit...
Autoformátování je se dneska prosazuje všude, i v Rustu. Nemluvně o jazycích jako je Python nebo Haskell kde je syntaxe dvourozměrná neboli existuje v podstatě jediný přípustný způsob, jak formátovat kód. Obecně myslím, že to má spoustu výhod. Jednotně formátovaný kód a prostředky, jak to vynucovat, značně usnadňuje správu záplat, mergování, code review atd. a samozřejmě, že je vždycky nějaký detail, který se danému jednotlivci nelíbí a chtěl by ho jinak. Byly věci, které mě v rustovském autoformátování zpočátku vytáčely. Na většinu jsem si zvykl, na některé ne ale zvykl jsem si aspoň pokrčit rameny a neřešit je. Možná by se dalo říct, že do budoucna by na tom nemělo až tolik záležet, protože inteligentní editor, resp. IDE a jeho nástroje, by ideálně měl pracovat na úrovni syntaktického stromu a ne na úrovni řádků textu, ale tam bohužel všeobecně ještě nejsme.
Náhodou, i v Pythonu je dost formátovacích nuancí, nad kterýma se dá v rámci review zhádat :D
Každopádně, osobně mi autoformátování vyhovuje. Začala jsem ho používat právě u Rustu a… Ony jsou ty oblíbené způsoby zápisu hlavně o zvyku. Sjednocení formátování kódu je věc, která za tu chvilku nepohodlí a zvykání si stojí.
„Ony jsou ty oblíbené způsoby zápisu hlavně o zvyku. Sjednocení formátování kódu je věc, která za tu chvilku nepohodlí a zvykání si stojí.“
No a můj problém je v tom, že toto se mi podařilo u úplně všech konvencí (a to celkem rychle), kromě té jedné, kterou jsem zmínil - když „{“ není na novém řádku, pro mne je ten kód výrazně méně čitelnější, mnohem hůř se mi v něm orientuje.
Nebo možná jsem jen netrpělivý? Kolik je „chvilka“? Nad oním projektem jsem strávil už víc, jak 50 hodin...
Edit: překlep
19. 9. 2019, 10:12 editováno autorem komentáře
V Pythonu se také používá autoformátování, problém je, že některé formátovače umožňují zbytečně moc voleb. Formátovač bez voleb podobný gofmt je black. https://github.com/psf/black
nastavení formátovače by každopádně mělo být součástí projektu, nemělo by se o tom diskutovat při review.
19. 9. 2019, 14:34 editováno autorem komentáře
Myslel jsem to tak, že když je kód všude formátovaný stejně, tak se v něm reviewer snáz zorientuje a posupem času s většími zkušenostmi už ho některé potenciální problémy budou samy bít do očí, aniž by musel vyvíjet zbytečně velké úsilí na to, aby zdroják mentálně parsoval. Samozřejmě, že nejde o to, že review by byla ta pravá chvíle se začít hádat, jestli má být někde mezera nebo tab a hestli má být { na novém řádku...
„a samozřejmě, že je vždycky nějaký detail, který se danému jednotlivci nelíbí a chtěl by ho jinak.“
To je mi jasné a právě proto, že tento princip chápu, neřeším ostatní konvence, které se mi tak úplně nelíbí na různých projektech. Když si uvědomím, že to nemá žádný výrazný praktický vliv, tak to hodím za hlavu a vím, že si na to zvyknu. Že snaha s tím něco dělat jsou jednak žabomyší války a jednak by to bylo vlastně dost sobecké a sebestředné. Ale to, co jsem popisoval, vidím jako problém, protože to mi to dlouhodobě překáží. Zpomaluje. A nakonec, vytváří odpor k dané práci (což je o to horší, že je to není projekt ze zaměstnání, ale ve volném čase).
Souhlasím s Vámi - moderní jazyky dnes trpí na "scope creep", zahrnují do sebe funkce, které tradičně byly externí. Např. package management (cargo, pip, gems, ...) podle mě smysl dává, ale integrovaný a povinný linter je už trochu za hranou. Styl psaní je jako dialekt u přirozených jazyků a tak je to jako nutit Ostraváka mluvit hantecem.
To je částečně pravda, ale jakmile se pracuje ve větší skupině nebo dokonce distribuovaně, tak už to zase spíš spadá do kategorie nezbytné kázně. Stejně jako je nějaký pracovní jazyk (nemyslím programovací) a Ostravák, Pražák i Plzeňák si při chytání bugů můžou nadávat každý po svém, ale do mailing listu budou všichni psát spisovnou češtinou, aby si vzájemně rozuměli.
v tom nejdál je Jai, kde je nastavení buildu součástí zdrojového kódu. Zajímavý projekt. Autor vychází ze zkušeností s vývojem AAA her. Vývoj jazyka streamuje na Twitchi.
https://www.twitch.tv/naysayer88/videos
19. 9. 2019, 14:56 editováno autorem komentáře