Názory k článku
Nově může mít zdrojový kód linuxového jádra více než 80 znaků na řádek

Proč psát nudle? 100 znaků je málo i na fullhd monitoru na výšku...
Silně nenávidím zejména definice funkce o třech parametrech na 5 řádků za čímž následuje zvráceně zalamovaný kód funkce... to vše s prázdou pravou polovinou obrazovky...
Pochopím, když je to nutné, ale 80 znaků... se rozšíří na 100 a to je jako dost? CRT monitor s rozlišením 1024 x 768 zvládne víc :D

Situace, kdy je potřeba (nebo aspoň velmi výhodné) mít vedle sebe dvě nebo více oken se zdrojáky, jsou častější, než myslíte.

ja osobne mávam v IDE splitnutý view na 2 až 3 stĺpce, 120 znakov sa mi bežne zmestí aj tak. Navyše IDE pri väčšom počte vie sam prispôsobiť zobrazenie a zalomiť tie riadky. Napríklad vo VS Code existuje nastavenie "editor.wordWrap": "on".

1. 6. 2020, 11:34 editováno autorem komentáře

Ale 80 znaků na řádek je v době dnešních monitorů fakt hodně přitažené za vlasy...

Stejné to má i Postgres. Ten má ale 4mezerové taby.

Kód v Cčku by neměl být moc široký.

[hawran.diskuse]
To je podle me o tom na co je kdo zvykli a jaky ma styl prace.

Pokud muzu si to rozhodnout sam, uz leta mam nastaveny limit 100 znaku na lajnu (tyka se to kodu, komenty neomezuji). A snazim se to dodrzovat. Vetsinou, s tim zadne problemy nejsou. Obcas vsak potrebuji napr. zmensit okno editoru (treba protoze potrebuji zaroven sledovat vystupy, nebo nejake informace ve vice dalsich oknech, a porovnavat to s kodem) a pak se to automaticky zalomi na nekolik radku, nebo proste cast radku neni videt. At tak nebo tak, je to potom hnus fialovy, zvlast v zanorenych blocich . V C/C++ to jeste jakztaz se skripenim zubu jde, ale treba v pripade Pythonu, nebo Lua je opravdu des se v tom vyznat. :(

2. 6. 2020, 00:01 editováno autorem komentáře

Technika bez pochyb zvládá daleko víc než 100 znaků. Toto opatření plní ale ještě druhou roli: vede programátora k zamyšlení se nad přehledností kódu. Příliš dlouhé řádky (a/nebo) přílišné vnoření může signalizovat problém. Stanovením takového pravidla.

Více např. zde: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Documentation/process/coding-style.rst?h=v5.4.43

Rationale: The whole idea behind indentation is to clearly define where
a block of control starts and ends. Especially when you've been looking
at your screen for 20 straight hours, you'll find it a lot easier to see
how the indentation works if you have large indentations.

Now, some people will claim that having 8-character indentations makes
the code move too far to the right, and makes it hard to read on a
80-character terminal screen. The answer to that is that if you need
more than 3 levels of indentation, you're screwed anyway, and should fix
your program.

Nerozporuji přínosy limitu, ale je třeba zhodnotit, jestli je 80 relevantní v současných jazycích a prostředích. To číslo pochází z dob Fortranu a začátků C, kdy název proměnné byl často 1 znak, volané funkce měly znaků pár. Nemusí to nutně fungovat v jazycích, kde píšeme názvy podstatně delší, používáme spousty knihoven, jmenné prostory, kde je najednou i hloupé přiřazení na 60 znacích :-)

Ostatně... přesně to píše Linus v odkazovaném mailu, a proto rozhodnul tak, jak je v titulu.

Docela chápu, že je lepší stanovený limit posouvat pomalu a postupně, zpět už by to nešlo. Myslím, že brzy budou jasné dobré i špatné zkušenosti ze změny 80 => 100.

Tady je ale řeč o specifickém coding style linuxového jádra, ne o nějakém dokumentu, který by si dělal ambice definovat univerzální pravidla pro všechny projekty ve všech jazycích.

To je slozity,

Treba v Jave se pouzivaji delsi nazvy identifikatoru nez v Ccku. Pak se muze stat, ze nekdo zamerne zkracuje nazvy promennych aby se do tech 80 znaku vesel. Treba ISC-DHCP server ma jednu cast kde veskere promenne maji jedno-pismenne nazvy.

Přílišné vnoření MŮŽE znamenat problém, ale ten limit způsobí problémy i když bude ospravedlnitelné.

Tak noviny taky zvládnou text od levého kraje k pravému, přesto je článek rozdělen do sloupců. Ale ať jsme blíže k monitoru, ani na webu nebývá text článku od jednoho kraje ke druhému. Na čitelnost ty dlouhé nudle nejsou nic moc, alespoň pro mne.

Otázka není co je možné, ale co je praktické. On někdo s horším zrakem a hrubším zobrazovačem bude mít problém "dohlédnout" konce řádku ... a použít zalamování konců řádek není u zdrojáku dobrý nápad ...

Pokud editujete ve fullscreen okně na fullhd monitoru, tak ho doporučuji otočit o 90 stupňů ... uvidíte ten rozdí. ;-)

Ja mel na skole jednu spatnou zkusenost. Vramci projektu jsme prevzali cizi program a ten mel samozrejme chyby. Jednu chybu jsme hledali hodne dlouho. Nekolik lidi nekolik dnu. To bylo za dob Turbo C v DOSu. No a nakonec jsme to nasli. Slo o to ze tam na radku bylo vice prikazu a nektere odsazne o 100 i vice znaku. Takze jsme videli prikaz co neco udelal ale zaroven v tom samem kroku zmenil neco jineho. To bylo fakt flustrujici tohle.

No ale to se má řešit jiným pravidlem, než počtem znaků na řádku, ne? C má speciální pasti - operátor čárky, neblokové a blokové větve v podmínkách, dost problematický příkaz switch+break... Ideálně by to měl hlídat linter, ať už samostatně nebo někde v IDE.

linter (navic v IDE) z "dob Turbo C v DOSu"? :) Nojo, kdyz nemate chleba, jezte kolace :)

Rozhodně jsem neměl v úmyslu doporučovat stroj času. Předpokládal jsem, že původní komentář toto považuje za obecný problém, se kterým se musíme potenciálně potýkat i dnes.

Správci Devuanu teď budou muset forknout i kernel ;)

Myslím, že v případě kolize s kometou, třetí světové nebo jiné apokalypsy by děrné štítky asi nepřežily. Snad vytesat kód do kamene...?

...ale rychlo, lebo pri tesani do kamena uz potom moze byt tych 100 znakov problem :-)

No jedna z teorii je zapis do DNA. Ta je neznicitelna.

Nikdo neříká, že ty děrné štítky nemůžou být z plechu. Běžný pozink běžnou kometu přežije.