Příspěvky

1

Vývoj / Re:If bez curly brackets?

« kdy: 20. 08. 2025, 19:32:22 »

Jenže tohle udělá i podstatně méně striktní astyle. Jenom když to třeba někde sám zalomím, protože to tam zrovna dává smysl, tak mi to nepřeválcuje.

Myslím si, že my dva se tady dohadujeme jakou barvu má mít přístřešek na kola zatímco zbytek jezdí na mokrých sedadlech .

Vyzkoušeli jsme toho tenkrát v roce 2017 docela dost různých variant a nakonec jsme skončili u clang-format. Je ale docela možné, že astyle nám tenkrát v týmu utekl, protože si jej nepamatuju. Ale zkoušeli jsme teď nástrojů více.

Neřešíme spíš barvu přístřešku, který už dávno stojí?

My právě v práci přecházíme z astyle na clang-format, takže můžu srovnávat.

2

Vývoj / Re:If bez curly brackets?

« kdy: 20. 08. 2025, 16:57:36 »

Nějaká vlastní kreativita (v mezích pravidel, která se ale netýkají jen formátování) se přece očekává a hlídá se to přes code review. Opravdu je cílem ji zkoncentrovat do tokenů mezi whitespacy, nebo je to jen omezení použitého nástroje?

Jenže mi naprosto vyhovuje to, že můžu zdroják libovolně nabouchat jak mi to přijde pod ruku, a pak udělám Ctrl-x Ctrl-s a mám jednotný styl. Tím pádem nemusím přemýšlet nad zalamováním řádků a podobnými nepodstatnými věcmi (forma) a můžu se soustředit jen na funkcionalitu (obsah).

Jenže tohle udělá i podstatně méně striktní astyle. Jenom když to třeba někde sám zalomím, protože to tam zrovna dává smysl, tak mi to nepřeválcuje.

3

Vývoj / Re:If bez curly brackets?

« kdy: 20. 08. 2025, 14:41:45 »

To je opravdu nepředstavitelné, že by si spolu sedli, dohodli se na formátování a každý si to pak nastavil ve svém IDE?

Ano. Pokud ten styl nevynucuje následně CI, tak nemá smysl se o to ani pokoušet, protože každý člověk v týmu do toho přinese nějakou vlastní kreativitu.

Ostatně jde tohle vidět i na novějších jazycích, že mají formátování zdrojáků nativně viz go fmt, a rustfmt.

Bojím se, že na vás clang-format už zanechal stopy.

Díky za pochvalu! :-D

On totiž dotahuje jeden z možných přístupů k formátování do extrému.

Přesně! A je to dobře.

Na tohle jsem přesně narážel. Ona existuje určitá míra formátovací volnosti, kterou odhalíte jen pomocí striktního formátovače a diffu. Když na to kouká člověk, tak je to zformátované dostatečně stejně, aby to při čtení nijak nevadilo.

Můžete to i zaintegrovat do CI. Stačí použít tool, který zdroják "formátuje" místo toho aby ho "rekonstruoval z ASTčka".
Pravidla, která ten formátovač vynucuje, nemusí jednoznačně definovat každou mezeru.

Nějaká vlastní kreativita (v mezích pravidel, která se ale netýkají jen formátování) se přece očekává a hlídá se to přes code review. Opravdu je cílem ji zkoncentrovat do tokenů mezi whitespacy, nebo je to jen omezení použitého nástroje?

4

Vývoj / Re:If bez curly brackets?

« kdy: 20. 08. 2025, 13:07:11 »

Hmm, co když má spolupracovník jiné IDE? Jak se domluvíte na stylu formátování?

Česky?

To je opravdu nepředstavitelné, že by si spolu sedli, dohodli se na formátování a každý si to pak nastavil ve svém IDE?

Je to představitelné, ale zbytečně komplikované - takhle se to dělalo dřív, ještě než existovala moderní IDE kterým stačí dát do git repository soubor .editorconfig a IDE se podle toho nastaví automaticky (a klidně pro každý projekt jinak, čehož dosáhnout se starými IDE ve kterých pracujete na spoustě různých projektů byl velký problém).

Tak jsem se na to koukl. Tohle někdo používá? Vždyť to nic neumí! Akorát nastavit o kolik odsadit a ve které verzi utfka to uložit. Proč se vůbec babrat s nějakým editorconfigem, když drtivou většinu věcí musím pořešit jinak? Tech pár drobností už můžu přihodit.

