Код поведения Contributor Covenant

Данный код поведения основан на полном Коде поведения Contributor Covenant.

Разработочные руководства

• Напишите код с сердцем. Целитесь на чистый, упрощённый и крайне элегантный код. Поддерживайте концепции из «Refactoring: Improving the Design of Existing Code» и «Clean Code: A Handbook of Agile Software Craftsmanship».
• Будьте знакомы с уже существующими кодами, чтобы поддерживать последовательность стиля и использования.
• Высоко переиспользуемые компоненты, отсутствие дублирования кода или конфигураций.
• Временно удаляйте ненужные коды.

Код поведения Contributor Covenant при отправке вклада

• Убедитесь, что процесс сборки Maven проходит успешно. Запустите команду mvn -T 1C clean install или ./mvnw -T 1C clean install в командной строке для запуска процесса сборки Maven. Для выбора директории для запуска сборки Maven есть два варианта: 1) если вы не знакомы с Apache ShardingSphere, то можно запустить его на корневой директории проекта, 2) если вы знаете, какие модули будут затронуты изменениями, то можно запустить сборку на этих модулях, чтобы сэкономить время сборки.
• Убедитесь, что процент покрытия тестами не ниже, чем в основной ветке.
• Тщательно рассмотрите каждый запрос на слияние (pull request). Приветствуются маленькие и частые запросы на слияние с полностью работоспособными единичными тестами.
• Соответствуйте данному ниже коду поведения Contributor Covenant.
• Если используете IntelliJ IDEA, вы можете импортировать рекомендованную конфигурацию src/resources/code-style-idea.xml.

Код поведения Contributor Covenant

• Используйте разделители строк Linux.
• Поддерживайте отступы (включая пустые строки) согласно предыдущему коду.
• Оставляйте одну пустую строку после определения класса.
• Исключите бессмысленные пустые строки. Если метод слишком длинный или содержит различные логические фрагменты кода, извлеките приватные методы вместо пустых строк.
• Используйте осмысленные имена классов, методов и переменных, избегайте сокращений.
• Имена значений возврата должны начинаться с result; переменные в цикле должны называться each; замените each на entry в картах.
• Исключения при перехвате должны называться ex; исключения, которые игнорируются, должны называться ignored.
• Имена файлов свойств должны использовать Spinal Case (вариация Snake Case, которая использует дефисы - для разделения слов).
• Разделите код, который требует заметок, на маленькие методы, объясняющие эти методы.
• В условных выражениях = и equals постоянные значения должны находиться слева, а переменные — справа; в условиях > и < переменные должны находиться слева, а постоянные значения — справа.
• Избегайте использования ключевого слова this в операторах присваивания, кроме случаев использования одинаковых имен входных параметров и глобальных полей.
• Проектируйте классы как final классы, за исключением абстрактных классов для расширения.
• Создайте новый метод для вложенных циклов.
• Следуйте последовательности определения членов классов и методов.
• Приоритет следует отдавать использованию защитных условий.
• Минимизируйте доступные права доступа для классов и методов.
• Приватные методы должны располагаться сразу после метода, где они используются; несколько приватных методов должны располагаться в том же порядке, что и оригинальные методы.
• Отсутствие параметров или значений возврата типа null.
• Приоритет следует отдавать использованию тернарного оператора вместо конструкции if-else-return и оператора присваивания.
• Приоритет следует отдавать использованию Lombok вместо конструкторов, геттеров, сеттеров и логических переменных.
• Приоритет следует отдавать использованию LinkedList. Используйте ArrayList только для получения элемента по индексу.
• При использовании коллекций на основе емкости, таких как ArrayList, HashMap, указывайте начальную емкость для избежания пересчета емкости.
• Используйте английский язык во всех логах и javadoc.
• Включайте Javadoc, todo и fixme только в комментариях.
• Только public классы и методы требуют Javadoc, остальные методы, классы и переопределенные методы не требуют Javadoc.
• Запрещено использование вложенного оператора условия ( ? : ).

Код поведения Contributor Covenant при выполнении юнит-тестов- Коды тестов и производственные коды должны следовать одному типу кода поведения.

• Юнит-тесты должны следовать принципу AIR (Автоматический, Независимый, Повторяемый).
  • Автоматический: Юнит-тесты должны выполняться автоматически, а не интерактивно. Проверка результатов теста должна осуществляться с помощью утверждений, а выводы System.out и логи запрещены.
  • Независимый: Зависимости между тестовыми случаями и последовательности вызова запрещены. Каждый тестовый случай должен выполнять свою задачу независимо.
  • Повторяемый: Тестовые случаи должны быть независимы от внешней среды и могут повторяться.
• Юнит-тесты должны следовать принципу дизайна BCDE (Граница, Верный, Дизайн, Ошибка).
  • Граница: Тестирование границ значений, тестирование границ циклов, специальных значений и последовательностей значений для получения ожидаемого результата.
  • Верный: Тестирование верных значений для получения ожидаемого результата.
  • Дизайн: Проектирование вместе с производственным кодом.
  • Ошибка: Тестирование ошибочных входных данных, исключений для получения ожидаемого результата.
• Без особой причины, тестовые случаи должны быть полностью покрыты.
• Каждому тестовому случаю требуется точное утверждение.
• Код подготовки окружения должен быть отделен от кода тестов.
• Статическое импорт может использоваться только для Mockito, junit Assert, hamcrest CoreMatchers и MatcherAssert.
• Для одноаргументных утверждений следует использовать assertTrue, assertFalse, assertNull и assertNotNull.
• Для многоаргументных утверждений следует использовать assertThat.
• Для точных утверждений следует избегать использования not, containsString.
• Реальные значения тестовых случаев должны называться actualXXX, ожидаемые значения — expectedXXX.
• Классы тестовых случаев и аннотация @Test не требуют Javadoc.

Код поведения Contributor Covenant G4

Общий код поведения

• Каждая строка не должна превышать 200 символов, гарантируйте семантическое завершение каждой строки.

Лексический код поведения

• Каждое правило должно быть расположено в одной строке, между правилами не должно быть пустых строк.
• Имена правил лексера должны быть записаны с заглавной буквы. Если имя состоит более чем из одного слова, используйте _ для разделения. Имена правил DataType и Symbol должны заканчиваться _. Если имя правила конфликтует с ключевым словом ANTLR, следует добавить _ в конце имени правила.
• Для приватных правил лексера следует использовать fragment, правила с fragment должны быть определены после общих правил, которым они служат.
• Общие правила лексера следует помещать в файл Keyword.g4, каждая база данных может иметь свои собственные настраиваемые файлы правил. Например: MySQLKeyword.g4.

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

• После завершения каждого правила следует одна пустая строка без отступов.
• Не должно быть пробела перед определением имени правила. Между двоеточием и правилом должно быть одно пространство, точка с запятой должна начинаться новой строкой и поддерживать отступы (включая пустые строки) согласно предыдущему коду.
• Если ветви правила превышают 5, каждая ветвь должна начинаться новой строкой.
• Имена правил парсера должны совпадать с именами переменных Java в стиле CamelCase.
• Определите отдельные файлы для каждого типа SQL, имя файла должно состоять из база данных + тип SQL + Заявление. Например: MySQLDQLStatement.g4.