Kodstandard till JavaScript (dbwebb javascript-style-guide)

Vi behöver en kodstandard (styleguide för kod) till JavaScript, som fungerar i browser och server samt förhåller sig vettigt till ES5 och ES6 samt har fungerande konfigfiler till jscs och jshint. Vårt behov spänner över kurserna javascript1, linux, dbjs, webapp, ramverk1, ramverk2.

Jag kikade och fann dessvärre ingen befintlig kodstandard som jag ville välja för utbildningssyfte. På gott och ont så får det bli en egen kodstandard som styrs efter vårt behov och delvis kan influeras av de kodstandarder vi redan använder inom Python och PHP, med korrekt och best practice JavaScript.

Så, innan hösten är här, så behöver vår nya kodstandard hamna i version 1.0, för att användas i kurserna. I nuläget finns den i v0.9.1 och inkluderar den variant av jscs som vi använder idag tillsammans med delar av jshint. Dock är större delen av jshint konfigoptionen ännu inte beskrivna. Man kan säga att arbetet är startat, vi är på gång.

När kodstandarden närmar sig v1.0 så behöver respektive kursrepo anpassas så att det matchar styleguiden.

Du finner vår kodstandard, "JavaScript Style Guide", dbwebb kodstandard för JavaScript (javascript-style-guide), på:
* GitHub
* npm

Vill du bidra så läser du CONTRIBUTE.md.

Eller fråga, diskutera och bidra här i tråden, eller skapa en ny tråd om du tror att diskussionen kan bli lång.

Ser ut som vi behöver flytta från jscs till eslint. Det får bli inför hösten.
http://eslint.org/blog/2016/04/welcoming-jscs-to-eslint

Skadar inte att ha koll på hur andra ser på läget bland javascript linters.
http://www.npmtrends.com/jshint-vs-esli ... nt-vs-jscs

Det gick rätt smidigt att konvertera till eslint från jscs. Men det är en ny värld av options som skall ses över. Alla testerna passerar nu både jscs och eslint.

Det kan vara värt att kolla in prettier. Kom nu under våren. Det är inte bara en linter utan även en kodformaterare. Det verkar som om den snabbt börjar bli populär, såg ett klipp från reactconf där dom annonserade att dom använder den på reacts kodbas. Själv har jag använt liknande i Elm vilket var accelererande för mitt lärande. Finns ett liknande även i golang som i princip blivit industristandard.
https://github.com/prettier/prettier

Nu slår vi snart på validering med ESLint enligt denna "kodstandard", det gäller alla kursrepon som kan innehålla JavaScript.

Nuvarande version av kodstandarden är v0.9.7 och exempelprogrammen i kursrepot javascript1 är uppdaterade och motsvarar de guidelines som definieras.

Enligt nuvarande regler för jscs krävs ett mellanslag efter nyckelordet function och dess parenteser. Det känns väldigt främmande när man kommer både från PHP och python, där parenteserna ska sitta fast i funktionsdefinitionen.

Som ett exempel så kräver alltså jscs att det ska vara function (x, y) istället för function(x, y)

Kod: Markera allt

var moveBaddie = function (x, y) {
};

Direktivet att ändra på skulle i så fall vara requireSpaceAfterKeywords, och då kanske bara för ordet function men inte de andra.

Jag tror att motiveringen till mellanslaget är att man lättare ska se skillnad på en definition och ett anrop. Det är en rimlig motivering. Men eftersom det inte egentligen har någon påverkan på kodens exekvering och att vi dessutom använder flera andra språk samtidigt som inte vill ha det där mellanslaget så röstar jag för att vi inte kräver mellanslag i Javascript heller.

Jag skulle även vilja ändra på direktivet key-spacing som just nu inte tillåter extra mellanslag mellan nyckel och värde.

Den lättläsliga koden:

Kod: Markera allt

    partAsElement = {
        "hill":     document.getElementById('hang_hill'),
        "gallow":   document.getElementById('hang_construction'),
        "rope":     document.getElementById('hang_rope'),
        "body":     document.getElementById('hang_body'),
        "rightarm": document.getElementById('hang_rightarm'),
        "leftarm":  document.getElementById('hang_leftarm'),
        "rightleg": document.getElementById('hang_rightleg'),
        "leftleg":  document.getElementById('hang_leftleg'),
        "head":     document.getElementById('hang_head')
    };

Blir därmed ganska svårläst:

Kod: Markera allt

    partAsElement = {
        "hill": document.getElementById('hang_hill'),
        "gallow": document.getElementById('hang_construction'),
        "rope": document.getElementById('hang_rope'),
        "body": document.getElementById('hang_body'),
        "rightarm": document.getElementById('hang_rightarm'),
        "leftarm": document.getElementById('hang_leftarm'),
        "rightleg": document.getElementById('hang_rightleg'),
        "leftleg": document.getElementById('hang_leftleg'),
        "head": document.getElementById('hang_head')
    };

Det ser ut som att man kan sätta direktivet till align på något sätt för att istället tvinga den mer lättläsliga koden. Kan det vara något?

Låter rimligt. Vi kör på det. Kodstandarden är nu i v0.9.8.

* Eslint allow values to be aligned in object properties declaration.
https://github.com/canax/javascript-sty ... 52c7d03b95

* Jscs not require space after keyword function.
https://github.com/canax/javascript-sty ... e52f0f7b83

