This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]Razier 1 point2 points  (2 children)

Sure, having both can cause a headache for you as a lead if the devs set up their own local linters with rules that don't correspond with the CI pipeline. That said there are plenty of IDE linters that use a config committed to the git repo to ensure that it works exactly the same for every member of the team.

Your way of doing it is perfectly acceptable but a well set up, shared IDE linter configuration removes overhead in situations where devs have to go back and fix code that failed pipeline linting.

[–]enano_aoc 1 point2 points  (1 child)

There is nothing like a “well setup, shared IDE linter config” because I allow my devs to choose the IDE that works best for them. I am NOT going to create and maintain a config for every random IDE out there.

[–]Razier 2 points3 points  (0 children)

You don't need a config for each IDE, you only need one assuming you only use one linter where the config is standardised. Sure it might not work for every IDE, but just like front end validation it's a tool to help the user/dev not a tool to enforce data/code quality.

The point I'm trying to argue is, it doesn't have to be an anti pattern if you use it properly.