Aktualizace stylu zápisu zdrojového kódu Linuxu. Maximální počet znaků na řádek zvýšen z 80 na 100

Byl aktualizován styl zápisu zdrojových kódů Linuxu. Maximální počet znaků (sloupců) na řádek byl zvýšen z 80 na 100. Preferováno ale zůstává 80 znaků [reddit].

1.6.2020 00:22 | Ladislav Hagara | Komunita

Komentáře

[Odin1918]

Kdyz mne jeste zivila java pred hodne letyz meli jsme v coding style 140 znaku. Prislo mi to tak akorat.

[Ilfirin]

Na psaní to ok je. Horší je čtení..

[xkucf03]

Mně se i ve FullHD vejde na obrazovku 180 znaků a vedle toho ještě panel s projekty v IDE. Navíc, část lidí má širokoúhlejší displeje, část lidí má dva monitory… Ano, občas se hodí mít dva soubory vedle sebe, ale má smysl optimalizovat pro tuhle situaci a lidi, kteří mají jen jeden neširokoúhlý monitor, a omezovat kvůli tomu všechny ostatní?

[panika]

uzsi text je snazsi na cteni, podivej se jak jsou sazeny knihy/noviny. kod je sice neco trochu jinyho ale ne tak docela..
tady jsem si nasel protipriklad, ale autor testoval prave jen do ty miry co se dnes povazuje za uzky https://www.usability.gov/get-involved/blog/2006/08/line-length-and-onscreen-reading.html
kdy si chci cist treba neco tady, tak si musim dlazdicnout prohlizec na pulku displaye aby mi to nevadilo (treba jsem divnej - anketa?)

[Michal Kubeček]

Já mám prohlížeč na půl obrazovky (nebo něco přes půlku, podle velikosti monitoru) standardně a na celé okno ho rozšiřuju jen u webů, kde to dává smysl (např. mapy.cz) nebo kde je web zprasený tak, že se normálně prozlížet nedá.

[abc]

Kod a normalni text je ale neco uplne jineho. Vetsina obrazovky kodu je prazdna - indentance, new line, radky jen s "}" atp.

Typicky u kodu je vetsina radku obsahove kratka, jen obcas to uleti trochu vys.

[Michal Kubeček]

1. Ta situace, kdy je žádoucí mít vedle sebe dva terminály se zdrojáky, není zdaleka tak mimořádná, jak by se zdálo, a třeba na notebooku, kde si to s rozumnou velikostí písma dovolit nemůžu, je to pro mne dost omezující. Na normálním počítači se pak často hodí i layout s více okny - v práci na dvou 24" monitorech třeba mívám dva užší terminály se zdrojáky a k nim dva širší s crashem, případně dvě terminálová okna a jedno s git gui (s tím se dá vejít i na jeden 27" monitor).

2. Čitelnost není jen otázka toho, jestli se to vejde na monitor. Když si doma na 27" monitoru roztáhnu okno přes celou obrazovku, tak se mám sloupců 318, ale takhle dlouhé řádky bych ve zdrojácích rozhodně číst nechtěl. Těch 100 znaků, zvlášť pokud se to bude používat spíš výjimečně, celkem jde, ale pokud by se mělo ve větší míře rozšířit používání výrazně delších řádků (s výjimkou chybových hlášení, kde se to obvykle tolerovalo i teď), nadělalo by to víc škody než užitku.

[xkucf03]

Těch 100 znaků, zvlášť pokud se to bude používat spíš výjimečně, celkem jde, ale pokud by se mělo ve větší míře rozšířit používání výrazně delších řádků (s výjimkou chybových hlášení, kde se to obvykle tolerovalo i teď), nadělalo by to víc škody než užitku.

