I for one love coding standards when they are done right. That sounds like an awfully pigheaded thing to say, but with so many different standards out there it's easy to find a style you like and defend it like the men of Gondor at Helm's Deep: A battle where you fight for what's right against the evil tides of tyranny. That, in essence, sums up my experience with ESLint. I feel like the rebel pilots above Yavin IV with the Death Star breathing down my neck. That's not to say ceding standards aren't important, because they are. Uniformity across a repo is super important when it comes to consistency and communication. As programmers, we often forget that our code speaks to two different audiences: Computers and people. It's essential for my code to be easily understood by other developers, and this is where I take particular issue with ESLint. I feel like it doesn't lend itself to an easily understood experience.
As developers, we often find ourselves working long sessions at odd hours of the day. It's important that our code remains legible during these critical hours. I enjoy putting spaces before and after every parentheses or bracket. I enjoy neatly stacking variables in cute little columns. I enjoy splitting long constructors into several lines that are alse neatly stacked into cute little columns. ESLint hates it when I do this. Of course these settings can be adjusted and altered, but I still dislike having to do so. Coding styles aside, ESLint does check off the "is code so airtight it could prevent the Titanic's sinking" box quite nicely. It does a great deal of work towards debugging and future proofing, especially when it comes to unexpected inputs and outputs. I do thoroughly enjoy ESLint's ability to check every possible data leak, memory leak, type error, etc. This ensures my code is able to effectively speak with computers. While I take issue with ESLint's style, its ability to question the programmer and double check mistakes is beyond reproach.