Понятные названия полей и свойств

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

В случае с булевой переменной, название должно отображать вопрос, ответ на который будет "Да" или "Нет".

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

Понятные названия методов

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

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

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

Единый стиль наименований событий (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 время. При должном количестве практики, вы привыкнете к этому слову и не будете замечать его написание. И будете рады, что пользуетесь им, взглянув на свой код спустя несколько месяцев.

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