BTW, ten charset je dobrý vtip. Latin1 nebo nějaké UTFko. Ve chvíli, kdy si můžu vybírat z téhle nabídky, je stejně jediná příčetná volba utf-8.

5

Vývoj / Re:If bez curly brackets?

« kdy: 20. 08. 2025, 08:35:06 »

Hmm, co když má spolupracovník jiné IDE? Jak se domluvíte na stylu formátování?

Česky?

To je opravdu nepředstavitelné, že by si spolu sedli, dohodli se na formátování a každý si to pak nastavil ve svém IDE?

No jo, ale tohle přece vůbec nefunguje v případě, že na jednom projektu dělají aspoň dva lidi. Jiné IDE, jiné nastavení, jiné preference. Formátování se musí dohodnout kolektivně a konsenzuálně, a všichni musí používat stejné formátování a stejnou verzi clang-format[1].

Bojím se, že na vás clang-format už zanechal stopy. On totiž dotahuje jeden z možných přístupů k formátování do extrému.

clang-format totiž zdroják rozemele na prvočinitele a pak ho skládá dohromady. Jako by cílem bylo, aby co možná nejvíce bytů z výsledného souboru bylo vygenerované deterministicky.

"všichni musí používat stejné formátování" ale může znamenat něco podstatně jiného.
Formátování se musí řídit nějakou sadou pravidel, ale ta pravidla musí pokrývat jen důležité věci. Nemusí řešit každou mezeru.

Všiml jsem si toho, když jsme ve firmě přešli z astyle na clang-format. Najednou jsme museli rozhodnout jak formátovat spoustu drobností, které do té doby vůbec nebylo třeba řešit. Astyle na to nesahal a jak to ostatní napsali bylo vždycky dobře čitelné, i když se občas lišili v nějakých drobnostech.

1. Nové verze clang-format mají tendence občas něco rozbít nebo případně opravit věci, které byly rozbité, takže se občas něco změní jenom při změně verze.

Což práve plyne z toho extrémního přístupu, jakým k tomu clang-format přistupuje.

6

Software / Re:Password manager

« kdy: 13. 08. 2025, 10:00:27 »

Zálohu pak řeším především tím, že mám aplikaci na několika zařízeních, kde jsou ta hesla synchronizovaná.

Jen bacha, synchronizace není zálohování. Automatická synchronizace naopak zaručí že pokud jedno zařízení kompletně nezdechne, ale "jen" začne generovat nějaký binární bordel, tak sejme úplně všechno.

7

Vývoj / Re:If bez curly brackets?

« kdy: 20. 06. 2025, 06:13:19 »

Tolik závorek často nemívám ani v celé funkci, přestože je povinně používám. Možná to bylo způsobeno zbytečně hluboko zanořenými podmínkami.

Dost často jsem tuhle prasárnu viděl v případě, že se autor kódu slepě držel zásady že goto je fuj.

Jak už tu zaznělo výše,  typicky ve funkcích, které mají několik málo rozdílných clean-upů je to naprosto legální praktika, která právě vnořená ifová pekla eliminuje.

Místo goto používám return.

Což jde dobře v jazycích, které mají defer/destruktory či něco podobného. Jak je třeba před každým z mnoha returnů udělat úklid, tak to začíná být nepohodlné a náchylné k opomenutí.

8

Vývoj / Re:If bez curly brackets?

« kdy: 19. 06. 2025, 15:59:05 »

A bol som šokovaný, že je zástancom (nielen) if-ov bez curly brackets. Ja som si myslel a dúfal, že táto diskusia je už mŕtva, pochovaná a zabudnutá minimálne od roku 2014.

A co na to říká samotný odkazovaný článek?

Maybe the coding style contributed to this by allowing ifs without braces, but one can have incorrect indentation with braces too, so that doesn't seem terribly convincing to me.

Jo jo, mrtvá, pochovaná a zapomenutá

9

Hardware / Re:USB-C zdroj pro tři notebooky zároveň

« kdy: 17. 06. 2025, 14:35:26 »

Ty tomu ale vubec nerozumis. Ty tlacis tak akorat konektor do diry. To je vse. Proud se nikam netlaci, protoze to je zavisla hodnota na rezistanci spotrebice do ktere privadis napeti viz ohmuv zakon. Tak si ho nastuduj protoze fyzika neni politika. Tj. pokud nevis tak budes akorat za hlupaka.

