How not to lint your code?

Areknawo 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]
markdown guide

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!).


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.


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?


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.


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.


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

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


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. 😉


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 😁

code of conduct - report abuse