<commit_before>﻿## Требования к pull-request

Все требования будут направлены на удобство проведения review, поэтому попробуем открыть новую методологию разработки:
# Review Driven Development (RDD) #

Качественный код - поддерживаемый (модифицируемый) код. Для этого он должен быть понятен еще кому нибудь кроме автора.
Одна из важных целей при проектировании кода - сделать код понятный ревьюверу.
## Правила понятности pull-request ## 
- В описании запроса дожно быть описание и обоснование предложенных изменений.
- В описании запроса должна быть ссылка на Issue. Если вы нашли новый баг или придумали новый функционал, то следует завести новое issue. 
- Каждый коммит в запросе должен содержать коментарий с описанием правки.
- Финальный коммит запроса: 
  - Должен компилироваться.
  - Должен запускаться.
  - Не должен содержать проваленных или игнорируемых тестов.
  - Не должен содержать TODO комментариев.
- Правка по изменению форматирования кода должна быть отделена в отдельный коммит с соответствующим комментарием.
- Правка с изменением функционала, не должна содержать изменений в форматировании кода.
- Каждую строку diff надо быть готовым обосновать. Не можешь этого сделать - выкинь ее из запроса.
- Codestyle священен. Код в проекте может крив, но код в запросе обязан ему соответсвовать. (следовательно, принимаются запросы состоящие только с правками Codestyle) 

** Чтобы код прошел review он должен думать как reviewer, он должен быть им. **

## Дополнительно по этому проекту ##
- Править можно все файлы проекта включая требования.
- Требования по форматированию кода используются с [RSDN](http://rsdn.ru/article/mag/200401/codestyle.XML)




<commit_msg>правки в требованиях к pull-request<commit_after># Требования к pull-request


Качественный код - поддерживаемый (модифицируемый) код. Для этого он должен быть понятен еще кому нибудь кроме автора.

## Правила понятности pull-request
- В описании запроса дожно быть описание и обоснование предложенных изменений.
- В описании запроса должна быть ссылка на Issue. Если вы нашли новый баг или придумали новый функционал, то следует завести новое issue. 
- Каждый коммит в запросе должен содержать коментарий с описанием правки.
- Финальный коммит запроса: 
  - Должен компилироваться.
  - Должен запускаться.
  - Не должен содержать проваленных или игнорируемых тестов.
  - Не должен содержать TODO комментариев.
- Правка по изменению форматирования кода должна быть отделена в отдельный коммит с соответствующим комментарием.
- Правка с изменением функционала, не должна содержать изменений в форматировании кода.
- Каждую строку diff надо быть готовым обосновать. Не можешь этого сделать - выкинь ее из запроса.
- Codestyle священен. Код в проекте может крив, но код в запросе обязан ему соответсвовать. (следовательно, принимаются запросы состоящие только с правками Codestyle) 

## Дополнительно по этому проекту
- Править можно все файлы проекта включая требования.
- Требования по форматированию кода используются с [RSDN](http://rsdn.ru/article/mag/200401/codestyle.XML)
- перед отправкой запроса:
  - проверьте каждый commit, просмотрите diff-ы, проверьте соответствие описания.
  - запустите проект.
  - запустите тесты.
  - оцените удобство просмотра кода.
- всегда можно пересобрать историю коммитов в запросе с помощью rebase (также полезен ключ interactive)




{'fraction_non_alphanumeric': 0.049806143751864006, 'fraction_numerical': 0.003578884580972264, 'mean_word_length': 4.552980132450331, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 1, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6764345', 'n_tokens_mistral': 1299, 'n_tokens_neox': 1560, 'n_words': 407}