Comments 10
UFO just landed and posted this here
Ссылку на оригинальную статью дадите?
Паттерны багов улыбнули. Давайте писать без перегрузки операторов, auto, DI и мьютексов.
Паттерны багов улыбнули. Давайте писать без перегрузки операторов, auto, DI и мьютексов.
И без полиморфных функций.
Ссылка вообще-то скрыта в первом предложении под словом «публикуем»: medium.freecodecamp.org/how-to-write-fewer-bugs-tips-for-game-developers-82e3d742f6f7
Я готовился увидеть статью из толкового словаря по индексу «публиковать».
На самом деле в статье есть ссылка на слайды, там есть пара примеров вполне жизненных, но на мой вкус маловато. Их должно быть раз в 15 больше.
Вообще там авты всякие я и сам истребляю, ибо для прототипирования, когда всё быстро и строчки прямо с пальцев слетают это удобно, а поддерживать код после них — как читать, густо полив глаза шампунем.
Вообще правила сформулированы и в переводе и в оригинале очень неважно. Автор не призывает отказываться от интерфейсов и полиморфизма в принципе. Просто реально встречаются такие места, когда в одном объекте несколько функций с одинаковыми именами и разными аргументами, внутри бизнес-логика. И найди потом баги. А с другой стороны это хорошо когда все ваши коллекции имеют одинаковый метод Sort(Filter[] filters = null) с предсказуемым результатом.
Статья так себе. Как идея «хорошо бы на эту тему подумать и как-то её развить» сойдёт. Публиковать такой сырой материал — не очень. Лучше меньше, но лучше.
Я готовился увидеть статью из толкового словаря по индексу «публиковать».
На самом деле в статье есть ссылка на слайды, там есть пара примеров вполне жизненных, но на мой вкус маловато. Их должно быть раз в 15 больше.
Вообще там авты всякие я и сам истребляю, ибо для прототипирования, когда всё быстро и строчки прямо с пальцев слетают это удобно, а поддерживать код после них — как читать, густо полив глаза шампунем.
Вообще правила сформулированы и в переводе и в оригинале очень неважно. Автор не призывает отказываться от интерфейсов и полиморфизма в принципе. Просто реально встречаются такие места, когда в одном объекте несколько функций с одинаковыми именами и разными аргументами, внутри бизнес-логика. И найди потом баги. А с другой стороны это хорошо когда все ваши коллекции имеют одинаковый метод Sort(Filter[] filters = null) с предсказуемым результатом.
Статья так себе. Как идея «хорошо бы на эту тему подумать и как-то её развить» сойдёт. Публиковать такой сырой материал — не очень. Лучше меньше, но лучше.
С такими заголовками могут привлечь за экстремизм
При создании нового проекта необходимо избегать…Это сильно напоминает идею с передвиганием кроватей.
— Перегрузка операторов…
— Auto, полиморфные функции…
— Использование мьютексов, семафоров…
Auto, полиморфные функции и пренебрежение типобезопасностью.
вот как раз пренебрежение auto и полиморфными функциями ведет к раздуванию кода и копипасте, а это (если верить блогу pvs studio) как раз причина возникновения большинства ошибок
Какая то статья не о чем. Кратко: оказалось, что наши программисты запутались в собственном коде.
Какой-то манифест Make it simple stupid получился.
А на деле надо было разобраться почему неправильно использовались инструменты языка. А то "пренебрежение типобезопасностью" и проблемы с синхронизацией потоков наводят на мысли о кривой архитектуре. Ну и как вишенка — детские болезни с переопределением операторов. А auto и полиморфизм где не надо уже моло что мог испортить
Sign up to leave a comment.
Ликвидировать нужно не баги, а причину их появления: кейс от разработчика игр