Size: a a a

2020 October 11

D

Danila in pro.js
В смысле документации тут разница невелика
источник

D

Danila in pro.js
Ну поинт в чём, что типы не нужны потому что можно написать код, который и без них будет работать?
источник

D

Danila in pro.js
С этим не спорю
источник

in pro.js
Danila
Но это решается (если нужно) на этапе приёма данных
Любой, теоретически переиспользуемый код, должен валидировать ввод в рантайме, хотя бы чтобы осмысленно падать, бросая исключения, а не начинать стрелять куда-попало.
источник

D

Danila in pro.js
Любой, теоретически переиспользуемый код, должен валидировать ввод в рантайме, хотя бы чтобы осмысленно падать, бросая исключения, а не начинать стрелять куда-попало.
Кроме ввода есть ещё внутренняя работа
источник

in pro.js
К слову, я еще забыл про то, что статическая типизация никак не избавляет от покрытия тестами.
источник

D

Danila in pro.js
Юзерский ввод в вебе это всегда строка почти
источник

D

Danila in pro.js
Это дело в любом случае кем-то где-то валидируется/приводится/парсится и так далее.
источник

D

Danila in pro.js
Вопрос в том, как оно дальше растекается
источник

in pro.js
Danila
Ну поинт в чём, что типы не нужны потому что можно написать код, который и без них будет работать?
Типы всегда есть. Это как ООП - оно в голове, а не в синтаксисе.
источник

in pro.js
Danila
Юзерский ввод в вебе это всегда строка почти
Ты можешь библиотеку писать. У нее есть внешний интерфейс, который будут использовать, и ты не имеешь права полагаться на то, что твою библиотеку будут использовать так, как задумал ты. Она может вызываться из нетипизированного кода, или ез применения стат анализа. Вход ты должен проверять во всем, что не имеет свойства приватного.
источник

D

Danila in pro.js
Ты можешь библиотеку писать. У нее есть внешний интерфейс, который будут использовать, и ты не имеешь права полагаться на то, что твою библиотеку будут использовать так, как задумал ты. Она может вызываться из нетипизированного кода, или ез применения стат анализа. Вход ты должен проверять во всем, что не имеет свойства приватного.
Если я пишу ТС-библиотеку, то я подразумеваю, что она юзается в ТС

Кроме "данных извне" есть ещё и работа частей кода между собой. И кто-то может не касаться ввода вообще, а получать его уже отвалидированый из другой части системы/с другого уровня, например. И вот в этом взаимодействии описание типов и следующая из этого самодокументированность позволяет
1) Повысить DX
2) Обезопаситься от ошибок времени разработки - если ты передал не то и не туда, твой код просто не скомпилируется.
3) То же относится и к библиотекам. Если они на ТС и для ТС - проверять ничего не нужно, код просто не соберётся, даже если увидит, что ты передаешь any туда, где нужно что-то конкретное
4) Чем больше, длиннее и шире проект и чем больше людей над ним работают, тем это важнее

И самое во всём это важное, с моей точки зрения (и в чём был изначальный поинт) - это не стоит ничего. Ноль рублей ноль копеек. Просто пишешь тип не в жсдоке, а ближе к самому коду и всё просто работает.
источник

in pro.js
Danila
Вопрос в том, как оно дальше растекается
Просто используй динамический подход. Он не только о типизации, но и структуре самого кода. Большое разбивается на частное. Так, чтобы сложность не была настолько запредельной, где ты не мог бы понимать, что в этом массиве у тебя лежат объекты такого-то типа, а в той переменной у тебя строка.
источник

N

Nillcon in pro.js
Можно нахуярить 3к строк без пробелов, а потом написать крутую документацию
источник

in pro.js
Danila
Если я пишу ТС-библиотеку, то я подразумеваю, что она юзается в ТС

Кроме "данных извне" есть ещё и работа частей кода между собой. И кто-то может не касаться ввода вообще, а получать его уже отвалидированый из другой части системы/с другого уровня, например. И вот в этом взаимодействии описание типов и следующая из этого самодокументированность позволяет
1) Повысить DX
2) Обезопаситься от ошибок времени разработки - если ты передал не то и не туда, твой код просто не скомпилируется.
3) То же относится и к библиотекам. Если они на ТС и для ТС - проверять ничего не нужно, код просто не соберётся, даже если увидит, что ты передаешь any туда, где нужно что-то конкретное
4) Чем больше, длиннее и шире проект и чем больше людей над ним работают, тем это важнее

И самое во всём это важное, с моей точки зрения (и в чём был изначальный поинт) - это не стоит ничего. Ноль рублей ноль копеек. Просто пишешь тип не в жсдоке, а ближе к самому коду и всё просто работает.
Твое ошибочное умозаключение в том, что это ничего не стоит. Это стоит очень многого, а профиты практически нулевые, при разумном программировании. Другое дело, что ты описываешь именно что юзкейс программирования не приходя в сознание. Где 90% времени вы тратите не на решение задачи, а на описание кода, который эту задачу решает, описывая его в несколько раз больше, чем было бы достаточно. И сражаетесь с компилятором, да.
источник

D

Danila in pro.js
Твое ошибочное умозаключение в том, что это ничего не стоит. Это стоит очень многого, а профиты практически нулевые, при разумном программировании. Другое дело, что ты описываешь именно что юзкейс программирования не приходя в сознание. Где 90% времени вы тратите не на решение задачи, а на описание кода, который эту задачу решает, описывая его в несколько раз больше, чем было бы достаточно. И сражаетесь с компилятором, да.
И чего же это стоит?
источник

in pro.js
Danila
И чего же это стоит?
Лишней работы, времени.
источник

D

Danila in pro.js
Лишней работы, времени.
Сейчас в твоём коде нет упоминаний типов? В комментах? В jsdoc?
источник

in pro.js
Пока в Виллабаджо все еще описывают типы и интерфейсы в сорцах тса, в Вилларибо уже написали логику и дописывают тесты.
источник

D

Danila in pro.js
Не забывая тестировать и разруливать поведение при неверных типах инпута, надеюсь
источник