Единый стиль наименований событий (event)

Название события начинается с приставки "On". Последующие слова названия начинаются с заглавной буквы. Оканчивается название события суффиксом "Event".

Название метода, подписанного на событие, начинается с приставки "On", последующие слова названия начинаются с заглавной буквы. В отличие от названия события НЕ ОКАНЧИВАЕТСЯ суффиксом "Event".

Небольшое отличие в названиях событий и подписанных на них методов позволяет моментально отличить событие от метода, когда среда разработки (IDE), предлагает автоподстановку, при написании кода. Уменьшается вероятность совершить промах, увеличивается скорость написания кода, повышается "понятность" кода.

___
#лр_хороший_код

Модификаторы доступа пишутся ВСЕГДА

В некоторых источниках (и Unity в том числе) предлагается при использовании модификатора "private" - его опускать. То есть явно указывать лишь "public" и "protected". В таком случае методы и переменные уже не выглядят унифицировано, а следовательно при беглом чтении кода создается маленький хаос в голове. Удобнее читать, когда все методы и переменные выглядят одинаково.

___
#лр_хороший_код

Показывай в инспекторе не публичные поля

Почти во всех видеоуроках (даже моих), курсах, туториалах и т.д. для настройки какого-то поля в инспекторе, в классе его помечают как public,

public Transform myPivot;

У этого подхода есть явный минус: он слабо выдерживает проверку на инкапсуляцию (принцип прячь все, о чем не должны знать другие).
Возьмем для примера код выше. Он подразумевает, что я из другого класса могу поменять пивот при помощи примерно такого кода:

someClass.myPivot = newPivot;

Для начинающих разработчиков такой подход - очень частое явление. Скорее всего, после такого изменения что-то сломается. Поэтому необходимо спрятать переменную, но при этом оставить возможность положить ссылку в редакторе. Объявление становится таким:

[SerializeField] private Transform myPivot;

Доступ извне закрыт. Все хорошо.
Если доступ извне нужен на чтение, рекомендуется дополнительно использовать свойство, немного изменив название приватной переменной:

[SerializeField] private Transform m_myPivot;

public Transform myPivot => this.m_myPivot;

В таком случае, нежелательное изменение исключено, а доступ на чтение есть.

___
#лр_хороший_код

Запилил урок с объяснением, как работают принципы ООП (объектно-ориентированного программирования) на практике в играх.
https://www.youtube.com/watch?v=od_hbf_sdvU&t
___
#лр_туториал

Почему я использую this, когда это совсем не обязательно

Вот уже несколько месяцев я пишу ключевое слово this перед переменными и методами класса. Важно отметить, что this можно писать только указывая на объекты текущего класса, и которые инициализированы при сборке, а не созданы во время выполнения методов (см. пример 1 ниже).

С одной стороны, каждый раз вписывать this - это лишнее время, доли секунды, но тем не менее. Однако, это даёт следующие плюсы:

1. Удобочитаемость. Когда я вижу ключевое слово this, я понимаю, что переменная или метод объявлены при сборке, в случае переменных - в начале класса. То есть, я знаю, где искать начало, и что где-то задано их значение по умолчанию. Я об этом не задумываюсь. Особенно, когда смотрю на код спустя пару месяцев.
2. Возможность не тратить силы на придумывание и написание имен для параметров публичных методов (см. пример 2 ниже). При отсутствии ключевого слова this, придётся называть переменную в параметрах метода как-то отлично от локальной переменной. От этого может пострадать понятность кода, что самое главное.

Не бойтесь тратить на this время. При должном количестве практики, вы привыкнете к этому слову и не будете замечать его написание. И будете рады, что пользуетесь им, взглянув на свой код спустя несколько месяцев.

___
#лр_хороший_код

Пользуйся словарями (Dictionary) - это удобно

Новички часто сторонятся использовать Dictionary. Это происходит по разным причинам, но в основном из-за того, что не до конца понимают его работу.

Если не погружаться в тонкости, то Dictionary - это таблица с двумя столбцами: ключ и значение.
- Одна строка этой таблицы - это один элемент (ключ + значение).
- И ключ и значение могут быть любыми типами данных.
- Нельзя вставить в один Dictionary два одинаковых ключа - выпадет исключение.
- Можно вставлять одинаковые значения с разными ключами.

Dictionary удобно использовать при хранении квестов, продуктов, скинов, инвентаря и других перечисляемых массивов.

P.S. В название переменной типа Dictionary в конце я всегда приписываю ~Map, так при подсказках IDE моментально становится понятно, какой это тип данных и при, начиная набирать map, интеллектуальный набор будет давать подсказки в виде уже существующих Dictionary. Просто и удобно!

___
#лр_хороший_код

Запилил урок с объяснением, как работает паттерн "Состояние" или "Поведение" на практике в играх.
https://www.youtube.com/watch?v=qaP8XLZap68
___
#лр_туториал

Короче методы - понятнее код

Эта тема уже достаточно изжевана в книгах, однако, не все читают книги, поэтому вкратце расскажу.
Важно помнить, что наравне с тем, что у каждого класса должна быть одна ответственность, каждый метод также должен выполнять одно действие. Правда, не стоит пускаться в разнос и писать методы в одну строчку.

Есть правило: метод должен быть таким размером, чтобы он умещался на одном экране по высоте. То есть программист должен видеть на экране метод целиком, без прокручивания вниз или вверх.

___
#лр_хороший_код

Урок о том, что такое события (Event) в C#, как они работают, и почему их нужно повсеместно использовать при разработке игра на Unity3D.

https://www.youtube.com/watch?v=tfVnD1x1iqk

___
#лр_туториал

Для качественной видеозаписи геймплея игры используй нативный Unity Recorder.
Устанавливается через Package Manager. Работает как часы!

___
#лр_советы

Коротенький урок о паттерне проектирования под названием Синглтон (Singleton). Рассказываю, что это и как им пользоваться в разработке игр в Unity3D

https://youtu.be/HFfSHlmMVzk

___
#лр_туториал

Недавно меня бесил момент, что у меня нет нормальной системы наград, которая могла бы кочевать из проекта в проект, была бы очень гибкой и удобной, чтобы я мог в качестве награды использовать вообще любую сущность.

Done!
https://github.com/vavilichev/RewardsSystem
___
#vavilichevgd #gamedev #Unity

Урок, посвященный расширениям (Extensions) в C#. Рассказываю на примерах, что это и как этим пользоваться при разработке игр в #unity3d
https://youtu.be/wHnQ4QVjQuc
___
#лр_туториал