Většina řádků se vejde i do těch 80 znaků – a to přirozeně, aniž by se o to člověk musel nějak snažit. Takže nemá smysl to srovnávat s novinami nebo webem, kde máme odstavce souvislého textu (a tam skutečně příliš široké odstavce zhoršují čitelnost). U kódu je otázka, kde mít nastaven ten tvrdý limit, který se nesmí nikdy překročit. A tady bych moc přísný nebyl. Vlastně ani nevím, jestli je nějaký tvrdý limit potřeba…

Dokud se lidi snažili držet do těch 80 znaků, tak ten limit smysl měl, protože i přirozený a rozumný kód by za tou hranicí 80 znaků mohl obsahovat něco zajímavého, co by nemělo zůstat skryto – a pak je dobré říct: radši ten řádek zalomte, ať to nikdo nepřehlédne.

Ale pokud se bavíme o 120, 140 nebo víc znacích, tak v těchto místech prakticky nic zajímavého nebývá – v zásadě to jsou jen nějaké logovací hlášky nebo texty výjimek, nebývá to kód, který by měl vliv na tok programu, takže při zběžném čtení se do těchto míst ani nemusím dívat. I kdybych měl třeba deset úrovní odsazení (což už je fakt hodně… na třídy, metody, IFy, cykly atd.), tak mi pořád zbývá 80 znaků na samotný kód (typicky zavolání metody, předání parametrů, naplnění návratové hodnoty do proměnné) a stále se vejdu do 120. Takže i když se nebudu nijak omezovat, většinou se tam vejdu.

Podle mého by se do nějakých těch 100 či 120 znaků mělo vejít to podstatné, tzn. i když člověk uvidí z každého řádku jen prvních 120 znaků, měl by z toho chápat logiku a tok programu. Za touto hranicí by nemělo být nic záludného, nic překvapivého – za touto hranicí „viditelnosti“ by se nemělo vyskytovat žádné return, throw, nastavování proměnných či i++ atd. Ale když tam bude něco méně podstatného, tak to nevadí – to člověka zajímá až ve chvíli, kdy studuje ten konkrétní řádek (např. upravuje chybovou hlášku). Asi si na to napíši nějaký skript a projdu si svoje zdrojáky :-)

[deda.jabko]

Mně se i ve FullHD vejde na obrazovku 180 znaků a vedle toho ještě panel s projekty v IDE. Navíc, část lidí má širokoúhlejší displeje, část lidí má dva monitory…

Krome argumentu, ktere tu uz zaznely, nizsi hranice poctu sloupcu ma i dulezity psychologicky efekt.

Pro citelnost kodu je docela dulezita zasada -- jeden radek, jeden krok vypoctu (jedna dulezita vec). Kdyz mas nastaveny mensi pocet sloupcu, nuti te to rozdelovat slozite vyrazy na mensi, prirazovat jejich hodnoty do promennych, apod., coz vyznamne zvysuje citelnost kodu.

[Blaazen]

Menší počet sloupců tě taky může přinutit ke kryptickým identifikátorům.

[xkucf03]

Viz výše:

Podle mého by se do nějakých těch 100 či 120 znaků mělo vejít to podstatné, tzn. i když člověk uvidí z každého řádku jen prvních 120 znaků, měl by z toho chápat logiku a tok programu. Za touto hranicí by nemělo být nic záludného, nic překvapivého – za touto hranicí „viditelnosti“ by se nemělo vyskytovat žádné return, throw, nastavování proměnných či i++ atd. Ale když tam bude něco méně podstatného, tak to nevadí – to člověka zajímá až ve chvíli, kdy studuje ten konkrétní řádek (např. upravuje chybovou hlášku).

Ano, narvat na jeden řádek volání pěti metod, inkrementaci proměnné, nějakou tu podmínku a return a throw v alternativních větvích… to je prasárna. Jen nevím, jestli proti tomu bojovat zrovna nějakým tvrdým limitem počtu sloupců.

