Как стать автором
Обновить

Комментарии 16

что-то не совпадает с исходником про воиды, поясните пожалуйста
let c = callback() //здесь callback всегда возвращает undefined

const didItWork = callback(200, results); // ️ compile error!

В статье просто неправильно написано: на самом деле calback(): void "возвращает" void, а не undefined
И тип у c будет не undefined а void. Оно скомпилится, но ничего осмысленного сделать нельзя с переменной c, тип void никуда не присвоить не получится(кроме другого void).

без загрязнения глобального пространства имён

А что мешает сделать (function(){...})();?

Если некая функция всегда должна возвращать undefined

логично написать return undefined;
логично написать return undefined;

const fn = () => (doSomething(), undefined)

так?
Я имею ввиду тело самой функции.

Как вы ее оформите — дело ваше. Стрелочные функции — просто сахар, суть от них не меняется. И, да, я предпочитаю ими не пользоваться в присваивании. Как-то глаза режет.
const fn = () => {doSomething()}
На сколько я себе представляю, человек пишет
return callback()
зная, что колбек возвращает undefined. Потом человек увидел, что иногда кто-то передаёт такой колбек, который возвращает что-то другое и тогда человек ставит void и спит спокойно. Другого варианта не придумал ) return undefined, как по мне лучше.
> который возвращает что-то другое
Иии… да и пофиг как бы. Если вы предполагаете, что вернется undefined (а скорее всего null, т.к. обычно return undefined не пишут), то если вернется «что-то», то ничего страшного не случится.

На крайняк

callback();
return undefined;

Может быть, использовать void можно в тех случаях, когда колбэк может вернуть false, а false обрывает дальнейшее выполнение, а программисту, в свою очередь, не нужно, чтобы выполнение обрывалось.

return undefined; не нужно писать, проще написать return;
Если не нужно возвращать результат callback — просто пишем два разных выражения:
callback();
return;

и не важно, что вернёт callback. Рецензия на статью отрицательная, void по факту архаизм и практического применения, кроме как попонтоваться знанием синтаксиса, не имеет.

Тип void в typescript имеет смысл, если участники проекта понимают разницу между функцией и процедурой, и помечают возвращаемый тип процедур как makeCoffee(): void. И директиву return в процедуре лучше не писать в принципе. Это и есть отсутствие возвращаемого значения. То что undefined эквивалентен void допущение typescript, о котором пару слов говорится в документации.


Противоположностью для типа any является тип unknown (а не void).

Почему лучше не писать return в принципе? В своих приложениях мы настаиваем на early return вместо вложенных if/else и флагов досрочного выхода из циклов.

Это достойные причины для return. Я сказал "лучше", подразумевая идеальный случай, когда нет причин для досрочного выхода.


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

Много лет не вспоминал про JS void пока на ревью TS кода не резанула глаз () => undefined как реализация onClose (): void в интерфейсе.

Не понял, зачем вообще огород городить, явно указывая void/undefined. Вот же:
var f1 = () => {
    // dosmth
    return;
},
f2 = () => {
    // dosmth
};
console.log(f1(), f2());

undefined undefined

Суммаризировать надо было проще - "ошибка дизайна языка".

Зарегистрируйтесь на Хабре, чтобы оставить комментарий