🐙Coding Standard

Naming Conventions

Ориентироваться стоит на правила, указанные в руководстве по стилю.

Если там нет ответа на вопрос, то ориентироваться стоит на следующие проекты по убыванию приоритета:

1. Cropout Sample Project

2. Lyra Sample Game

Правила написания кода

1. Использовать ClangFormat

2. Использовать модули (сделать правильный выбор между PublicDependencyModuleNames или PrivateDependencyModuleNames для добавления зависимости)

3. Весь код должен быть протестирован

Обработка ошибок

1. Макрос check используется только для критических условий, без выполнения которых дальнейшее продолжение игры бессмысленно

2. В большинстве случаев для проверки корректности входных данных используется if и ensure

3. Получив ошибку, начинать надо с написания теста, выявляющего эту ошибку

Порядок данных в заголовочном файле

1. Copyright

2. #pragma once

3. #include по алфавиту файлов движка

4. #include по алфавиту файлов проекта

5. #include FileName.generated.h, если необходим

6. Forward declaration по алфавиту типов движка (сначала структуры, потом интерфейсы и потом классы)

7. Forward declaration по алфавиту типов проекта (сначала структуры, потом интерфейсы и потом классы)

8. Делегаты

9. Перечисления

10. Структуры

11. Объявление класса

Порядок переменных и функций в заголовочном файле

Сначала указываются все сущности public, затем protected и в конце private:

1. Переменные с макросом UPROPERTY

2. Статические константы

3. Статические переменные

4. Обычные переменные

5. Делегаты

6. Конструкторы

7. Функции с макросом UFUNCTION()

8. Статические функции

9. Виртуальные функции (set-функции располагаются выше, чем get-функции)

10. Обычные функции (set-функции располагаются выше, чем get-функции)

Порядок данных в файле реализации

1. Copyright

2. #include заголовочного файла

3. #include по алфавиту файлов движка

4. #include по алфавиту файлов проекта

5. Функции в соответствующем порядке

Порядок функций в файле реализации

Порядок берётся изначально из заголовочного файла (соответственно, в начале файла всегда идут конструкторы), но он изменяется в случае вызова одних функций из других. Например, если функция A() вызывает функцию B(), которая ещё не была реализована, то сразу после функции A() реализуется функция B(), и если внутри неё вызывается функция C(), то следующей реализуется функция C().

Когда все эти функции определены, берётся следующая нереализованная функция из заголовочного файла после функции A().

Правило обращения к переменным класса

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

Checklist для перечислений

• Название перечисления - существительное в единственном числе (например, EPRJGameState, а не EPRJGameStates)

• Для первого элемента значение равно 0

Checklist для классов

• Класс не наследуется от другого класса

• Класс имеет основную цель

• Имя класса описывает основную цель

• Имя класса содержит специфичный для проекта префикс

• Класс имеет согласованную абстракцию

• Интерфейс класса ясно описывает его использование

• Интерфейс класса абстрактен настолько, что он может рассматриваться как "чёрный ящик"

• Класс разделён на необходимые компоненты (при необходимости)

• Члены класса сделаны минимально доступными

• Члены класса не имеют общих аффиксов

• Класс избегает предположений о своих клиентах, включая свои производные классы

• Класс не содержит компонентов, которые не используются в коде (например, какой-нибудь StaticMeshComponent, нужный только в Blueprint)

• Соблюдается правило IWYU (Include-What-You-Use)

Checklist для методов

• Все части метода, которые целесообразно поместить в отдельные методы, сделаны отдельными методами

• Имя метода имеет вид "выразительный глагол + объект", либо описывает возвращаемое значение

• Имя метода не имеет избыточный контекст (например, если класс называется Character, то называть функцию GetCharacterName() в большинстве случаев бессмысленно, а лучше назвать её просто GetName())

• Обработчик события имеет префикс On

• Если метод возвращает boolean, то имя функции должно содержать вопрос (Is, Has, Can, Was, Should)

• Метод решает только одну задачу, причём делает это хорошо

• Порядок параметров метода соответствует порядку параметров аналогичных методов

• Параметр имеет префикс Out, если параметр служит для записи в него значения

• В методе делаются проверки на некорректные входные данные

• Все указатели проверены на nullptr перед использованием

• Метод имеет не более 10-ти (лучше 5-ти) точек принятия решений (счёт начинается с 1, дальше прибавляется ещё 1 на каждом вхождении if, while, for, and, or)

• В lambda-выражениях не используется режим захвата по умолчанию

• Метод не имеет наблюдаемых побочных действий

• Максимальный уровень отступов не превышает двух

• Метод либо что-то делает, либо отвечает на вопрос, но не одновременно

• Метод соблюдает закон Деметры

• Метод содержит не более пяти строк кода, не считая { и }

• Метод вызывает методы в объекте, либо передаёт этот объект в виде аргумента, но не то и другое одновременно

• Метод не содержит пустых строк

Checklist для переменных

• Имя переменной полно и точно описывает свою сущность

• Спецификаторы (Total, Sum, Average, Max, Min, Count) находятся в конце имени (например, ItemCount, а не CountItems (в первом варианте, ещё и "s" не нужна))

• Имя переменной не содержит цифр

• Если переменная - boolean, то она имеет префикс b

• Если переменная - boolean, то она не содержит в имени глагола

• Имя переменной не имеет избыточный контекст (например, если класс называется Character, то называть переменную CharacterName в большинстве случаев бессмысленно, а лучше назвать её просто Name)

• Имя переменной не включает имя атомарного типа

• Имя переменной включает имя неатомарного типа

• Время жизни переменной сокращено до минимума

• Переменная инициализирована сразу, либо, хотя бы, перед первым использованием

• Если переменная - указатель, то перед использованием она проверяется

• Если переменная - указатель, то используется интеллектуальный указатель

• Указан диапазон допустимых значений и единица измерений в UPROPERTY, если эта переменная применяется для настройки в Blueprint

• Указана категория в UPROPERTY, если эта переменная применяется для настройки в Blueprint

Checklist по числам

• Код не содержит магические числа

• Все ошибки деления на ноль предупреждены

• Проблемы целочисленного переполнения в выражениях предупреждены

• Прямая проверка на равенство (через ==) чисел с плавающей запятой отсутствует

• Все индексы массивов проверяются перед использованием

Checklist по условным операторам

• "Ненормальный" вариант обрабатывается отдельно, после чего идёт return

• В последовательности if-else-if вначале идут наиболее вероятные сценарии

• Условие if простое для понимания (при необходимости можно создать отдельную функцию с хорошим названием)

• Условный оператор использует {} даже для одного оператора внутри, за исключением return

• Блок else (или switch) может использоваться только на границе программы

• Инструкция if, если она есть, идёт только в начале метода

Checklist по тестированию

• Каждый метод каждого класса протестирован (хотя бы косвенно)

• Каждая строка кода протестирована

• Протестированы граничные условия

• Код протестирован на неверные входные данные

• Тестовый код такой же чистый, как и код продукта

• Тестовый код делится на 3 части: построение тестовых данных, выполнение операций, проверка результатов

• В тесте проверяется только одна концепция

• ExpectedValue должен быть справа

Checklist по виджетам

• Имя корневого элемента имеет вид RootТипЭлемента (например, RootCanvas).