A víš o tom, že u skutečných zdrojů závisí napětí na proudu, který se odebírá? Nebo že jsou i nelineární zátěže jejichž odpor závisí na napětí nebo proudu? Takže s tou závislou hodnotou to není tak jednoduché?

Jakékoliv "tlačení" nebo "cucání" je neformální zjednodušení. Takže bych byl opatrný s tím, kdo je tady za hlupáka.

10

Vývoj / Re:Je jazyk C skutočne ťažký?

« kdy: 15. 06. 2025, 12:37:30 »

Na rozdíl třeba od C, které má jenom režim "pras jak umíš".

Při práci v C taky fungujou příčetnějí režimy, které krotí ty nejprasáčtějí praktiky. Jen nejsou nijak vynucené jazykem, takže to hlídají lintery, code review a podobně.

11

Vývoj / Re:Je jazyk C skutočne ťažký?

« kdy: 13. 06. 2025, 11:21:18 »

Nedefinované chování umožňuje primitivní operace pokrýt jednou CPU intrukcí. Když bude definované všechno, na každou prkotinu bude knihovní funkce, která bude emulovat operátor přesně každý bit výsledku.

Teď jde použít oboje - rychlý operátor s nejistým chováním, nebo si zavolat funkci a mít výsledek pomalu, ale precizně.

Na tohle by bohatě stačilo implementačně definované chování (jako je třeba u signed dělení). Rozdíl oproti UB je velký :
- To chování se vždycky stane. Překladač nemůže předpokládat, že daná situace ve validním kódu nesmí nastat. Takže opravdu vygeneruje odpovídající CPU instrukce.
- Překladač/platforma musí zdokumentovat, jak se ta operace bude chovat.

Ve výsledku mám jednu CPU instrukci a žádné démony z nosa.

12

Vývoj / Re:Je jazyk C skutočne ťažký?

« kdy: 13. 06. 2025, 09:29:14 »

Raději nedefinované chování, než za každou cenu vymýšlet konkrétní chování, jež nemusí být intuitivní.

Tady nastává jeden praktický problém. Konkrétní chování programu, když to UB přece jenom nastane, dokáže tu neintuitivnost dotáhnout do netušených extrémů.

UB umožňuje autorům překladače doplnit tam nějaké příčetné chování. Ale když to neudělají, tak je to strašná past.

13

Vývoj / Re:Je jazyk C skutočne ťažký?

« kdy: 12. 06. 2025, 16:04:50 »

Co s tím? Vyřeší se to tak, že se RAM zadefinuje od adresy 1 a adresa 0 se ignoruje, abychom se vyhnuli problémům s dereferencí null pointeru. Přijdeme o jeden bajt RAM na mikrokontroléru, ale to je nízká cena za vyřešení problémů s adresou 0 a undefined behavior.

Jo, no naprosto geniální tah. Třeba v případě, že takovej Atmel tam má namapovanej jeden registr je to dobrý fundamentalistický přístup do něj prostě nešahat...

Pragmatický přístup je samozřejmě ten, že se pro některé platformy to nedefinované chování dodefinuje. Přece jenom standard C od tohohle dává ruce pryč a dovoluje naprosto cokoliv.

A důsledek je samozřejmě ten, že něco co embedáci u sebe normálně dělají, je na jiné platfomě recept na katastrofu. Může nastat něco co ani nepřipomíná předpokládaný segfault při přístupu na adresu 0.

14

Vývoj / Re:Je jazyk C skutočne ťažký?

« kdy: 12. 06. 2025, 14:28:54 »

BTW, ještě se tu neobjevil Preprocessor iceberg :
https://jadlevesque.github.io/PPMP-Iceberg/

15

Vývoj / Re:Je jazyk C skutočne ťažký?

« kdy: 12. 06. 2025, 12:44:40 »

Hosi, nepresvedcili jste me. To ze je C nizkourovnovy jazyk, je jasne. Ale proc bych mel psat
a << -1 To je jasny, ze je to undefined behaviour.

O takovém shiftu tady celou dobu nebyla řeč. Mluvilo se o :

Kód: [Vybrat]

a >> 1
kde a je signed integer.