Cue a git log littered with “ Fix the linter” commit messages.Ĭommits like this can pollute a git log, which we try to keep as tidy as possible. This invariably meant that, despite best efforts, you would break your build when submitting a Pull Request by tripping the linter. This disadvantage of having a wide array of config options is each project could be set up very differently, even within small teams.
#HTML FORMATTER LINUX CODE#
The advantage of this was you could persuade your linter to check your code to ensure it’s was exactly as you’d check it yourself. As these linters tried to be all things to all men, they shipped with a seemingly infinite array of config options. html files these days – it is typically moulded around template tags of various flavours to enable dynamic population of content. This may be partly because HTML is rarely written in isolated. HTML linters also came and went but the community never seemed to coalesce around one solution.
We had JShint which evolved into Eslint for Javascript and Scsslint, latterly superseded by Sasslint, for Sass files. If it doesn’t give me joy – it goes in the bin! Lint all the thingsĪs front-end development matured rapidly in the early part of this decade, linters became more and more popular. There is a place for everything and everything should be in its place.
I like a tidy desk, a tidy house, a tidy car and a tidy garden. I’m also tidy by nature – clutter stresses me out. The reason for this is to make sure my code is tidy and consistent and thus easier to maintain – either by myself at a later date or by someone else. Let me explain why.įor many years, I’ve spent a considerable amount of time squinting at my code editor and trying to decide if the curly brackets at the top of my screen align with the curly brackets at the bottom of my screen. I’ve become a huge advocate of using Prettier to format front-end code.
0 kommentar(er)
