EditorConfig-generator

Wat .editorconfig doet

Een bestand met de naam .editorconfig in de hoofdmap van een project legt opmaakconventies vast. Editors met EditorConfig-ondersteuning (elke grote IDE en de meeste moderne teksteditors) passen die regels toe zodra je een bestand opent. Het zoeken loopt vanaf het bestand dat je bewerkt omhoog door de mappenstructuur en stopt bij het eerste bestand waarin root = true staat.

Voorbeelduitvoer

Met de standaardinstellingen (spaties, inspringgrootte 4, LF, utf-8) en de twee secties die alvast voor je zijn aangevinkt, genereert de tool:

root = true

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

[*.{md,markdown}]
trim_trailing_whitespace = false

[{Makefile,makefile,GNUmakefile,*.mk}]
indent_style = tab

Vink Python, Go of YAML aan en de bijbehorende sectie verschijnt eronder, meteen met de conventie die de formatter van dat ecosysteem afdwingt.

Belangrijkste richtlijnen

Drie regels die een build breken, niet alleen een stijlgids

De meeste regels in een .editorconfig zijn voorkeuren. Deze drie niet, en juist daarom is een sectie per taal de moeite waard:

• YAML staat het tabteken niet toe om in te springen. Dat is een parseerfout, geen waarschuwing van een linter. Springt je project in met tabs en heb je GitHub Actions-workflows, Docker Compose-bestanden of Kubernetes-manifesten, dan moet de YAML-sectie de spaties terugzetten.
• make eist een echte tab aan het begin van elke receptregel. Een spatie levert missing separator. Stop. op en de build valt stil. Daarom staan er in [{Makefile,makefile,GNUmakefile,*.mk}] meerdere schrijfwijzen: EditorConfig vergelijkt bestandsnamen hoofdlettergevoelig, en in repository’s komen zowel Makefile als makefile voor.
• Een shellscript dat met CRLF is opgeslagen, draait niet. De kernel leest de carriage return als onderdeel van het pad naar de interpreter en meldt zoiets als /bin/bash^M: bad interpreter: No such file or directory. Windows-batchbestanden hebben het spiegelbeeld van dat probleem: cmd.exe zoekt goto en call :label op via een byte-offset, dus een .bat met alleen LF kan naar de verkeerde regel springen of halverwege stoppen, zonder ook maar één foutmelding.

Twee daarvan worden juist veroorzaakt door het globale blok in plaats van erdoor opgelost, en daarom houdt deze generator ze in de gaten. Kies je tabs zonder de YAML-sectie toe te voegen, of CRLF zonder de shell-sectie, dan maakt het bestand dat hij schrijft juist die bestanden kapot, ook al worden ze er nergens in genoemd. De generator meldt dat boven de uitvoer, in plaats van je het te laten ontdekken via een pipeline die faalt. Hetzelfde geldt voor de utf-16-tekensets: die gelden voor elk bestand in het project, en make, shell-interpreters en Python kunnen broncode die zo is opgeslagen niet lezen.

Taalconventies die deze generator schrijft

Let op wat er niet in die tabel staat: regellengtes. PEP 8 zegt 79, Black zegt 88, PSR-12 houdt een zachte 120 aan en rustfmt zegt 100. Zet je een van die getallen in een taalsectie, dan overschrijft dat stilletjes de limiet die je voor het hele project hebt gekozen. Daarom laat de generator max_line_length alleen in het [*]-blok staan en houdt hij die getallen hier, waar je ze bewust kunt toepassen.

Ondersteunt jouw editor het?

Ingebouwde ondersteuning: VS Code, de IntelliJ-familie van JetBrains, Visual Studio, Sublime Text, Xcode en Notepad++. Vim, Emacs, Neovim en een handvol andere editors hebben een kleine plug-in nodig. Het bestand is gewone INI, dus linters en formatters kunnen het ook lezen; zo blijven Prettier en sommige language servers ermee in de pas lopen.