Just read this article https://2002-2012.mattwilcox.net/archive/entry/id/1054/
Man it's great to hear someone else telling the truth about Lint. I've worked at a place that used Linters as a part of its build process. Periodically you would have masterfully written code that couldn't be merged because Lint didn't like something. The code structure was good, the Linter was what was wrong.
Here is a recent example. By default all these linters want you to keep line lengths bellow 76 characters. Why? Oh the Python linter has a doozy of an explanation. "It's easier for side by side comparisons." No the real reason, it's legacy. Back many moons all terminals were standard 80 column. Wide printing printers (daisy chained) were 160 characters... and sounded like a freight train.
Well for MOST languages... you can fiddle fart with your line to get it to go under 80 columns. THAN THERE IS COFFEE. With indention and a line like
"item = (menuItem for menuItem in scope.topMenuItems when menuItem.label is label)"
which HAS to be on a single line. On top of that the default coffeelint makes over 80 characters a error instead of a warning... meaning you can't use anything good in Coffee by the default Coffee Linter rules.
Another precious one.. it is a warning but for those of you that use Angular+Coffee will enjoy
"scope.currentMenu = menuItem for menuItem in scope.topMenuItems when menuItem.label is label"
Will earn you line too long error and "Comprehensions must have parentheses around them." But what if your wanting to pass the actual object not just the data? TOO BAD! CoffeeLint says no!
Yes I know you can change the rules... and I did for line too long being an error to a warning. But in my humble opinion Lint should only be used in editors where it can be ignored if needs be, and not in the actual build processes where it can shove it's ugly head in and break builds. Don't misunderstand what I'm trying to say... Linting code is good. Having it at the decision point of a successful build or not is just stupid. It's there to make good suggestions on code formatting, not be the voice of truth. Well at least in my opinion.