Не бывает ничего красивого «в ваккууме». Красота — субъективная оценка обусловленная опытом. Код становится красивым не потому что его перечитывают воздыхая на полную луну.
Красивым его делает воспоминание о чём-то похожем, проработавшем 25 лет без перезапуска и ночных побудок.
Некарсивым его делает похожее решение обернувшееся предрелизной вечеринкой до 1 ночи и падением отношения dev:QA до 1 за следующие 3 месяца.
> чем человек квалифицированнее, тем он проще пишет и тем проще его код понимать другим
Смотря кому другим. Другим высококвалифицированным программистам — да. Случайным чувакам которыми хряки закрыли план — вряяядли.
Одни люди друг другу нравятся, другие не нравятся. Что с этим делать наука пока не придумала. Деды решали проблему простыми и незатейливыми фразами вроде «Мы таких как ты тут не любим», без претензий на объективность. Но в нашем пузырике эльфиская меритократия, все должно быть объективно. Поэтому говорят «ты токсичный и портишь атмосферу». Не циклитесь на словах, ищите смысл.
Существует мнение что функции более 3х аргументов без их явного именования мажорный тормоз при чтении кода и источник ошибок. Отсутствие поддержки именавания аргументов на стороне вызова я, например, считаю крупнейшим дефектом языка.
> Качество важнее скорости
Надо развернуть, в чём измеряется качество и в чём скорость? Без внятных определений очередная философская херня натянутая на инженерную дисциплину.
> Делать как надо важнее, чем делать как просят
Как надо кому? Просят кто?
«Модульные тесты в Rust писать настолько легко и просто, что хочется это делать снова и снова. :) Зачастую вам будет проще написать модульный тест, чем пытаться протестировать функциональность другим способом.» и тест тавтологии и 2 + 2. Серьёзно? Вам отчаяно не хватало пунктов до круглого числа или Вы реально думаете что такой пример что-то доказывает?
1. Реализация в ручную означает еще один способ ошибиться. Во всех программах что мне приходилось писать в них небыло недостатка.
2. «Простой» — нет. Он путает два разных объекта и два пути исполнения. Еще полезное упражнение представить что ваша предметная область аудит логов, в которых есть удачные и неудачные записи и сообщения об ошибках :)
3. «Понятный» — нет. Он даёт возможность создавать объекты с неоднозначным состоянием в которых заполнены и поля данных и поля ошибок. Нужно разрабатывать соглашение что мы с ними делаем, как ищем источник, его надо доносить до всей команды, держать в голове.
4. «Приводящий обработку ошибок к единообразному стилю» — во снах CTO возможно. В коде — это гарантия бардака.
Вы рассказываете про оконные бибилиотеки 80-90х. Все преимущества такого подхода сводятся к «это было первое что пришло в голову». В качестве альтернативы можно посмотреть на HTML, просто структура данных.
Кстати, описывать событие как метод который зовёт бибилиотека и а прикладной разработчик переопределяет — исключительно плохая идея. Это крайне затрудняет обработку сценариев о которых авторы библиотеки не подумали и отличный способ запутать построение интерфейса с реакцией на события. Например QT видели эту проблему еще в середине 90х, и несмотря на некоторую ангажированность языка сделали более функциональную систему сигналов и слотов. Пользуясь случаем хочу передать горячий привет авторам андроида :)
Красивым его делает воспоминание о чём-то похожем, проработавшем 25 лет без перезапуска и ночных побудок.
Некарсивым его делает похожее решение обернувшееся предрелизной вечеринкой до 1 ночи и падением отношения dev:QA до 1 за следующие 3 месяца.
Смотря кому другим. Другим высококвалифицированным программистам — да. Случайным чувакам которыми хряки закрыли план — вряяядли.
Если есть конкретные проблемы надо с них начинать. Оценки можно и в конце расставить, да и мало кто расстроится если на них вообще забить.
Если есть только ощущения и задетые эстетические чувства можно перейти к изложению альтернатив.
Если конкретных проблем и альтернативных решений нет стоит жать кнопку приянть, сэкномит время коллег и деньги работодателя.
Существует мнение что функции более 3х аргументов без их явного именования мажорный тормоз при чтении кода и источник ошибок. Отсутствие поддержки именавания аргументов на стороне вызова я, например, считаю крупнейшим дефектом языка.
Пойдёт.
> Качество важнее скорости
Надо развернуть, в чём измеряется качество и в чём скорость? Без внятных определений очередная философская херня натянутая на инженерную дисциплину.
> Делать как надо важнее, чем делать как просят
Как надо кому? Просят кто?
А надувать щёки и рассказывать что точно знаете Правильное Значение Слова а кто не знает тот джун/студент и не имеет права писать — норм?
2. «Простой» — нет. Он путает два разных объекта и два пути исполнения. Еще полезное упражнение представить что ваша предметная область аудит логов, в которых есть удачные и неудачные записи и сообщения об ошибках :)
3. «Понятный» — нет. Он даёт возможность создавать объекты с неоднозначным состоянием в которых заполнены и поля данных и поля ошибок. Нужно разрабатывать соглашение что мы с ними делаем, как ищем источник, его надо доносить до всей команды, держать в голове.
4. «Приводящий обработку ошибок к единообразному стилю» — во снах CTO возможно. В коде — это гарантия бардака.
Кстати, описывать событие как метод который зовёт бибилиотека и а прикладной разработчик переопределяет — исключительно плохая идея. Это крайне затрудняет обработку сценариев о которых авторы библиотеки не подумали и отличный способ запутать построение интерфейса с реакцией на события. Например QT видели эту проблему еще в середине 90х, и несмотря на некоторую ангажированность языка сделали более функциональную систему сигналов и слотов. Пользуясь случаем хочу передать горячий привет авторам андроида :)