Jason Knight

The less code you use, the less there is to break

Jun 3, 2018

I've generally found that even the recommendations made my linters are utter and complete NONSENSE. Out of box they universally check for so much crap that has NOTHING to do with whether the code is good or not, I cannot grasp why anyone would put up with it. Once configured to not report all the idiotic garbage and bad advice, they no longer actually DO anything.

It's like the inverse of turning off all the things the CSP blocks by default -- end result being at that point you're not even using it.

If we could see the code in question we could probably tell you exactly where it's going bits-up face-down, but on the whole my advice when it comes to linters is to forget it. They're full of s* and do nothing but fudge-pack the 'true believers' out there.

What specific part of the checks it does is it reporting that semi-colon under? It SHOULD be saying which of the flags in the configuration is detecting a problem. If you insist on trying to use eslint, that would be the place to start; though dimes to dollars it's something earlier in the code that's causing the linter to fail.

Mark

formerly known as M

Jun 3, 2018

I think half the purpose of linters is to make code uniform. By enforcing the same style guide on everyone (automatically), it's easier to read other people's code. So it's an advantage, even if the change suggested isn't inherently an improvement.

That said, I can't speak for eslint, but I myself feel that other linters have pretty good suggestions. With a fair number of exceptions, I think they're a net benefit, even when working alone.

M -- I'd agree with that given some of the options that are disabled by default -- but if that's the point why are they... well disabled by default?

Like brace-style... I disagree with what it does (I'm a "opening belongs on the line huffing opening it" type) but for forcing consistent style it's a good idea. Forcing uniform usage of tabs on indents, verifying that all indents are EITHER tabs or spaces with no mix-match, enforcing the use of curly brackets even when not needed I disagree with, but if that's the style a project is using you bloody well use it, and having a tool to check that is a good idea.

But that's all stuff disabled out of box, and instead pedantic nonsensical BULLSHIT like no-unexpected-multiline (making code HARDER to read), no-var forcing you to ONLY use the dumbass 'let' and 'const' (missing that all three might just exist separately for a reason), no-empty breaking conditional loop constructs, etc, etc... the stuff 'out of box' is just plain nonsense.

Or even the silly thing for making it complain about "Yoda" constructs (as if there's such a thing) when reversing the static before the dynamic can actually result in smaller gzipping of the output... which is why many minifiers will switch it around for you... nothing like having a tool tell you not to do something that another tool (that most everyone will use) will then go and flip it back around. Hurr-durr...

In that way it reeks to me of the same mentality where people have become so reliant on version control they no longer know how to communicate with team-members and project managers get to play farmville instead of doing their damned job. If used to enforce a style guide it just means nobody is reading or understanding the huffing style guide.

Kind of like how if people can't be bothered to use H1...H6 and HR properly to create their logical document structure, throwing pointlessly redundant and ultimately useless tags at it in the form of article, aside, header, footer, main, nav, and section isn't the answer! Don't even get me started on the microformat junkies 'special place' to yank their own cranks known as aria roles.

As a rule tools don't make up for incompetence, they only reinforce it.

Search Hashnode