Писать типы вначале или рассчитывать на вывод типов компилятором?

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

Я же, наоборот, пытаюсь лишь писать типы там, где это нужно, и где ТС не может их вывести правильно сам.

Какой подход по-вашему правильнее?
  • Вопрос задан
  • 72 просмотра
Пригласить эксперта
Ответы на вопрос 3
Никакой религии в этом вопросе нет и быть не может. Есть вполне конкретные правила, когда писать типы весьма полезно.

Если вы НЕ указываете тип, и рассчитываете на автовывод, то значит вам нужен не какой-то конкретный тип, а ТАКОЙ ЖЕ, КАК И... где-то ещё. Например, такой-же-как тип константы или такой-же-как тип возвращаемого значения функции. Иными словами, если я пишу:
const id = findIdByName("abc");
то мне не так важно, какой конкретно тип будет иметь id, мне важно чтобы это был тип возвращаемого значения функции "findIdByName". Для меня это приоритетно. Более того, если в какой-то момент тип возвращаемого значения у этой функции поменяется, то этот код продолжить компилироваться и, вероятно, даже РАБОТАТЬ (это зависит уже от того, что мы потом собираемся делать с id).

Совершенно противоположная ситуация - интерфейсы. В широком смысле. Интерфейсы функций, интерфейсы классов, интерфейсы в смысле типов данных, создаваемых с помощью "interface". Особенно если эту функцию/класс/интерфейс использует много кто ещё. Тогда наоборот, вам НЕЛЬЗЯ допустить, чтобы типы параметров или тип возвращаемого значения просто так поменялись. Это вдвойне важно, если вы пишите библиотеку и речь идёт о её публичном интерфейсе - любое изменение интерфейса тогда должно подкрепляться версионированием (например, семантическим). Вы не можете просто так, тем более по недосмотру, вместо числа начать возвращать из функции строку - вы сломаете ваших клиентов, причём даже не знаете как и где.
Ответ написан
Комментировать
@antares4045
Вопрос сугубо религиозный. Если у вас в команде нет требований к кодстайлу, то пишите так, как вам проще и не парьтесь.

Но если включить на время зануду, то очень хочется отметить, что вы взяли тайпскрипт чтобы всеравно писать на js. Все эти истории с автоматическим выводом типов выводила людей из себя: пропустив одну букву они получали программу которая работает, но делает что-то не то. И если эта "одна буква" где-то в корнер кейсе, то ошибка может оставаться незамнченой годами. Можно покрывать весь код юнит тестами. Но это долго и бизнес (по крайней мере средний) на такие траты ни за что не пойдёт. К тому же в тестах тоже могут быть косяки... И тут люди "вспомнили" о ещё одном способе избегать такого рода ошибок: если пользователь сам распишет типы, то совсем грубые семантические ошибки компьютер отловит: тайпсерипт специально сделан, чтобы ваш код не запускался.

Но как вы и сами отметили, проблему ошибок в коде попытплись заткнуть заставив програмиста писать больше кода в котором тоже могут быть ошибки и в результате большая часть времени уходит на "любювь с статическим анализатором". Если вы достаточно уверены в себе и в тех, кто будет поддерживать ваш код, то наверное лучше потратьте время на написание осмысленого кода а не боллерплейта, который позволят просто убедится, что вы не допустили совсем простых ошибок.
Ответ написан
Комментировать
Aetae
@Aetae Куратор тега TypeScript
Тлен
На этот вопрос нет однозначного ответа.
Мне нравится когда всё выводится само. Это приятно и удобно. Но нет никаких гарантий, что "само" выведется именно то, что нужно, и что ты где-то незаметно не накосячил. Потому в важных\сложных местах типы я пишу заранее. Но только в оных.

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

Ну и есть религиозное течение "types first" но это, на мой вкус, мазахизм чистой воды. И совершенно не стоит мнимых выгод.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы