Айтишник родился
NaN это не определенная операция, например если попробовать поделить строку на число. Для бесконечности есть infinity же
раскрыть ветку (1)
раскрыть ветку (1)
Удивительно, но лн прав, просто нужно складывать строку и число и тогда будет знак определяться, как конкатенация . "1"+1
показать ответы
Юнит тесты для этого как раз придумали.
Кстати об ошибках, готов?
Вот у тебя простейшая функция: console.log которая служит для вывода информации.
Если ты пихнёшь в неё ЛЮБОЕ ЗНАЧЕНИЕ кроме строки при подходе лишь выдавания ошибок, то получишь ошибку и нужно будет везде писать toString.
И допустим нам надо вывести текст: Объект обработан:/Здесь сам объект/
А вот как это будет в JS (старой версии):
console.log('Объект обработан:'+object)
В современных можно ещё так:
console.log(`Объект обработан:{object}`)
А в Python:
console.log(f'Объект обработан:{object}') даст тебе ошибку, потому что ты не прописал у object магический метод __str__
раскрыть ветку (1)
Не совсем понятно , как юнит тесты здесь помогают. Юнит тесты закроют лишь малую часть возможных проблем. Тестовая среда отличается от реальной и, более того, вы не покрываете в юнитах взаимодействия компонентов. Если где-то на входе вы не обработали типы, вы можете получить катастрофу, про которую вы не узнаете, пока она не произойдет.
1 + 1 + '1' = '21'
'1' + 1 + 1 = '111'
- это предсказуемо? Может быть, но лучше бы там была ошибка типов при наличии хорошего сахара для обработки исключений, как в питоне.
раскрыть ветку (1)
Все верно, не понимаю, но почему-то ошибки людям не нравятся. Лучше увидеть ошибку, чем не замечать того, что в прилаге в принципе расчеты неверны, пока не случится инцидент.
показать ответы
Явно нет, т.к. (яблоко + одно) не равно на js (одно яблоко). Это всего лишь применение русского языка. А на математике будет 2 яблока. Нужно было указать через что решать.
раскрыть ветку (1)
Этот пост залетает в Горячее на реактивной тяге от полыхающих жоп людей, оставляющих комментарии. Так работает система горячего, что уж тут.
раскрыть ветку (1)
Ну с первым примером все просто
!! - приводит к логическому значению.
А т.к. мы передаем не true или false, а 'true' и 'false', т.е. две строки, то и сравниваем, по сути, true и true.
По этой же логике:
!!'false' == !!'abrakadabra' // -> true
!!'false' == !!'' // -> false (пустая строка между двух кавычек)
!!'false' == !!false // -> false
!!'true' == !!true // -> true
Со вторым случаем как-то не сталкивался, но, судя по всему, т.к. на выходе получаем строку, то вся внутрянка массива преобразуется в строку и операция идентична "1,2,3"+"4,5,6" = "1,2,3,4,5,6"
То же самое будет верно и для
[1,2,3]+[4,5,6]+[7,8,9] // -> 1,2,34,5,67,8,9'
и для
[1,"a",3]+[4,"b",6]+[7,"c",9] -> '1,a,34,b,67,c,9'
Логика та же, что и с C: не зная спецификацию языка все кажется магией и не поддается логике.
раскрыть ветку (1)
В некоторых ЯП 'false' == false, я думаю это имеет некоторый смысл и спасает как "защита от дебила".
В случае с сложением проще было бы конвертировать все мат. операции одинаково, проблема судя по всему, в том, что объединили знак конкатенации и сложения под одним символом
Кто шарит? В JS автоматического преобразования типа данных нет что ли? 1+1 должно быть 2, так как тип данных число. 11 будет если сделать жёсткую привязку тип данных строка
раскрыть ветку (1)
Есть просто сложение строки и числа преобразует число в строку, вычитание преобразует строку в число. Какая-то логика есть, но очень странная. Есть множество других странных вещей, например:
!!'false' == !!'true' // -> true
[1, 2, 3] + [4, 5, 6] // -> '1,2,34,5,6
показать ответы
Чего все доебались до JavaScript? Такая фигня же в любом языке с динамической типизацией есть, разве нет?
раскрыть ветку (1)
Нет, такая проблема, по определению, может быть только в ЯП с дин. типизацией, где символ имеет множество применений, в данном случае он является оператором сложения и оператором конкатенации. Приведение к определенному типу также работает по разному