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?
(() => void)
for the callback. Regarding the noop: I just found out that lodash already defines one: _.noop
. This is so far the cleanest solution...
void
to an empty object.
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.
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.
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.
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(() => {/**/});
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"]
Success story sharing
() => undefined
in every single callback. But that's a matter of taste I suppose.NotImplemented
when used.