Войти на сайт
×
ТЕМА: Разделение плагина на несколько файлов
Разделение плагина на несколько файлов 6 года 2 мес. назад #102277
          |
|
|
Разделение плагина на несколько файлов 6 года 2 мес. назад #102279
|
|
|
Разделение плагина на несколько файлов 6 года 2 мес. назад #102284
|
|
|
Разделение плагина на несколько файлов 6 года 2 мес. назад #102291
|
Книжка, в целом, правильная. Но есть спорные моменты.
Например, не приписывать название типа после имени переменной. В некоторых моментах, очень удобно дописать тип, чтобы значительно быстрей выбрать нужную переменную из списка предложенных. Например, есть индикатор здоровья с иконкой сердечка, надписью "Health" и полоской. Все это на одной сцене и очень удобно назвать их переменные: healthicon, healthLabel и healthBar. В остальных случаях, когда объект один или есть возможность сгруппировать элементы в объект, тип писать нет смысла, да? Имена должны передавать намерения программиста Для временных и вспомогательных, которые используются в ближайшие 5-10 строчек, в принципе, можно и сокращение использовать. Вроде "str", "spr" или "len". Венгерская запись Хз, насколько они нужны, но от опечаток и ошибок при выпиливании фрагмента программы, когда внезапно оказалась одноименная локальная переменная, спасают неплохо.  IShapeFactory и ShapeFactory Очень полезный пункт. Если не знаешь, как назвать получше, можно использовать DefaultShapeFactory или CommonShapeFactory. Не используйте: Manager, Processor, Data, Info. Иногда нереально сложно не использовать. Например, "SceneManager". Пусть он не делает сам ничего, а только раздает работу другим и собирает результаты, как точка входа. Но хз как его иначе назвать. SceneFactory? Но он же их еще запускает и куда-то сам вставляет вроде... Методы чтения/записи и предикаты образовываются из значения и префикса get, set, is. Еще есть has, on, did, can... Обозначение двух разных идей одним термином – это каламбур. Совсем не согласен. Реализация зависит от контекста. Как они говорили в другом пункте про ясность работы от типа переменной и тут так же: "Если тип переменной Array, то итак понятно, что они не будут складывать какие-то числа и т д". Так в некоторых случаях можно и имен не напастись или слишком их усложнить. Да и, Array.add соединяет вызывающего и аргумент в один объект, как и числа или строки. Та же сумма, грубо говоря, только среди элементов другого типа. В общем, имя метода должно напоминать о действии из реального мира. Тут я не могу использовать add для массива и использую insert, потом я не могу использовать add или insert для размещения элемента на сцене использую put или place. Потом я не могу использовать add, insert или put/place для помещения объекта в режим ожидания и т д. А если б я назвал помещение на сцену "spawn", то не смог бы по этой логике, использовать spawn при введении персонажа в игру... GSDAccountAdress – 10 из 17 символов в этом имени избыточны. Тут тоже согласен. Для этого часто есть пространства имен. А если нету, можно на секунду взгрустнуть и создать вложенный класс, вроде 'GradientBackground.Color' или приписать имя класса или контекста, вроде 'GameBoardPoint'. Блоки в командах if, else, while должны состоять из одной строки, в которой обычно содержится вызов функции. Ну, не обязательно из одной... Часто удобней добавить несложные условия прямо в блок, вместо выделения под это функции. Например: events.forEach(function(item) {
var actor = item.actor;
if (actor.isDead() && actor.canRespawn) {
actor.respawnCounter -= 1
} else {
actor.makeTurn()
}
})Вообще, главное в разбиении функций знать меру и не увлекаться. Если она не влзит в экран, чувствуется, что в каком-то ее фрагменте возможно нарастание строк или потенциальное место бага, который придется ловить, то этот фрагмент точно хорошо бы вынести отдельно. Код должен читаться как рассказ сверху-вниз. За каждой функцией должны следовать следующего уровня абстракции. Спорный момент. Где-то это будет удобно, а где-то эти функции начинают мешать видеть "высокоуровневую" логику класса. Или один метод используется несколькими методами и никак не расположить его так, чтобы он находился после каждого из использующих его методов. Тут я за вынос методов с конкретной логикой отдельно от методов с ее абстрактной частью. Не бойтесь использовать длинные имена. Но все-равно стоит попытаться сформулировать то же, но по-короче. Например: battleScene.isAnyEnemyStillAliveAndCanMakeTurn() против battleScene.hasNotDisabledEnemy() |
|
|
Модераторы: NeKotZima