Ten limit totiž nezohledňuje obsah, ale jen počet znaků. Co když na konci toho řádku (pro někoho za viditelnou oblastí) je jen nezajímavý kód, třeba jen textová hláška nebo jen předání nějakých zjevných parametrů, ale nic, co by ovlivňovalo tok programu?

Taky tam píši:

I kdybych měl třeba deset úrovní odsazení (což už je fakt hodně… na třídy, metody, IFy, cykly atd.), tak mi pořád zbývá 80 znaků na samotný kód (typicky zavolání metody, předání parametrů, naplnění návratové hodnoty do proměnné) a stále se vejdu do 120.

Málokdo se dneska drží klasických 80 znaků, spíš to bývá těch 100 nebo 120. A na tom příkladu vidíš, že tenhle limit tě nijak moc neusměrní, protože pořád můžeš udělat deset úrovní odsazení, což je hodně – jedna úroveň třída, druhá metoda, a pak ti zbývá osm úrovní na IFy, cykly atd. což umožňuje napsat hodně kryptický kód resp. hodně složitou metodu (kterou by bylo lepší rozdělit na víc menších).

[Michal Kubeček]

Obávám se, že část diskutujících zapomíná, že je řeč o specifickém coding style linuxového jádra, tedy požadavcích, které si nedělají ambice být univerzálním pravidlem pro všechny projekty a všechny programovací jazyky. Ostatně ani v tom jádře nebyly a nejsou vyžadovány úplně striktně.

[deda.jabko]

Ano, narvat na jeden řádek volání pěti metod, inkrementaci proměnné, nějakou tu podmínku a return a throw v alternativních větvích… to je prasárna

Nemusis to tak prekombinovavat. Spatne citelny kod ti vyleze i z volani metod, kde nelze rict, ze by neco bylo mene duleziteho. Docela bezne vidam veci typu:

getLoremIpsum(dolor).setAmet(consectetuer.getAdipiscing(), Integer.vulputate).get(a, nibh).rutrum(consequat);

Jen nevím, jestli proti tomu bojovat zrovna nějakým tvrdým limitem počtu sloupců.

Nikde se nezminuji o nejakem hard-limitu. Ten limit by mel byt soft, dejme tomu, 80 + 20, nebo 100 + 20, s tim, ze ten limit lze v oduvodnenych pripadech prekrocit, cim vic tim hur. Bohuzel nekteri programatori s takovou informaci maji problem nalozit a tak vyzaduji nejaky jasny limit.

I kdybych měl třeba deset úrovní odsazení (což už je fakt hodně… na třídy, metody, IFy, cykly atd.), tak

...tak jsi hovado a ten kod je necitelny bez ohledu na delku radku a tudiz ji nema cenu resit.

jedna úroveň třída, druhá metoda, a pak ti zbývá osm úrovní na IFy, cykly atd. což umožňuje napsat hodně kryptický kód resp. hodně složitou metodu (kterou by bylo lepší rozdělit na víc menších).

Jak jsem ukazoval vyse, slozity kod lze vytvorit i bez toho aniz bys potreboval nasobne zanoreni a dlouhe (neomezene) radky to podporuji.

[Aleš Kapica]

Do 140 je to v pohodě. 80 je málo a 100 taky nic moc, ale na druhou stranu je to lepší, při porovnávání stránek. Delší řádky nejsou tak přehledné.

[Koder]

Pro nas co mame monitor na vysku je 120 tak akorat. Vejde cely radek a jeste je vlevo misto na nejake IDE serepeticky.

[*]
charset = utf-8
end_of_line = lf
indent_style = space
indent_size = 2
insert_final_newline = true
max_line_length = 120
trim_trailing_whitespace = true

[Dr. Golub]

Fascinuje mě jak se diskuze o počtu sloupců v terminálu zvrhne v poměřování velikostí displajů/fontů.

Přitom stačí aby editory uměly zalamovat. Když to někdo neumí udělat, tak je snad ještě dnes problém nacvičit nějakou AI, aby to zvládala?

