Как анонимная функция из props.ref хранится в памяти больше чем одним экземпляром, если это одна и та же функция в дереве кода?
Как тут может быть утечка? Обьясните пожалуйста.
Этот подход для новичка может показаться нормальным, но он имеет очень много «косяков», и не подходит для больших проектов. Давай по порядку:
— Имена переменных. Выше обсуждалось, код должен быть читабельным без комментариев.
— Большая функция. Выходит больше строк кода, что значит больше переменных, а значит длиннее их имена. Я бы выносил логические блоки в другие методы, даже если метод будет вызываться всего один раз.
— Много переменных. Состояния мыши в можно объединить в структуру и передавать её между методами. Можно будет написать проверку не так:
где в isCopyCase я бы скомбинровал проверку правильным образом.
— Код будет редактироваться другими членами команды, и чтобы оставить его «читабельным», они должны писать так-же неправильно. И скорее всего они не будут следовать твоим внутренним правилам, и через 3-4 сторонние правки вряд-ли сам поймешь, что происходит в коде.
— Для постройки строк оптимальнее использовать StringBuilder.
— Правильное разделение кода на пакеты, классы, методы дает возможность покрывать код тестами. Код например можно разделить на блоки: «вычитка состояния», «проверка», «выполнения действия». И нет ни одной причины писать всё это в одном вместе.
В общем, есть интересная книжка — «Боб Мартин — Чистый код», она перевернёт твой взгляд, как однажды перевернула и мой. Советую почитать.
Автор, помогите разобраться со второй "ошибкой разработчика".
Использование анонимных функций в props разворачивается из
в следующий вызов
Как анонимная функция из props.ref хранится в памяти больше чем одним экземпляром, если это одна и та же функция в дереве кода?
Как тут может быть утечка? Обьясните пожалуйста.
Во второй задаче, если мат ставить ферзь C3 с превращением пешки в коня — пешка чёрных может пойти C6 и поменяться с королём.
— Имена переменных. Выше обсуждалось, код должен быть читабельным без комментариев.
— Большая функция. Выходит больше строк кода, что значит больше переменных, а значит длиннее их имена. Я бы выносил логические блоки в другие методы, даже если метод будет вызываться всего один раз.
— Много переменных. Состояния мыши в можно объединить в структуру и передавать её между методами. Можно будет написать проверку не так:
а, хотя бы так:
где в isCopyCase я бы скомбинровал проверку правильным образом.
— Код будет редактироваться другими членами команды, и чтобы оставить его «читабельным», они должны писать так-же неправильно. И скорее всего они не будут следовать твоим внутренним правилам, и через 3-4 сторонние правки вряд-ли сам поймешь, что происходит в коде.
— Для постройки строк оптимальнее использовать StringBuilder.
— Правильное разделение кода на пакеты, классы, методы дает возможность покрывать код тестами. Код например можно разделить на блоки: «вычитка состояния», «проверка», «выполнения действия». И нет ни одной причины писать всё это в одном вместе.
В общем, есть интересная книжка — «Боб Мартин — Чистый код», она перевернёт твой взгляд, как однажды перевернула и мой. Советую почитать.