Why do TSLint and JSLint report empty blocks?

Question

From time to time, I get TSLint errors "block is empty". This happens e.g. when I pass a no-op callback to a function:

doSomething(() => {});

From what I read, JSLint apparently does the same, but I didn't verify that.

I find these usages completely valid, so I tried to find a reason why empty blocks are considered bad at all. But the only thing I'm able to find (e.g. in this answer) are instructions to add a return; to avoid the error. This is not what I want to do in every empty callback.

Why does TSLint report above empty block as problem? Is there any reason why I shouldn't disable the check?

Burnard

Never used either; just thinking aloud: could it be that the times that TSLint complains is when it thinks the function should return a value and your no-op function isn't doing so? You could perhaps define an explicit no-op function and just pass its name in this sort of call. – Agnosticism

@Agnosticism No, TSLint complains even when I specify an explicit type of (() => void) for the callback. Regarding the noop: I just found out that lodash already defines one: _.noop. This is so far the cleanest solution... – Burnard

@danwellman yes but that changes the return type from void to an empty object. – Brooklime

Go to the following page for the empty function errors: https://mcmap.net/q/212607/-eslint-complaining-about-empty-constructor-and-ngoninit-implementation – Habitant

Go to the following page for the empty function errors: https://mcmap.net/q/212607/-eslint-complaining-about-empty-constructor-and-ngoninit-implementation – Habitant

Answer 1

Why does TSLint report above empty block as problem

To prevent mistakes. Perhaps the function was forgotten to be filled out. Recommend () => undefined as a noop.

More

If you want to disable it simply add "no-empty": false, to your tslint.json (globally disable) or disable it inline using a /* tslint:disable:no-empty */ comment.

Octopus

I guess I don't want TSLint to tell me I missed filling out a function body, that's what I have tests for. So if there is really nothing else that this check is useful for, I rather disable it than using () => undefined in every single callback. But that's a matter of taste I suppose. – Burnard

Just to clarify, could you specify what you mean by "mistakes" exactly? Is it just the empty function body? – Burnard

Like basarat said, a mistake might be you forgot to implement something, although conventionally every function you want yo implement someday should throw NotImplemented when used. – Niel

FYI it's been updated to: "no-empty": 0, – Zadazadack

Using () => undefined breaks the no-undefined rule, so no this is not recommended. The recommended fix is to write a clear comment: () => {\n// Do nothing.\n}. – Absolutism

@GéryOgam thanks a lot bro, I was just at the docs and literally missed the first topic. – Digitize

Answer 2

If you feel you dont want to use callback during certain scenarios you can modify the code

from

doSomething(() => {});

to

doSomething(() => undefined);

Substituting () => {} to this implies you dont care about this callback. and explicit typecasting will avoid implications.

Good luck.

Gnatcatcher

Answer 3

A way to suppress the error and designate that empty block was intentionally is to disable the rule temporary:

// tslint:disable-next-line:no-empty
doSomething(() => {});

Or make it non-empty:

doSomething(() => {/**/});

Kay

The second advise seems very inappropriate. – Separation

Answer 4

As with all checks, you have the ultimate judgement on whether they are helping you or not. You can switch off this TSLint check using one of the following options.

Disable the rule in tslint.json

//...
"no-empty": false,
//...

Disable the rule in the file:

/* tslint:disable:no-empty */

You can always switch it back on again if sometime in the future you find an empty block that has caused you a problem.

Mcdougall

Avoid disabling lint rules. – Sunbeam

@Sunbeam you should absolutely build your own ruleset with your team. Don't follow lint rules blindly. I would keep this particular rule, but in general, you should think about each rule and take a team decision. – Mcdougall

I understand your point. The thing is that ideally, the decision to build the ruleset usually occurs when the project starts. You may help me to understand why investing time to choose a ruleset that can be easily bypassed or ignored (as the first option to solve issues like the one mentioned) while a project grows. – Sunbeam

Answer 5

tslint v5.10.0 introduced "allow-empty-functions" option to "no-empty" just for this case;
also "allow-empty-catch" (introduced in v5.5.0) may be useful:

"no-empty": [true, "allow-empty-functions", "allow-empty-catch"]

Waki

Answer 6

if it doesn't work the comment inline to disable try this

// eslint-disable-next-line @typescript-eslint/no-empty-function
handler: () => { }, // here you empty function

Stephanus