Руководство по внесению вклада
Благодарим вас за то, что вы ознакомились с нашим руководством по внесению вклада! Активное и здоровое сообщество разработчиков — это то, что делает хороший игровой движок исключительным игровым движком. Сосредоточившись на разработке новых функций и исправлении ошибок в каждой версии Lumberyard, мы хотим услышать ваше мнение. Нам интересно узнать, как вы используете движок и какие улучшения вы вносите в свои собственные игровые проекты. Именно поэтому, помимо наших Форумов GameDev, Обучающих материалов и Документации, мы предоставляем вам возможность поделиться своими функциями и улучшениями с другими разработчиками. После того как вы измените основной код движка, просто отправьте запрос на извлечение.
Чтобы вам было легко внести свой вклад в наш игровой движок, команда разработчиков Lumberyard придерживается следующих соглашений о кодировании. Мы считаем, что эти рекомендации поддерживают согласованность кода движка и его простоту для понимания, чтобы вы могли тратить меньше времени на интерпретацию кода и больше времени на программирование. Мы с нетерпением ждём ваших вкладов!
Совместимость компилятора:
Форматирование:
- Lumberyard рекомендует использовать средство форматирования кода Uncrustify для обеспечения соответствия кода C++ коду движка. См. http://uncrustify.sourceforge.net/.
- Применяйте отступы последовательно:
- Файлы должны начинаться без отступов.
- Для каждого вложенного блока кода используйте один дополнительный уровень отступа.
- Все строки блока должны быть выровнены одинаково.
- Делайте строки разумной длины.
- Отступы в препроцессорных инструкциях должны соответствовать отступам в обычном коде.
- Располагайте фигурные скобки так, чтобы они открывались на новой строке и были выровнены с отступом внешнего блока.
- Всегда используйте фигурные скобки для операторов управления потоком.
- Каждая строка кода должна содержать только одно выражение.
- Соглашения об именах для классов, функций, типов и файлов должны соответствовать CamelCase и указывать, что функция делает.
- Во всех заголовочных файлах должна присутствовать директива «#pragma once».
- Используйте предварительные объявления, чтобы минимизировать зависимости заголовочных файлов. Время компиляции является проблемой, поэтому приложите усилия, чтобы уменьшить цепочки включений.
- Синтаксис, который следует использовать при включении заголовочных файлов: #include <Package/SubdirectoryChain/Header.h>. Это правило помогает различать файлы из разных пакетов с одинаковыми именами. <Object.h> может встречаться относительно часто, но <AZRender/Object.h> гораздо менее вероятен.
Классы:
- Вы должны определить конструктор по умолчанию, если ваш класс определяет переменные-члены и не имеет других конструкторов. Если у вас нет конкретной оптимизации, вы должны инициализировать все переменные известным состоянием, даже если состояние переменной недействительно.
- Не предполагайте каких-либо конкретных свойств на основе выбора структуры или класса; всегда используйте <type_traits>, чтобы проверить фактические свойства.
- Общедоступные объявления предшествуют частным объявлениям. Методы должны быть объявлены перед членами данных.
- Все методы, которые не изменяют внутреннее состояние, должны быть константными. Все параметры функции, передаваемые по указателю или ссылке, должны быть помечены как константные, если они не являются выходными параметрами.
- Используйте ключевое слово override везде, где это возможно, и опускайте ключевое слово virtual при использовании override.
- Используйте ключевое слово final там, где его использование оправдано.
Область действия:
- Весь ваш код должен находиться по крайней мере в пространстве имён, названном в честь пакета, и соответствовать указанному ранее соглашению об именовании.
- Поместите объявления переменных функции в максимально узкую область видимости и всегда инициализируйте переменные в их объявлении.
- Статические члены или глобальные переменные, являющиеся конкретными объектами класса, полностью запрещены. Если вам нужен глобальный объект, он должен быть указателем. И он должен быть создан и уничтожен с помощью соответствующих функций.
Комментирование кода:
Чёткая и лаконичная коммуникация важна для того, чтобы код был читаемым для всех. Поскольку комментарии являются основным методом коммуникации, пожалуйста, следуйте этим рекомендациям при комментировании кода:
- Используйте /// для комментариев.
- Используйте /**..*/ для блочных комментариев.
- Используйте @param и т. д. для команд.
- Полные предложения с хорошей грамматикой предпочтительнее сокращённых заметок.
Опубликовать ( 0 )