Update commit style docs

Co-authored-by: acidicMercury8 <acidicmercury8@outlook.com>

Author: sodat1de

doc/commit-style.md

@@ -8,36 +8,110 @@ Commit style accepted in __IX-Ray__ project
 
 The project accepts commit standard for transparency and comprehension of the changes being made. The acceptable commit style is described below
 
-## Naming
+## General rules
+
+- Commit messages must be written in English.
+- Each commit message should be structured to answer the question: __"If this commit is applied, it will..."__
+- The message must start with a verb in the infinitive form without the `to` particle
+- No flags like `[Fix]`, `[UPDATE]`, or other tags should be included. The verb should directly describe the action performed
+- Commit messages should be brief but descriptive, with additional details added in a long description if needed
+- Capitalize the first letter of the commit message
+- If you are unsure how to write in English, clearly describe what you did in your native language (no gibberish, we will translate and refine it later)
+
+## Commit message structure
 
 ### Initial commits
 
-Initial commit message should be written in the following style:
+Initial commit messages should follow this structure:
 
 ```text
 Initial commit
 ```
 
 ### Regular commits
 
-- Pattern
+Regular commit messages consist of one part, optionally followed by a long description:
+
+```text
+<Commit message body>
+
+<Long description if necessary>
+```
+
+### Length guidelines
+
+- The maximum length for the commit message header is __72 characters__
+- Each line in the long description should also not exceed __72 characters__
+
+## Writing commit messages
+
+### Header format
+
+The commit message header must begin with a verb in the infinitive form that describes the action taken in the commit. Examples:
+
+- `Fix window manager implementation`
+- `Implement audio output support`
+- `Remove obsolete configurations`
+- `Add documentation for API endpoints`
+- `Optimize rendering pipeline`
+
+#### Specific rules for nouns
+
+If the message includes a noun, make sure to structure it naturally for clarity:
+
+- `Implement new devices support (preferred)`
+- `Add new gizmo support (preferred)`
+- `Add support for AMD FSR (less desirable, use the structure above)`
+- `Implement support for new devices (less desirable, rephrase as shown in the examples above)`
+
+It is recommended to place the main noun after any qualifiers when possible for better readability
+
+### Examples of correct messages
+
+#### Single-line messages
+
+- `Fix memory leak in database connector`
+- `Refactor logging system for clarity`
+- `Update README with installation instructions`
+- `Remove deprecated API calls`
+
+#### Messages with long descriptions
+
+```text
+Fix rendering issue in graphics pipeline
+
+The rendering pipeline had a bug causing frame drops on low-end GPUs. This fix optimizes shader execution and resolves the issue.
+```
+
+```text
+Add unit tests for input validation
+
+Unit tests cover edge cases for user input to ensure stability and prevent crashes during unexpected inputs.
+```
+
+## Common mistakes to avoid
+
+- __Using tags or brackets:__
 
-  Regular commit message should consist of one part and be built according to the following template:
+  - Incorrect: `[Fix] Resolve bug in module`
+  - Correct: `Fix bug in module`
 
-  ```test
-  Commit message body
+- __Starting with a non-verb:__
 
-  Long description if necessary
-  ```
+  - Incorrect: `Bugfix for network error`
+  - Correct: `Fix network error`
 
-  Commit message body and description should briefly reflect the meaning of the commit changes
+- __Improper verb placement:__
 
-  Commit message body should be written starting with a capital letter
+  - Incorrect: `Implementing new feature`
+  - Correct: `Implement new feature`
 
-  First word should denote the verb of the action performed by the commit, this word should be in the infinitive form without the `to` particle
+- __Using incomplete sentences:__
 
-  Description should be separated from the body by one empty line
+  - Incorrect: `Fixed bug`
+  - Correct: `Fix UI layout bug`
 
-- Length
+- __Improper noun placement:__
 
-  The maximum length of the commit header or the commit description line is 72 characters
+  - Incorrect: `Add support new layout`
+  - Correct: `Add new layout support`

doc/commit-style.rus.md

@@ -8,7 +8,17 @@
 
 В проекте принят стандарт фиксаций для обеспечения прозрачности и понимания вносимых изменений. Приемлемый стиль фиксаций описан ниже
 