[Michal Kubeček]

A je to tady… :-(

[O'o'yam]

Idealni je mit jednu operaci na radek. Jenomze 80 znaku na to je silene malo. Pokud delam nejakou slozitejsi matematiku rekneme ve dvou smyckach a s if(), tak jenom odsazeni sezere 4 taby (32 sloupcu) a zbyde mi 48.

neco_co_potrebuju = neco_co_uz_mam + neco_dalsiho[poradi] * univerzalni_komstanta_na_neco + sqrt( nejaka_pitomost[x]^2 + nejaka_blbost[x]^2);

A jsem na 142 znacich + 32 odsazeni = 174 znaku.

Fakt vam prijde tole prehlednejsi?

neco_co_potrebuju = neco_co_uz_mam + \

neco_dalsiho[poradi] * \

univerzalni_komstanta_na_neco + sqrt( \

nejaka_pitomost[x]^2 + nejaka_blbost[x]^2);

Nebo tu je samozrejme moznost pouzivat kratsi identifikatory:

np = nm + nd[i] * uk1 + sqrt( nt[x]^2 + nb[x]^2)

Velmi prehledne.

Dalsi moznost je vhodit to do funkce, ktera se vola jednou:

int vypocet_takove_blbosti_ktera_je_potreba_kdyz_se_tentonoc_dostane_tamhle \ (int np, int nm, int nd, int i, int uk1, int nt, in x, in nb){ /*Tohle vlastne fungue tak, ze se udela asi tohle: neco_co_potrebuju = neco_co_uz_mam + \ neco_dalsiho[poradi] * \ univerzalni_komstanta_na_neco + sqrt( \ nejaka_pitomost[x]^2 + nejaka_blbost[x]^2); */ np = nm + nd[i] * uk1 + sqrt( nt[x]^2 + nb[x]^2) }

Nevim, jak vam, ale me se vsechny tyhle obezlicky ctou blbe.

Samozrejme se vzdy najde idiot, ktery na ten radek nacpe 6 operaci. Ale to by se snad lepe resilo omezenim tech operaci.

A ted se muzeme pohadat, jestli je citelnejsi:

for ( i = 0; i < arraylen; i++) array[i] = 0;

Nebo:

if( x > 0 ) sum += x;

A nebo jestli je nezbytne nutne rozepsat na vice radku i tohle,

[Michal Kubeček]

Fakt vam prijde tole prehlednejsi?

neco_co_potrebuju = neco_co_uz_mam + \

neco_dalsiho[poradi] * \

univerzalni_komstanta_na_neco + sqrt( \

nejaka_pitomost[x]^2 + nejaka_blbost[x]^2);

To je snad trochu moc průhledná demagogie, nemyslíte?

        neco_co_potrebuju = neco_co_uz_mam +
                            neco_dalsiho[poradi] * univerzalni_komstanta_na_neco +
                            sqrt(nejaka_pitomost[x] ^ 2 + nejaka_blbost[x] ^ 2);

To je sice 82 znaků, ale kdyby ta "komstanta" neměla záměrně zvolené tak dlouhé jméno, nebyl by problém se vejít do 80 i bez rozdělování toho součinu.

K tomu trojnásobnému odsazení: právě to, že uvnitř takhle hlubokého vnoření ještě stále potřebujete napsat něco takhle komplikovaného, by mělo samo o sobě být signálem, že byste se měl nad strukturu té funkce znovu zamyslet.

Navíc si nemohu nevšimount, že (a) podle použití operátoru "^" a backslashů na koncích řádků ve vašem příkladu nejspíš vůbec nemluvíte o C (takže je otázka, nakolik je váš příspěvek relevantní pro diskusi o coding style linuxového jádra) a (b) podle náhodného výskytu mezer kolem závorek vám očividně nějaký coding style vrásky nedělá.

[rad]

Já sám používám striktně maximální šíři 80 znaků. Nicméně je pravda, že situace, kdy je toto omezení nepříjemné jsou právě (i když ne jenom) matematické výrazy. Tyto nepříjemnosti jsou sice vždy řešitelné, ale někdy bohužel na úkor čitelnosti.

Prvním řešením, které se nabízí je rozdělení výrazu a uložení dílčích výsledků do proměnných. To ovšem často znepřehlední výraz tak, že není na první pohled zřejmé, co se tam vlastně počítá.

Druhým je pak 'zalomení' na více řádků. Tento postup je v principu asi dobře použitelný např. pro polynomiální výrazy, nicméně méně již pro výrazy jiných typů.

Co mě osobně mrzí na té druhé možnosti je situace, kdy provádím více podobných operací na stejných datech či obráceně, a kdy mohu velmi pohodlně porovnat oba řádky a okamžitě vidět v čem se liší.

Ještě bych doplnil, že se nemusí nutně jednat o nějaké super-složité výrazy či dlouhé názvy proměnných či funkcí. Vemte si pro příklad jen takové normální rozdělení (navíc přistupujete-li k jeho parametrům přes atributy):

(1/data.std()*np.sqrt(2*np.pi))*np.exp(-0.5*((data-data.mean())/data.std())**2)

Přesně 80 znaků! Netvrdím, že je to nejlepší příklad, ani že by to nešlo zkrátit (ačkoli jsem byl podle mě ještě dost úsporný). Jen, že se to stává.

Jinak si (stejně jako podle mě většina diskutujících) uvědomuji, že zprávička je o linuxovém jádře, holt se nám ta diskuze trochu rozvolnila, to už se stává.

[Michal Kubeček]

Tohle je podle mne zrovna příklad, kdy by bylo i kvůli čitelnosti mnohem vhodnější si to rozdělit:

/* nějaké komentáře vysvětlující parametry */
static double normal_distribution(double x, double m, double d)
{
        return np.exp(-0.5 * np.sqr((x - m) / d)) / (d * np.sqrt(2 * np.pi));
}

...
        ... normal_distribution(data, data.mean(), data.std()) ...
...

Ten ošklivý výraz stačí napsat a zkontrolovat jen jednou a tam, kde se to použije, je na první pohled vidět, co dělám. On ten coding style jádra nejsou jen takové ty prvoplánové věci jako osmdesát znaků na řádek nebo tabulátory, které se přetřásají v podobných diskusích, ale i o tom, že napsat si takový helper má dobrý smysl, a to dokonce i v případech, kdy se použije jen jednou.

Jinak to, že je řeč o coding style jádra, se snažím zdůrazňovat právě proto, že si nemyslím, že by stejný coding style měl smysl obecně. Svého času jsem třeba napsal pár věcí v C++ Builderu (a dokonce i v Delphi) a radši si ani nezkouším překvapit, jak by to vypadalo, kdybych se tam pokoušel o 80 znaků na řádek s odsazováním po osmi znacích. Proto mi připadá nesmyslné, když vidím lidi argumentovat stylem "Ale v Javě…"

[rad]

Já se vším souhlasím. Hlavně s tím, že coding style je víc než jen maximální počet znaků na řádek a že různé projekty a programovací jazyky mohou vyžadovat jiný přístup.

Takže aniž bych se v tom potřeboval dál rýpat, tak jen stručné vysvětlení toho mého příkladu. Šlo mi o situaci, kdy mám několik velmi podobných výrazů (např. lišících se normováním u té zmíněné distribuce). Pokud je mám zarovnané pod sebou ihned vidím v čem se liší a nemusím porovnávat těla (jinde definovaných) fukcí.

Něco jako:

x1 = 1*p;
x2 = 2*p;

Místo:

x1 = vynasob_parametrem_1(p);
x2 = vynasob_parametrem_2(p);