Добавлен GetLocalPlayer,
опубликован
WurstScript
Содержание:
Здесь будет представлено несколько рекомендаций написания Wurst кода, которых вам следует придерживаться.
Правило 1: Пишите для читателя
Следует всегда писать код легкий для чтения. В идеале, код должен читаться так же просто как и обычный текст. Используйте подходящие имена для функций и переменных, чтобы сделать ваш код похожим на обычный текст.
- Создавайте функции, которые позволят выразить ваши намерения наиболее абстрактно
- Если функция или переменная имеет тип boolean, дайте ей имя содержащее вопрос. Имя должно звучать естественно внутри выражения.
- Используйте классы и расширяющие функции, чтобы сделать код удобочитаемым слева направо
Плохо
if GetUnitState(h, UNIT_STATE_LIFE) <= 0.405
let t = NewTimer()
t.setData(...)
t.start(...)
...
Лучше
if hero.isDead()
hero.reviveAt(town, REVIVE_TIME)
// Функции таймера внутри другой, маленькой функции
Правило 1.1: Документируйте ваш код
Правило 1.2: Сохраняйте функции короткими
Правило 1.3: Придерживайтесь "золотого пути"
Избегайте ситуаций, когда работа вашей программы может привести к непредусмотренному результату.
Правило 2: Пишите проверяемый код
Компилятор должен иметь возможность проверять ваш код самостоятельно и выловить всевозможные ошибки, Wurst имеет некоторые инструменты, которые могли бы сделать ошибки для него невидимыми
- Избегайте приведения типов (castTo) везде, где это возможно
- Используйте высокоуровневые библиотеки (такие как HashList) взамен низкоуровневых (например Table или даже встроенного hashtable)
- Используйте кортежи, чтобы наполнить смыслом наборы переменных (пример - пакет Vectors)
- Используйте перечисления в операторе множественного выбора (switch)
Правило 3: Не повторяйтесь
Если вы обнаружили в вашем коде несколько идентичных конструкций, попробуйте выделить их в функцию, класс или модуль.
Правило 4: Будьте проще
Всегда старайтесь найти наиболее простое решение вашей проблемы. Избегайте преждевременной оптимизации.
Правило 5: Используйте объектно-ориентированное программирование
Избегайте instanceof
Использование instanceof обычно является признаком плохого применения ООП. Зачастую, проверка посредством instanceof может быть легко заменена динамической диспетчеризацией. Взгляните на пример
if shape instanceof Circle
Circle c = shape castTo Circle
area = bj_PI * c.radius*c.radius
else if shape instanceof Rect
Rect r = shape castTo Rect
area = r.width * r.height
Будет намного лучше иметь единственный метод area в классе Shape и реализацию этого метода в подклассах Circle и Rect. Тогда можно просто написать
area = shape.area()
Правильный метод будет вызван автоматически, в зависимости от класса shape.
Содержание
Комментарии пока отсутcтвуют.
Чтобы оставить комментарий, пожалуйста, войдите на сайт.