In the last few months, aceman and I have been working on the mammoth task of linting all the javascript code in comm-central. I hope to have that task mostly finished by the end of January. Linting makes our code easier to read and easier to search, and makes us less prone to mistakes. But we need to make sure it can do its job. To that end, **please don't write code or accept code** that disables the linter or any of its rules without a good reason. Here's some examples: /* eslint-disable */ This is right out, without a /very/ good reason. /* eslint-disable complexity */ This isn't so bad, sometimes it's unavoidable to write a very complex function. (Try to avoid it, though.) **But** the disabling comment should be immediately before the function, and the function should be immediately followed by /* eslint-enable complexity */. In fact, disabling any rule for more than a line or two should not be done. If you have a good reason, use "// eslint-disable-line [rule name]" for inline comments or "// eslint-disable-next-line [rule-name]" if that would make the line too long. If you want to find out why the linter is complaining about your code, look up the rule it mentions at https://eslint.org/docs/rules/. There's also some Mozilla-specific rules at https://hg.mozilla.org/mozilla-central/file/tip/tools/lint/eslint/eslint-plugin-mozilla/lib/rules/. Finally, it might be helpful to install a linter plugin for your editor. I use SublimeLinter-eslint for Sublime Text: https://github.com/SublimeLinter/SublimeLinter-eslint and it's very good. Happy coding! GL P.S. There's somebody out there whose patch prompted this message, and three people who reviewed it. I'm not writing it to make you feel guilty.

Hey Geoff, a little base rule about style is good for code readability. A linter that makes too many demands, however, has a detrimental effect on code readability. A human still still better in expressing code than a machine is able to judge. If the linter forbids reasonable code, then the linter goes too far and reduced code quality. That means, as a coder, I should always be able to override a linter rule, because my judgement call in a specific case is better than a general judgement call. And if I find that I need to override a certain linter rule a lot, then the rule should probably be removed. Specifically, the complexity rule is too trigger happy. It's true that code should be kept small, I am a prime believer in short code, short functions, short files. I find files with 1000 lines unworkable, I usually make files with 200 lines. And my functions are much shorter. *But* some of the functions I wrote have 100 lines or so, because it makes sense for them. They do one thing, and it's not complex, it's just long, i.e. a lot of the same thing. So, a single function makes sense. The complexity rule triggers too often on these. Similarly, the "no-lonely-if" rule can dramatically reduce code readability, and should probably not be used at all. Humans are better than computers. And a general rule that's generally a good idea does not always apply in all cases. I should not have to justify every time where I think that my case is different. In other words, if I explicitly disable a specific linter rule, I know what I'm doing, and I should be trusted on that. Same thing for all rules: I think linting /in general/ is a good idea, I think the general idea makes sense. But it does not work in /all/ cases. The rules need to establish only a baseline and not dictate all aspects expression. Thanks for the work on linting and cleaning up the code, I think that's great and helps the codebase. Ben Geoff Lankow wrote on 04.01.19 03:27: > **please don't write code or accept code** that disables the linter or > any of its rules without a good reason.