4.6 KiB
Code Style Guide to 'RobotFire' Repo
Не является обязательством, но было бы очень приятно🙂 Обращаться к Conventional Commits, к Microsoft C# Coding Conventions.
Coding Rules
Чтобы обеспечить единообразие во всем исходном коде, помните об этих правилах во время работы:
- Все функции или исправления ошибок должны быть протестированы одной или несколькими спецификациями (unit-tests).
- Все публичные методы API должны быть документированы(сопровождаться комментариями).
- Мы следуем Google C# Style Guide, но оберните весь код в 100 characters.
У нас есть очень точные правила относительно того, как могут быть отформатированы наши сообщения коммита git. Это приводит к более читабельным сообщениям, которые легко отслеживать при просмотре истории проекта. Но также, мы используем сообщения коммита git для генерации журнала изменений кода.
Commit Message Format
Иметь сообщение к коммиту не обязательно. Каждое сообщение о коммите состоит из header, body и footer. Заголовок имеет специальный формат, который включает type, scope и subject:
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
Header обязателен, а scope заголовка необязательна.
Любая строка сообщения о коммите не может быть длиннее 100 символов! Это позволяет упростить чтение сообщения на GitHub, а также в различных инструментах git.
Нижний колонтитул должен содержать закрывающую ссылку на проблему если таковая имеется.
docs(changelog): update changelog to beta.5
fix(release): need to depend on latest rxjs and zone.js
The version in our package.json gets copied to the one we publish, and users need the latest of these.
Revert / Отмена
Если коммит отменяет предыдущий коммит, он должен начинаться с revert: , за которым следует заголовок отменяемого коммита. В теле должно быть написано: Это отменяет коммит <hash>., где хэш — это SHA отменяемого коммита.
Type / Тип
Должно быть одно из следующего:
- build: Изменения, влияющие на систему сборки или внешние зависимости(packages, etc).
- ci: Изменения в наших файлах конфигурации CI и скриптах (примеры областей: GitHub Actions, GitLab CI, Jenkins, etc).
- docs: Файлы документации.
- feat: Новая функция или изменения касательно функционала(в том числе геймплей).
- fix: Фиксы багов.
- perf: Изменение кода, повышающее производительность (но не добавляющий новый функционал).
- refactor: Изменение кода, которое не исправляет ошибку и не добавляет функцию.
- style: Изменения, не влияющие на смысл кода (пробелы, форматирование, пропущенные точки с запятой и т. д.).
- test: Добавление отсутствующих тестов или исправление существующих тестов.