DEV Community

How not to lint your code?

Arek Nawo on February 10, 2019

This post is taken from my blog so be sure to check it out for more up-to-date content 😉 As a programmer, I think you have high expectation for th...

Read full post

Dian Fay • Feb 11 '19

I've used ESLint for years; I keep telling myself I'll switch to prettier the next time I find myself writing an // eslint-disable-line or // eslint-disable-next-line but it never seems to take....

One thing to note, naming your magic numbers is all well and good but numOfIterations doesn't tell you anything that 10 didn't. If you're going to go to the effort, it should explain why, not just what (like comments!).

Arek Nawo • Feb 11 '19

I said about it in the article.

Know that you can do a little better with variable naming, unlike me. 😅

But it's good advice in general. Variables should be taken care more than they actually are.

Mihail Malo • Feb 12 '19

I must say, I wholly support the import/export rules, they make automatic imports, renames, and other tooling work so much better, as well as generally causing less diffs and consistent naming throughout a project.
I also begrudgingly agree with the sorting rules.

I am not convinced about "return-undefined" or even "noImplicitReturns" though.
Implicit returns in a void-returning function are a no-brainer, the body just ends and you're done. And having undefined written is just noise, that is what return means.

Personally I'd forbid return undefined in all positions, and return at the end of a function. Is there a way to do that?

Arek Nawo • Feb 13 '19

It's a good idea. Sadly, such a simple rule isn't present in TSLint and even ESLint. The closest thing I found is consistent-return from ESLint, but still, it's not exactly the right thing.

Mihail Malo • Feb 12 '19

But my increment :v

  neighborsInfo: (r: BufferWithPointer) => {
    const length = r.uint8()
    const arr: (number | Buffer)[] = new Array(length * 6)
    for (let i = 0, off = 0; i < length; i++) {
      const addr = r.buffer(8)
      arr[off++] = addr
      arr[off++] = r.int16le()
      arr[off++] = r.int16le()
      arr[off++] = r.int16le()
      arr[off++] = r.int8()
      arr[off++] = r.uint8()
    }

    return arr
  }

Mihail Malo • Feb 12 '19

Actually, I feel like a lot of people would applaud the typedef rule in this situation (yes, I deleted the types from the implementation):

const myArrowFunction: (arg1: number, arg2: number) => void =
(arg1, arg2) => {
    // ...
}

This way all the type information comes first, and the implementation comes after.
Very haskelly.

Mihail Malo • Feb 12 '19

Well, there's the "interface-name": [true, "never-prefix"] option.
Which is what the style I've seen TSc team recommend.

Basti Ortiz • Feb 10 '19

I love this article because I can relate to it on so many levels. Don't worry, bro. I know the struggles, too. You aren't the only perfectionist here. 😉

Arek Nawo • Feb 10 '19

Well... I definitely feel better now. 😅 As a side-note, I found this. It seems like a nice option if somebody wants to follow strictly defined guidelines with NPM, Express and alike using it. But still, it's not so strict and not so ideal either. That's why for now I disabled my linter (I'll turn it on when I finish writing the basic codebase) as it seemed a bit counter-productive with all this configuration stuff 😁

Kevin Boosten • Feb 20 '20

Nice article! Will try out tslint:all tomorrow!

I also standard add this rule from tslint-microsoft-contrib to check my code on any forgotten TODO/FIXME/HACK comments:
“no-suspicious-comment“ 🙂

Arek Nawo • Feb 20 '20

Thanks! I think you might be interested in a config of mine that I've recently released. github.com/areknawo/eslint-config-... It aims to solve most of the issues that I've described in this post. Hope you enjoy it! 😊