-## Именование
+## Общие Правила
+
+- Сообщения к коммитам должны быть написаны на английском языке
+- Каждое сообщение должно отвечать на вопрос: __"Если этот коммит будет применён, он..."__
+- Сообщение должно начинаться с глагола в инфинитиве без частицы `to`
+- Никаких флагов, таких как `[Fix]`, `[UPDATE]` и т.п., использовать не нужно. Глагол должен чётко описывать выполненное действие
+- Сообщение должно быть кратким, но информативным. При необходимости можно добавить дополнительное описание
+- Первая буква сообщения должна быть заглавной
+- Если вы не уверены, как написать на английском, напишите на своём родном языке, чётко описывая, что вы сделали (избегайте "бреда", мы переведём и доработаем сообщение)
+
+## Структура Сообщений
 
 ### Начальные фиксации
 
@@ -20,24 +30,88 @@ Initial commit
 
 ### Рабочие фиксации
 
-- Шаблон
+Обычное сообщение о фиксации должно состоять из одной части и быть построено в соответствии со следующим шаблоном:
+
+```text
+<Основное сообщение коммита>
+
+<Дополнительное описание, если необходимо>
+```
+
+### Ограничения по длине
+
+- Максимальная длина заголовка сообщения коммита — __72 символа__
+- Каждая строка в дополнительном описании также не должна превышать __72 символа__
+
+## Правила Написания Сообщений
+
+### Формат Заголовка
+
+Сообщение коммита должно начинаться с глагола в инфинитиве, описывающего действие, выполненное в коммите. Примеры:
+
+- `Fix window manager implementation`
+- `Implement audio output support`
+- `Remove obsolete configurations`
+- `Add documentation for API endpoints`
+- `Optimize rendering pipeline`
+
+#### Особые правила для существительных
+
+Если сообщение включает существительное, важно правильно разместить его, чтобы фраза звучала естественно:
+
+- `Implement new devices support (предпочтительно)`
+- `Add new gizmo support (предпочтительно)`
+- `Add support for AMD FSR (нежелательно, используйте структуру выше)`
+- `Implement support for new devices (нежелательно, переформулируйте как в примерах выше)`
+
+Рекомендуется, чтобы основное существительное шло после уточнений, если это возможно, для лучшей читаемости
+
+### Примеры корректных сообщений
+
+#### Однострочные сообщения
+
+- `Fix memory leak in database connector`
+- `Refactor logging system for clarity`
+- `Update README with installation instructions`
+- `Remove deprecated API calls`
+
+#### Сообщения с дополнительным описанием
+
+```text
+Fix rendering issue in graphics pipeline
+
+The rendering pipeline had a bug causing frame drops on low-end GPUs. This fix optimizes shader execution and resolves the issue.
+```
+
+```text
+Add unit tests for input validation
+
+Unit tests cover edge cases for user input to ensure stability and prevent crashes during unexpected inputs.
+```
+
+## Типичные ошибки
+
+- __Использование тегов или скобок:__
 
-  Обычное сообщение о фиксации должно состоять из одной части и быть построено в соответствии со следующим шаблоном:
+  - Некорректно: `[Fix] Resolve bug in module`
+  - Корректно: `Fix bug in module`
 
-  ```test
-  Тело сообщения фиксации
+- __Начало не с глагола:__
 
-  Длинное описание, если необходимо
-  ```
+  - Некорректно: `Bugfix for network error`
+  - Корректно: `Fix network error`
 
-  Текст сообщения о фиксации и описание должны кратко отражать смысл изменений, внесенных при фиксации
+- __Неправильное использование глаголов:__
 
-  Текст сообщения о фиксации должен начинаться с заглавной буквы
+  - Некорректно: `Implementing new feature`
+  - Корректно: `Implement new feature`
 
-  Первое слово должно обозначать глагол действия, выполняемого коммитом, это слово должно быть в форме инфинитива без частицы `to`
+- __Неполные предложения:__
 
-  Описание должно быть отделено от основного текста одной пустой строкой
+  - Некорректно: `Fixed bug`
+  - Корректно: `Fix UI layout bug`
 
-- Длина
+- __Неверное расположение существительного:__
 
-  Максимальная длина заголовка фиксации или строки описания фиксации составляет 72 символа
+  - Некорректно: `Add support new layout`
+  - Корректно: `Add new layout support`