En väldigt bra inspirationskälla är

https://www.npmjs.com/package/eslint-config-airbnb

Används flitigt inom industrin.

En väldigt bra inspirationskälla är

https://www.npmjs.com/package/eslint-config-airbnb

Används flitigt inom industrin.

Här är dess struktur,:
https://github.com/airbnb/javascript

Jämför gärna med vår variant.

Har funderat mer på det där med function() vs function (). Det blir faktiskt bättre med mellanslaget än utan. Det tydliggör att funktionen är anonym, namnlös. PHP använder inte namnlösa funktioner på det sättet.

Kanske borde krävas ändå, så att man får upp ögonen för att det spelar roll, så att man får möjligheten att fundera över det.

Jag använder Vim, och syntastic för lint.
Här är en länk för hur det går att få in jshint till vim & syntastic:

https://stackoverflow.com/questions/473478/vim-jslint#5893447

Och här är instruktioner för att få in jscs:
https://coolaj86.com/articles/jscs-jscsrc-vim-syntastic-and-you/

... om det nu råkar vara någon annan kan med vim.

Hej.

Parallellt med denna kursen kommer jag läsa andra JS-kurser som kör efter Javascript Standard Style, https://standardjs.com/.
Det går lite på tvärs och använder bara 2-space-indent och utan semikolon. Det går även att installera som plugin till Atom och VScode.
Om jag använder det, kommer linten att slå bakut helt och hållet?

Ha en bra dag.
Mvh Thomas

Hej.

Parallellt med denna kursen kommer jag läsa andra JS-kurser som kör efter Javascript Standard Style, https://standardjs.com/.
Det går lite på tvärs och använder bara 2-space-indent och utan semikolon. Det går även att installera som plugin till Atom och VScode.
Om jag använder det, kommer linten att slå bakut helt och hållet?

Ja, det låter som det kommer slå bakut.

Inget i sammanhanget är direkt fel, men den kodstandard vi använder bygger på 4 mellanslag. Lite osäker på om den klagar på missade semikolon, men den "borde" göra det.

Men, i kursrepot ligger de filerna som gäller för det repot. Om man öppnar editorn utifrån just det repot så bör den använda de konfigurationsfiler som ligger i det repot. På det viset kan man jobba med sin texteditor, utan att behöva göra inställningar för olika kodstandarder, inställningarna ligger i filer i repot.

mos skrev:

Ja, det låter som det kommer slå bakut.

Inget i sammanhanget är direkt fel, men den kodstandard vi använder bygger på 4 mellanslag. Lite osäker på om den klagar på missade semikolon, men den "borde" göra det.

Men, i kursrepot ligger de filerna som gäller för det repot. Om man öppnar editorn utifrån just det repot så bör den använda de konfigurationsfiler som ligger i det repot. På det viset kan man jobba med sin texteditor, utan att behöva göra inställningar för olika kodstandarder, inställningarna ligger i filer i repot.

Jo, den gillade inte alls att jag uteslöt semikolon Men då vet man det och får förhålla sig därefter. Det är väl bra att öva sig på olika standarder då det förekommer ett antal när man väl kommer ut på jobb.
Tack för svaret och ha en bra dag.

//Thomas

Är det inte dags att gå över till npm:s rekommenderade standard?

Att skippa semikolon tycker jag låter väldigt trevligt

https://www.npmjs.com/package/standard

Är det inte dags att gå över till npm:s rekommenderade standard?

Att skippa semikolon tycker jag låter väldigt trevligt

https://www.npmjs.com/package/standard

När man kommer ut och jobbar kan jag tänka mig att en del företag använder den varianten, eller andra...

Jag har inte kollat på ett tag vilken kodstandard som är den mest vanliga inom JS-världen.

En anledning till att vi kör 4 spaces (och semikolon) är då alla programstudenter lär sig flera olika språk (python, php, javascript server, javascript klient) så är det ett försök att ha en liknande kodstandard under första årets kurser.

Jag har egentligen inga bekymmer att använda en js-kodstandard som kör 2 spcaes och inga semikolon. Dock, lite osäker om det är fördel eller nackdel med semikolonet. Men python har ju inga semikolon så... visst.

Tills vidare så kör vi nog på den kodstandard som ligger, men en tanke är ju att i de kurser som går i tvåan och högre, tex jsramverk, så är det fullt rimligt att studenten själv kan göra ett eget aktivt val om kodstandarden då dess konfigfil troligen är en del av ett eget repo och en egen utvecklingsmiljö. Men det överlåter jag till efo att fundera på.

I kursen jsramverk används ramverkens inbyggda kodstandarder och vi har inte på samma sätt dbwebb validate. I till exempel Vue går det inte ens att bygga koden om man inte följer standarden.

I övrigt kan jag tycka att regeln om att ”alltid” ha === och inte använda sig av de möjligheter coersion ger i JavaScriptär mycket konstig. Tycker det är ett märkligt nerslag när man inte till exempel hindrar användandet av till exempel || och && på olika typer (”” || 0 = false). Eller att använda coersion vid matematiska operatorer (”2” - 1 = 1) eller i booleska uttryck som if (myArray.length) {}.

Mycket bättre att isåfall som dominerande pakethanterare utbilda i coersion, både fallgropar och fördelar.

Som i så många andra JavaScript finns det en alldeles utmärkt förklaring i You Don’t Know JS.