Функции должны иметь как можно меньше аргументов, желательно ни одного.
Clean code, очевидно не подразумевает написание pure code.
В чистом коде функция не может не иметь ни одного аргумента, ведь ее можно(и нужно) заменить константой.
В остальном — я давно уже пришел к маленьким функциям и маленьким файлам еще.
Ах да, попытка «в лоб» уменьшить количество аргументов обычно приводит к тому, что аргументы схлопывают либо в кортежи либо в plain объекты, что меняет функцию только визуально, проблема не решается. Размер функции и количество аргументов это симптомы болезни, root cause же этой болезни — избыточное количество отвественности в функции. Надо уменьшать ответственность, растаскивая ее на части, декомпозируя то бишь. Количество аргументов и размер функции подтянутся сами.
Ну то что оверхед есть это понятно, мне интересно часто ли случается такое, что при какой то относительно простой операции результатом будет число с огромными нумератором и деноминатором, что одно число сожрет пару гигов памяти и соответствующую же производительность.
Да, в шарпе нашел в том числе реализацию с BigInteger, бесконечным целым. (первое что нашел было с uint). Стало интересно, не случается ли риск при каких нибудь безобидных действиях получить удар по производительности/памяти?
Так и я решах существующую задачу, а не сферическую задачу в вакууме, и эта задача прекрасно решается через Decimal.
И Rational тоже допускает потери, по определению, т.к. не имеет бесконечной точности, и к нему также применимо выражение «гарантирует отсустствие потерь, пока не превысится точность», как и к Decimal. В отличие от Double, который дает погрешность уже на примере операции 0.1 + 0.2
Кругом столько минусов, что хочется, чтобы кто то написал статью(или дал ссылку) как правильно работать с деньгами.
Как сохранять в БД бесконечные дроби, да хоть бы и конечные, но с большей точностью, чем стандартные типы. Даже не арифметические операции с такими числами, а просто сохранить в базе и считать без потери.
ЗЫ У нас не было операций деления. Сложение, вычитание и умножение на целое количество процентов(не дает бесконечных дробей, очевидно). А порой просто ввод, хранение и вывод. Double валится уже тут. Decimal на этом всём работает. Это кстати были не банковские деньги, а рассчеты, что то типа выставления сметы.
Гарантирует, пока не превысится точность. Точность не бесконечна естественно, хоть и больше, чем у double.
В JS (как и в шарповом double я думаю) даже без каких либо алгебраических действий можно получить такую кривизну. Просто читаешь ораклом из базы дробное число, получаешь не то что в базе записано. Решали тем, что в селекте значение кастили к строке, а в коде делали new Decimal(val). Библиотечку Decimal использовали, ибо работали с «деньгами» и такие double-фокусы были недопустимы.
E2e-тесты плохие, потому что петля обратной связи очень длинная (долгая).
Unit-тесты околобесполезны, потому что не гарантируют работоспособности продукта.
Решение — Behavior-тесты. Медленно работающие «концы», те самые «end» из Е2Е можно (и нужно) отрезать, и тесты начинают работать также быстро детерминировано как unit-тесты и продолжают гарантировать корректность логики приложения.
Загвоздка здесь в том, чтобы начать писать код так, чтобы концы можно было отрезАть. Например, при разработке на ангуляре, логику зачастую пишут пишут прямо в разметку. Естественно эту логику не протестировать кроме как посредством Е2Е.
И еще непонятен один вопрос, если проблема в шуме, то почему жгут именно 5G?
Я так понимаю шумом они не должны отличаться от оборудования прошлых поколений, да и вышек 5G пока что должно быть сильно меньше, почему жгут именно их?
Да, мне тоже интересно, а как поджигали то. Вышки, которые я видел, это бетонный столб и на высоте ~15 метров оборудование. Звука никакого не слышал, первый раз вот узнал, что они звук могут издавать.
если вы в экипировке на мотоцикле, то не бессмертны
нравится эта аналогия. Я, когда приходится рефакторить ts код, хоть бы и не нахожусь в абсолютной безопасности, все же имею подсказки где что может сломаться. моя оценка — система типизации отлавливает 90% моих ошибок. не бессмертие, но спасает от подавляющего большинства «тупизны». Бывает такое, что ошибка такая тупая, что когда найдешь — обтекаешь, сил нет, как такое могло произойти. С чистым js регулярно случалось, с ts буквально стало на порядок реже. Без преувеличений.
Про номинальное сравнение типов — я сейчас использую вот такие типы для id:
export interface CompanyId {
companyId: string;
}
соответственно если случайно передать CompanyId в метод принимающий UserId будет ошибка компиляции. И даже если ее как то обойти через any, или еще что то, то рантайм исключение возникнет «ближе» к строке содержащей ошибку.
Интересно, есть ли способ лучше, без выставления флага компиляции.
Я так и не понял, полностью окирпичивается или только смарт тв не работает?
Мне просто интересно, если LG также начнет делать.
На смарт тв плевать с высокой колокольни, лишь бы hdmi работал.
а обычно как это делают? в C++ понятно, можно в строку залезть и символы затереть, а в JS как? Строки ж иммутабельные. Как и в C# и наверное еще много в каких языках.
иммутабельность идет на пару с чистым кодом. Чистый код, т.е. чистые функции, определяются отсутствием сайд-эффектов(в т.ч. мутаций) и отсутствием состояния, т.е. результат функция зависит толко от входных параметров. Если это же перефразировать, то чистые функции не зависят от другого кода и сами не влияют на другой код. Отсюда свойство — чистая функция не может сломаться от изменения в другом коде и другой код не может сломаться при изменении чистой функции. Устойчивость кода к внесению изменений это такой показатель его «хорошести».
Я вот вижу комменты, что динамических типов не бывает вообще, как будто это нетипизованный язык, претензий к немного неточному переводу вот только сейчас вижу.
И кроме динимической проверки типов, в сравнениях и других операциях, есть еще динамическое назначение типов. В переменную можно положить не тот тип, который там был до этого, в поле объекта, в элемент массива. Т.е. такое небольшое искажение в терминологии можно бы понять и простить. Если конечно изначально знать о чем вообще речь.
Это все не меняет того факта, что заголовок статьи о строгой типизации, а текст о динамической, то есть автор не понимает о чем говорит и не читал источник, на который сам же и ссылается.
И, внезапно, тут написано ровно тоже самое. Системы типов бывают нетипизованные (ассемблер, брейнфак, там правда они не приведены), и типизованные.
Типизованные делятся на матрицу статические/динамические по горизонтали и строгие/слабые по вертикали. JS и питона там нет, видимо тогда еще не было, зато есть Perl и Java. Страница 14
Clean code, очевидно не подразумевает написание pure code.
В чистом коде функция не может не иметь ни одного аргумента, ведь ее можно(и нужно) заменить константой.
В остальном — я давно уже пришел к маленьким функциям и маленьким файлам еще.
Ах да, попытка «в лоб» уменьшить количество аргументов обычно приводит к тому, что аргументы схлопывают либо в кортежи либо в plain объекты, что меняет функцию только визуально, проблема не решается. Размер функции и количество аргументов это симптомы болезни, root cause же этой болезни — избыточное количество отвественности в функции. Надо уменьшать ответственность, растаскивая ее на части, декомпозируя то бишь. Количество аргументов и размер функции подтянутся сами.
И Rational тоже допускает потери, по определению, т.к. не имеет бесконечной точности, и к нему также применимо выражение «гарантирует отсустствие потерь, пока не превысится точность», как и к Decimal. В отличие от Double, который дает погрешность уже на примере операции 0.1 + 0.2
Как сохранять в БД бесконечные дроби, да хоть бы и конечные, но с большей точностью, чем стандартные типы. Даже не арифметические операции с такими числами, а просто сохранить в базе и считать без потери.
ЗЫ У нас не было операций деления. Сложение, вычитание и умножение на целое количество процентов(не дает бесконечных дробей, очевидно). А порой просто ввод, хранение и вывод. Double валится уже тут. Decimal на этом всём работает. Это кстати были не банковские деньги, а рассчеты, что то типа выставления сметы.
Гарантирует, пока не превысится точность. Точность не бесконечна естественно, хоть и больше, чем у double.
В JS (как и в шарповом double я думаю) даже без каких либо алгебраических действий можно получить такую кривизну. Просто читаешь ораклом из базы дробное число, получаешь не то что в базе записано. Решали тем, что в селекте значение кастили к строке, а в коде делали new Decimal(val). Библиотечку Decimal использовали, ибо работали с «деньгами» и такие double-фокусы были недопустимы.
Unit-тесты околобесполезны, потому что не гарантируют работоспособности продукта.
Решение — Behavior-тесты. Медленно работающие «концы», те самые «end» из Е2Е можно (и нужно) отрезать, и тесты начинают работать также быстро детерминировано как unit-тесты и продолжают гарантировать корректность логики приложения.
Загвоздка здесь в том, чтобы начать писать код так, чтобы концы можно было отрезАть. Например, при разработке на ангуляре, логику зачастую пишут пишут прямо в разметку. Естественно эту логику не протестировать кроме как посредством Е2Е.
Я так понимаю шумом они не должны отличаться от оборудования прошлых поколений, да и вышек 5G пока что должно быть сильно меньше, почему жгут именно их?
соответственно если случайно передать CompanyId в метод принимающий UserId будет ошибка компиляции. И даже если ее как то обойти через any, или еще что то, то рантайм исключение возникнет «ближе» к строке содержащей ошибку.
Интересно, есть ли способ лучше, без выставления флага компиляции.
Мне просто интересно, если LG также начнет делать.
На смарт тв плевать с высокой колокольни, лишь бы hdmi работал.
И кроме динимической проверки типов, в сравнениях и других операциях, есть еще динамическое назначение типов. В переменную можно положить не тот тип, который там был до этого, в поле объекта, в элемент массива. Т.е. такое небольшое искажение в терминологии можно бы понять и простить. Если конечно изначально знать о чем вообще речь.
Это все не меняет того факта, что заголовок статьи о строгой типизации, а текст о динамической, то есть автор не понимает о чем говорит и не читал источник, на который сам же и ссылается.
Типизованные делятся на матрицу статические/динамические по горизонтали и строгие/слабые по вертикали. JS и питона там нет, видимо тогда еще не было, зато есть Perl и Java. Страница 14