In de (al wat oudere) programmeertaal C is het duidelijk; na ieder statement moet een puntkomma komen te staan. Het is een statement-terminator. Op zich raar gekozen, omdat in onze eigen taal de puntkomma dat nu juist niet is. In programmeertalen geeft hij echter structuur.
In moderne programmeertalen, zoals Go en Swift, is de puntkomma echter optioneel. Hij hoeft er niet te staan en wordt in deze talen ook vaak gezien als hinderlijk.
JavaScript komt uit 1995 en valt er een beetje tussenin. Hij is optioneel, maar anders dan in bijvoorbeeld Swift wordt hij niet door iedereen als hinderlijk gezien. Er zijn duidelijk twee kampen; zij die vinden dat hij altijd moet worden gebruikt en zij die vinden dat hij nooit moet worden gebruikt. En daar zit dan weer een klein kampje tussen dat het aan de tooling overlaat. Daarover later meer.
AUTOMATIC SEMICOLON INSERTION
Voordat we de kampen kunnen begrijpen, moeten we nog wel één ding weten; ASI. Automatic Semicolon Insertion is het automatisch toevoegen van puntkomma’s op plekken waar de JavaScript-taal ze verwacht, maar de programmeur ze niet expliciet heeft toegevoegd. Daar zijn duidelijke regels voor en die zijn goed beschreven. Voor nu is het genoeg om te weten dat het gebeurt. Omdat het automatisch gebeurt, is het soms onverwacht en veroorzaakt het soms problemen. En waar problemen zijn, zijn oplossingen. En waar oplossingen zijn, zijn meningen.
KAMP ALTIJD EEN PUNTKOMMA
Dit kamp is van mening dat je ze altijd expliciet moet intypen. Als ASI soms voor problemen kan zorgen, is het beter de problemen voor te zijn en de puntkomma altijd te gebruiken. Het is eenvoudiger om ze altijd te gebruiken dan om te weten en te snappen wanneer ASI de mist in gaat.
KAMP NOOIT EEN PUNTKOMMA
Dit kamp heeft een wat genuanceerdere mening. Zij gaan ervan uit dat ASI altijd aanwezig is en zijn werk goed doet. De situaties waarin ASI voor problemen kan zorgen, vinden zij sowieso situaties die vermeden moeten worden, omdat zij ‘bad coding practice’ zijn. Zij vinden dat de taal zonder puntkomma’s veel beter leest en moderner aanvoelt.
KAMP IK BRAND MIJN VINGERS NIET
Je kunt ook kiezen voor een tussenweg. Je typt ze niet expliciet in je code, maar de editor (in combinatie met wat extensies) voegt ze voor je toe. Dus in je uiteindelijke code zitten ze wel en technisch gezien hoor je dan alsnog in kamp ALTIJD.
ESLINT HEEFT OOK GEEN ANTWOORD
Wat is nu eigenlijk de algemene tendens? Meestal kun je die wel vinden in de instellingen van linters, code sniffers en fixers. ESLint heeft een duidelijke regel, ‘semi’, die twee waardes kent; ‘always’ en ‘never’. Deze komen duidelijk overeen met de twee kampen. Voor ESLint is ‘always’ de standaardwaarde voor ‘semi’. En daarmee schaart ESLint zich in kamp ALTIJD. De ‘semi’-regel is echter niet opgenomen in de ‘eslint:recommended’-regelset. Een standaardinstallatie breidt deze regelset uit. En daarmee kiest ESLint dus toch geen kamp.
DE STANDAARD VAN NU
De ‘JavaScript Standard Style’ (standardjs) is een guide, linter en fixer. Hij wordt door veel bedrijven en communities gebruikt en lijkt de de-factostandaard te worden voor JavaScript. Zij kiezen duidelijk voor kamp NOOIT. De situaties waarin ASI moeilijkheden kan geven zouden helemaal niet mogen voorkomen, omdat zij getuigen van een slechte programmeerstijl.
Zo lijkt het erop dat kamp NOOIT langzaam terrein wint.
Maar zoals altijd met kampen het geval is, zal er altijd een kamp blijven dat nooit helemaal voor NOOIT zal gaan, met een knipoog, of is dat een knipoog zonder puntkomma?
Meer info:
https://tc39.es/ecma262/#sec-rules-of-automatic-semicolon-insertion
https://eslint.org/docs/latest/rules/semi