Standard AirBnB se zdá nejpopulárnější.
- AirBnB JS Style Guide
- Idiomatic JS
- Google JS Style Guide
- Jiný
- Vlastní
- ...?
AirBnB i Google vynucují odsazení 2 mezery.
Idiomatic definuje odsazení 2 mezery nebo 2 taby, ale jen jednu variantu napříč projektem.
Jaký standard používáte vy?
Používáte při psaní JS nějaký standard?
Co se právě děje na Webtrhu?
- Daniel Hejna nabízí: Postaráme se o celý online svět. Od tvorby loga až po komplexní webovou stránku
- JiříN poptává: Nette programátor
- Yan poptává: Programování v Rust
Vždycky když zakládám projekt volím z šablon pro eslint AirBnB a to hlavně (ačkoliv se to může zdát úsměvné) kvůli středníkům. Byl by pro mě strašný nezvyk je nepsat. Dál to nějak neřeším a případně opravím to kvůli čemu na mě Eslint řve (případně eslint --fix a je to). Někdy se mi stává, a to se nejspíše bude stávat u všech, že potřebuji obejít chování linteru (pomocí komentářů), což je sice otrava, ale nejspíše to k tomu patří (například když potřebuji využít jenom 2. argument funkce a linter na mě řve, že 1. zůstává nepoužitý a je zbytečný... většinou se ale jedná o API, které nebylo psáno mnou, jsou to závislosti a s těmi nic neudělám).
Jiné standardy ani nepoužívám (ani neznám jejich specifikace podrobně), takže k nim nemám co extra říct.
Standard AirBnB ten povinný středník i rozumně vysvětluje:
When JavaScript encounters a line break without a semicolon, it uses a set of rules called Automatic Semicolon Insertion to determine whether or not it should regard that line break as the end of a statement, and (as the name implies) place a semicolon into your code before the line break if it thinks so. ASI contains a few eccentric behaviors, though, and your code will break if JavaScript misinterprets your line break. These rules will become more complicated as new features become a part of JavaScript. Explicitly terminating your statements and configuring your linter to catch missing semicolons will help prevent you from encountering issues.
1 Tab, který se ovšem vždy zobrazí o jednotné délce 4 mezery. Psát mezery je nepohodlné, psát dva taby je nesmysl, pak se na ten řádek nic nevleze. Dvě mezery je pro mě málo vizuálně, hůř se to čte. Jinak zrovna styl odsazení je ta nejméně důležitá věc vůbec, protože každý lepší editor umí odsazení přeformátovat automaticky. Horší je to třeba s použitím složených závorek, kde mi odlišný styl vadí (především, když je někdo nepoužívá).
Podle toho odkázaného článku se komunita okolo Javascriptu už sjednotila na odsazení o dvou mezerách.
Já jsem z PHP zvyklý na 4 mezery, ale dává smysl dodržovat de facto standard jazyka, i když se mi to třeba taky úplně nelíbí.
Taky jsem bojoval s dměma mezerami. Po dvou letech jsem si zvykl. Taky jsem byl zvyklý na z PHP a CSS na 4 mezery.
mám občas pocit, že komunita kolem JS se zbláznila. Po experimetech nejspíš většina projektů, kde jsem přešla na standardjs.com (https://github.com/standard/standard), který sdružuje všechny zmíněné, navíc obsahuje konfigurace pro IDE a automatické kontroly v rámci testingu.
Přeformátovat odsazení automaticky je pro práci v týmu s verzovacím systémem ta nejhorší věc, co může vývojář udělat, vytvoří to obrovské množství změn, spousty konfliktů při mergování a znepřehlední to historii. Občas to nějakého vývojáře napadne či má jinak nastavený IDE, tak ho hned plácám přes prsty, že v týmu to je dost netýmové :).
JS na 2 mezery přešel podle mě ve velkém s ES6 a špatnými návyky na skladbu kódu a funkcí, kdy zanoření i u velkých projektů atakuje 10. úroveň, pak 4 mezery se nevejdou na obrazovku :). Právě a jen kvůli tomuhle bych ty 4 mezery chtěl vrátit, ať si vývojáři nezvyklají dělat stromečky.
Vždy jsem preferoval taby v jazycích, kde to šlo, i dnes je používám, pokud není společná dohoda jiná. Jejich největší mínus je, že se chovají různorodě v různých prostředích, potřebuji k nim speciální nepřenosné konfigurace pro konkrétní programy, pro práci v terminálu jsou občas pěkné peklo a kód je často nevzhledně rozházený, přináší to zbytečnou komplexitu a nutnost se o to starat, mezery mají v IDE snad jedinou nevýhodu, musím je mazat po jedné.
Absolutní souhlas. U každého nového projektu dávám prettier.io, který se postará o zbytek.Přeformátovat odsazení automaticky je pro práci v týmu s verzovacím systémem ta nejhorší věc, co může vývojář udělat, vytvoří to obrovské množství změn, spousty konfliktů při mergování a znepřehlední to historii. Občas to nějakého vývojáře napadne či má jinak nastavený IDE, tak ho hned plácám přes prsty, že v týmu to je dost netýmové :).