Как стать автором
Обновить
12
0

Разработчик

Отправить сообщение

В python декораторы существуют и активно используются не первое десятиление. Что-то мне подсказывает, что паттерн жизнеспособен

Когда примут, то на классах уже писать никто не будет

уметь?

А вообще знаковый комментарий, характеризующий. Если перевести с русского на русский:

я не знаю ООП и не понимаю, где его нужно использовать

UPD: а ещё смешнее, что незнание (-- сила) ООП внезапно находит поддержку среди комментаторов -- комментарий не только минусовали. Не переключаемся, смотрим за развитием событий

Ох уж этот народец... Сидят на ж ровно, как будто ничего не происходит

Бинго. Теперь погнали. Есть 2 сегмента кода:

function doAnything(data: Object) return String {
	data = JSON.stringify(data);
	// data = AnythingOther(data);
	if (data.length < 15) {
    data += ' ' * (15 - data.length);
  }
  return data;
}

Допустим, добавляем 3ю строчку. Например, бизнесу стрельнуло гонять не JSON, а base64. Ошибиться в таком коде сложно. Но, по-вашему, код ужасен:

Таким кодом даже я, как разработчик, недоволен

Исправим его!

function doAnything(data: Object) return String {
	const jsonData: String = JSON.stringify(data);
	// convertedData: String = AnythingOther(jsonData);
	if (jsonData.length < 15) {
    const jsonDataPlus: Srting = jsonData + ' ' * (15 - jsonData.length);
  }
	return jsonDataPlus;
}

Прекрасный код, не находите? Идеалочный. Усложните в своём воображении преобразование на +2 этапа и добавьте больше типов (UInt8Array, ArrayBuffer) и ещё чего-нибудь любопытного -- и начнёт бросаться в глаза сложность сопровождения 2го варианта -- на каждое изменение кода необходимо затрагивать не одну, а минимум 2 строки

// Я в этом коротком примере вылавливаю уже 4й баг. А вот и 5й. Знаете, я начинаю что-то понимать в этой жизни. С такой манерой написания кода у программистов всегда будет работа. В аду.

В принципе, если число таких функций будет расти дальше, есть резон всё это заменить на Array.reduce, но это уже другая история и не всегда возможно

Спасает написание читабельного кода. Запхать всё в одну строку и навернуть кучу вложенных конструкций в одной строке -- вот уж где и просто читается, и просто отлаживается.

Если раскидать код на отдельные строки -- читается сильно проще

Найс! Спасибо!

Это ответ на что угодно, но не мой вопрос

Пользуясь моментом: я до сих пор не понимаю, в чём разница между l10n и i18n. Определение/расшифровка не интересуют. Интересует суть -- чем одно отличается от другого

В статье данными 2020 года. Странно не видеть Беларуси

Меня (политического) держали в Жодино. Дворик меньше, чем тот, что в Хакасии для злобных нарушителей, но тоже "небо в клеточку". Камеры сопоставимы с ИК "Чёрный дельфин". Только окна у нас были нарешёчены настолько, что понять, за окном день или ночь, не представлялось возможным

Кстати, а шо ж не фотографировали камеру с обратной стороны? Шо ж не видно достижения гениальной советской тюремной мысли "параша"?

А смысл? Одно дело, когда подвозят типизацию в URL template на бэке типа такого:

Route('/users/{user_id:int}', user)
Route('/floating-point/{number:float}', floating_point)
Route('/uploaded/{rest_of_path:path}', uploaded)

На этапе парсинга да, типизация ключей важна. А тут задача обратная -- просто в строку кастануть. Какой смысл типизировать ключи?

Тайп чекер не спасает от ошибок в реализации бизнес-логики, о которых я рассказал. Удачной отладки!

То есть несериализуемых в JSON объектов не существует, верно?

у них же не реалтайм анализатор в отличие от ts?

Что 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: шаблоны строк мы завезли, а явных методов форматирования нет

Это понятно. Очевидно, намеренно простой код используется для иллюстрации

Ваша лодка готова, капитан!

Хотел почитать интересную статью, но сразу сломался на слове «клиффхэнгер» и потерял нить повествования.

Согласен, для терминов, которые с высокой вероятностью будут новыми для аудитории, есть подсказки или ссылки. ЧСХ, подсказки есть только в посте, но нет в комментариях

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность

Специализация

Fullstack Developer
Senior
Git
Linux
SQL
Python
OOP
MySQL
PostgreSQL
Docker
Nginx
High-loaded systems