Почему TSLint и JSLint сообщают о пустых блоках?

Время от времени я получаю ошибки TSLint, "блок пуст". Это происходит, например, когда я передаю вызов no-op для функции:

doSomething(() => {});

Из того, что я читал, JSLint, очевидно, делает то же самое, но я этого не проверял.

Я нахожу эти обычаи полностью действительными, поэтому я попытался найти причину, по которой пустые блоки считаются плохими. Но единственное, что я могу найти (например, в этом ответе), - это инструкции по добавлению return;, чтобы избежать ошибки. Это не, что я хочу делать в каждом пустом обратном вызове.

Почему отчет TSLint над пустым блоком является проблемой? Есть ли причина, по которой я не должен отключать проверку?

ОТВЕТЫ

Ответ 1

Почему отчет TSLint над пустым блоком как проблема

Чтобы предотвратить ошибки. Возможно, функция была забыта, чтобы ее заполнили. Рекомендовать () => undefined как noop.

Подробнее

Если вы хотите отключить его, просто добавьте "no-empty": false, в свой tslint.json (глобально отключить) или отключите его в строке с помощью комментария /* tslint:disable:no-empty */.

Ответ 2

Как и при всех проверках, у вас есть окончательное решение о том, помогают ли они вам или нет. Вы можете отключить эту проверку TSLint, используя один из следующих вариантов.

Отключите правило в tslint.json

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

Отключите правило в файле:

/* tslint:disable:no-empty */

Вы всегда можете снова включить его, если в будущем вы найдете пустой блок, который вызвал у вас проблемы.

Ответ 3

Чтобы устранить ошибку и указать, что пустой блок был преднамеренно, нужно временно отключить правило:

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

Или сделать его непустым:

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

Ответ 4

В tslint v5.10.0 введена опция "allow-empty-functions" для "no-empty" только для этого случая;
также "allow-empty-catch" (введенный в v5.5.0) может быть полезен:

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

Ответ 5

Другим возможным решением является использование

doSomething(() => { return })

Хотя это не совсем вопрос, который был задан, я обнаружил этот подход, пытаясь решить следующую сообщаемую строку:

export const generatorFn = function * (): IterableIterator<any> { }

Мое решение состояло в том, чтобы добавить инструкцию return как описано выше, поскольку функции генератора не могут быть выражены как функция стрелки:

export const generatorFn = function * (): IterableIterator<any> { return }

Ответ 6

Если вы чувствуете, что не хотите использовать обратный вызов во время определенных сценариев, вы можете изменить код

от

doSomething(() => {});

в

doSomething(() => undefined);

Подстановка() => {} подразумевает, что вы не заботитесь об этом обратном вызове. и явное приведение типов позволит избежать последствий.

Удачи.