Когда примут, то на классах уже писать никто не будет
уметь?
А вообще знаковый комментарий, характеризующий. Если перевести с русского на русский:
я не знаю ООП и не понимаю, где его нужно использовать
UPD: а ещё смешнее, что незнание (-- сила) ООП внезапно находит поддержку среди комментаторов -- комментарий не только минусовали. Не переключаемся, смотрим за развитием событий
Прекрасный код, не находите? Идеалочный. Усложните в своём воображении преобразование на +2 этапа и добавьте больше типов (UInt8Array, ArrayBuffer) и ещё чего-нибудь любопытного -- и начнёт бросаться в глаза сложность сопровождения 2го варианта -- на каждое изменение кода необходимо затрагивать не одну, а минимум 2 строки
// Я в этом коротком примере вылавливаю уже 4й баг. А вот и 5й. Знаете, я начинаю что-то понимать в этой жизни. С такой манерой написания кода у программистов всегда будет работа. В аду.
В принципе, если число таких функций будет расти дальше, есть резон всё это заменить на Array.reduce, но это уже другая история и не всегда возможно
Спасает написание читабельного кода. Запхать всё в одну строку и навернуть кучу вложенных конструкций в одной строке -- вот уж где и просто читается, и просто отлаживается.
Если раскидать код на отдельные строки -- читается сильно проще
Пользуясь моментом: я до сих пор не понимаю, в чём разница между l10n и i18n. Определение/расшифровка не интересуют. Интересует суть -- чем одно отличается от другого
В статье данными 2020 года. Странно не видеть Беларуси
Меня (политического) держали в Жодино. Дворик меньше, чем тот, что в Хакасии для злобных нарушителей, но тоже "небо в клеточку". Камеры сопоставимы с ИК "Чёрный дельфин". Только окна у нас были нарешёчены настолько, что понять, за окном день или ночь, не представлялось возможным
Кстати, а шо ж не фотографировали камеру с обратной стороны? Шо ж не видно достижения гениальной советской тюремной мысли "параша"?
Лично я бы использовал три разных переменных (точнее, три разных константы). С разными именами, отражающими смысл данных.
Это сильно лучше, чем предложение снизу запердолить всё в одну строку. Нередко в этом даже есть смысл. Но в функции, которая занимается, например, только сериализацией данных и ничем больше, заводить гору переменных -- это трэш. Если бизнес скажет, что необходима обфускация потока данных, и вы решите JSON преобразовывать ещё в base64 -- вам придётся затронуть не одну строку, но ещё и следующую. А как удобно в целях отладки отключать этапы! Изменения такого неоднородного кода над одной сущностью будут болезненными.
Блог PVS-Studio не раз и даже не два показывал силу и эффективность статического анализа кода как средства отлова ошибок на как можно более ранних стадяих. И вроде бы TypeScript тоже претендует на эту нишу. Но как-то не получается
let data = { a: 1, b: 2, c: 3 }; data = JSON.stringify(data); data = AnythingOther(data);
И в таком примере TypeScript будет немножечко не доволен
Все приведённые примеры про статический текст, что решается совсем просто. Мой интерес, как решают проблемы типа той, что приведена ниже, не удовлетворён:
Поле ${field} заполнено неверно: ${error_description}
Вообще тут проблема в дизайне самого JS: шаблоны строк мы завезли, а явных методов форматирования нет
Хотел почитать интересную статью, но сразу сломался на слове «клиффхэнгер» и потерял нить повествования.
Согласен, для терминов, которые с высокой вероятностью будут новыми для аудитории, есть подсказки или ссылки. ЧСХ, подсказки есть только в посте, но нет в комментариях
В python декораторы существуют и активно используются не первое десятиление. Что-то мне подсказывает, что паттерн жизнеспособен
уметь?
А вообще знаковый комментарий, характеризующий. Если перевести с русского на русский:
UPD: а ещё смешнее, что незнание (-- сила) ООП внезапно находит поддержку среди комментаторов -- комментарий не только минусовали. Не переключаемся, смотрим за развитием событий
Ох уж этот народец... Сидят на ж ровно, как будто ничего не происходит
Бинго. Теперь погнали. Есть 2 сегмента кода:
Допустим, добавляем 3ю строчку. Например, бизнесу стрельнуло гонять не JSON, а base64. Ошибиться в таком коде сложно. Но, по-вашему, код ужасен:
Исправим его!
Прекрасный код, не находите? Идеалочный. Усложните в своём воображении преобразование на +2 этапа и добавьте больше типов (UInt8Array, ArrayBuffer) и ещё чего-нибудь любопытного -- и начнёт бросаться в глаза сложность сопровождения 2го варианта -- на каждое изменение кода необходимо затрагивать не одну, а минимум 2 строки
// Я в этом коротком примере вылавливаю уже 4й баг. А вот и 5й. Знаете, я начинаю что-то понимать в этой жизни. С такой манерой написания кода у программистов всегда будет работа. В аду.
В принципе, если число таких функций будет расти дальше, есть резон всё это заменить на Array.reduce, но это уже другая история и не всегда возможно
Спасает написание читабельного кода. Запхать всё в одну строку и навернуть кучу вложенных конструкций в одной строке -- вот уж где и просто читается, и просто отлаживается.
Если раскидать код на отдельные строки -- читается сильно проще
Найс! Спасибо!
Это ответ на что угодно, но не мой вопрос
Пользуясь моментом: я до сих пор не понимаю, в чём разница между l10n и i18n. Определение/расшифровка не интересуют. Интересует суть -- чем одно отличается от другого
В статье данными 2020 года. Странно не видеть Беларуси
Меня (политического) держали в Жодино. Дворик меньше, чем тот, что в Хакасии для злобных нарушителей, но тоже "небо в клеточку". Камеры сопоставимы с ИК "Чёрный дельфин". Только окна у нас были нарешёчены настолько, что понять, за окном день или ночь, не представлялось возможным
Кстати, а шо ж не фотографировали камеру с обратной стороны? Шо ж не видно достижения гениальной советской тюремной мысли "параша"?
А смысл? Одно дело, когда подвозят типизацию в URL template на бэке типа такого:
На этапе парсинга да, типизация ключей важна. А тут задача обратная -- просто в строку кастануть. Какой смысл типизировать ключи?
Тайп чекер не спасает от ошибок в реализации бизнес-логики, о которых я рассказал. Удачной отладки!
То есть несериализуемых в JSON объектов не существует, верно?
Что TS, что анализатор PVS-Studio позволяют обнаружить ошибки до запуска кода
Это сильно лучше, чем предложение снизу запердолить всё в одну строку. Нередко в этом даже есть смысл. Но в функции, которая занимается, например, только сериализацией данных и ничем больше, заводить гору переменных -- это трэш. Если бизнес скажет, что необходима обфускация потока данных, и вы решите JSON преобразовывать ещё в base64 -- вам придётся затронуть не одну строку, но ещё и следующую. А как удобно в целях отладки отключать этапы! Изменения такого неоднородного кода над одной сущностью будут болезненными.
Да, отличная идея. Просто чудесный код. И лимит в 80 символов соблюдается, и отлаживать легко, и читается тоже прекрасно.
Блог PVS-Studio не раз и даже не два показывал силу и эффективность статического анализа кода как средства отлова ошибок на как можно более ранних стадяих. И вроде бы TypeScript тоже претендует на эту нишу. Но как-то не получается
let data = { a: 1, b: 2, c: 3 };
data = JSON.stringify(data);
data = AnythingOther(data);
И в таком примере TypeScript будет немножечко не доволен
UPD: ммм, статья обновлена. Спасибо!
Все приведённые примеры про статический текст, что решается совсем просто. Мой интерес, как решают проблемы типа той, что приведена ниже, не удовлетворён:
Поле ${field} заполнено неверно: ${error_description}
Вообще тут проблема в дизайне самого JS: шаблоны строк мы завезли, а явных методов форматирования нет
Это понятно. Очевидно, намеренно простой код используется для иллюстрации
Ваша лодка готова, капитан!
Согласен, для терминов, которые с высокой вероятностью будут новыми для аудитории, есть подсказки или ссылки. ЧСХ, подсказки есть только в посте, но нет в комментариях