1 В избранное 0 Ответвления 0

OSCHINA-MIRROR/TheAlgorithms-C-Plus-Plus

Присоединиться к Gitlife
Откройте для себя и примите участие в публичных проектах с открытым исходным кодом с участием более 10 миллионов разработчиков. Приватные репозитории также полностью бесплатны :)
Присоединиться бесплатно
Клонировать/Скачать
CONTRIBUTING.md 16 КБ
Копировать Редактировать Web IDE Исходные данные Просмотреть построчно История
gitlife-traslator Отправлено 28.11.2024 01:00 23b4ea9

Руководство по внесению вклада

Перед внесением вклада

Добро пожаловать в TheAlgorithms/C-Plus-Plus! Прежде чем отправлять запросы на включение, пожалуйста, убедитесь, что вы прочитали все руководство. Если у вас есть какие-либо сомнения относительно этого руководства по вкладу, пожалуйста, откройте проблему или задайте вопрос на нашем Discord сервере, и чётко сформулируйте свои опасения.

Вклад

Сопровождающий/рецензент

Пожалуйста, проверьте файл кода рецензента для сопровождающих и рецензентов.

Участник

Будучи участником The Algorithms, мы просим вас следовать пунктам, упомянутым ниже:

  • Вы выполнили свою работу самостоятельно.
    • Плагиат не допускается. Любая работа, содержащая плагиат, не будет объединена.
  • Ваша работа будет распространяться под лицензией MIT, как только ваш запрос на включение будет объединён.
  • Пожалуйста, следуйте правилам и стандартам репозитория, упомянутым ниже.

Новая реализация Новые реализации приветствуются!

Вы можете добавить новые алгоритмы или структуры данных, которые отсутствуют в репозитории, или которые могут улучшить старые реализации (документацию, улучшение тестовых случаев, устранение ошибок или в любом другом разумном смысле).

Проблемы Пожалуйста, избегайте открытия проблем с просьбой «назначить» их конкретному алгоритму. Это просто создаёт ненужный шум для сопровождающих. Вместо этого, пожалуйста, отправьте свою реализацию в запросе на включение, и она будет оценена сопровождающими проекта.

Внесение изменений

Код

  • Пожалуйста, используйте структуру каталогов репозитория.
  • Убедитесь, что расширения файлов — *.hpp, *.h или *.cpp.
  • Не используйте bits/stdc++.h потому что это специфично для Linux и замедляет процесс компиляции.
  • Организуйте свой код с помощью struct, class и/или namespace ключевых слов.
  • Если реализация алгоритма уже существует, пожалуйста, обратитесь к разделу руководство по именам файлов.
  • Вы можете предложить разумные изменения в существующие алгоритмы.
  • Строго используйте snake_case (разделенные подчеркиванием) в именах файлов.
  • Если вы добавили или изменили код, пожалуйста, перед отправкой убедитесь, что код компилируется.
  • Наши автоматизированные тесты запускают CMake для всех запросов на включение, поэтому, пожалуйста, будьте уверены, что ваш код проходит перед отправкой.
  • Пожалуйста, соблюдайте стандарты Doxygen и документируйте код как можно больше. Это не только облегчает чтение для читателей, но и генерирует правильную информацию на веб-сайте.
  • Будьте последовательны в использовании этих рекомендаций.

Документация

  • Убедитесь, что вы добавляете полезные комментарии в свой код. Не комментируйте очевидные вещи.
  • Пожалуйста, старайтесь не создавать новые каталоги, если это возможно. Попробуйте вписать свою работу в существующую структуру каталогов. Если вы хотите создать новый каталог, то, пожалуйста, проверьте, был ли недавно предложен или создан другой запрос на включение в подобной категории.
  • Если вы модифицировали/добавили документацию, пожалуйста, удостоверьтесь, что ваш язык краток и не содержит грамматических ошибок.
  • Не обновляйте README.md вместе с другими изменениями. Сначала создайте проблему и затем свяжите её со своим запросом на включение, чтобы предложить конкретные изменения, необходимые для README.md.
  • Репозиторий следует стандартам Doxygen и автоматически генерирует веб-сайт репозитория. Пожалуйста, убедитесь, что код документирован в этой структуре. Пример реализации приведен ниже.

Тест

  • Обязательно добавьте примеры и тестовые случаи в свою функцию main().

  • Если вы обнаружите алгоритм или документ без тестов, пожалуйста, не стесняйтесь создать запрос на включение или проблему, описывающую предлагаемые изменения.

  • Пожалуйста, попробуйте добавить один или // можно провести несколько проверок

    // это позволяет пользователю узнать, что тесты пройдены успешно std::cout << "Все тесты успешно пройдены!\n"; }

/**

  • @brief Основная функция
  • @param argc количество аргументов командной строки (игнорируется)
  • @param argv массив аргументов командной строки (игнорируется)
  • @returns 0 при выходе */ int main(int argc, char *argv[]) { test(); // запускаем реализации самотестирования // код здесь return 0; }

Правила именования файлов

  • Используйте слова в нижнем регистре с разделителем «_».
  • Например:
MyNewCppClass.CPP       неверно
my_new_cpp_class.cpp    верно
  • Это будет использоваться для динамического создания каталога файлов и реализации.
  • Проверка имени файла будет выполняться в Docker для обеспечения правильности.
  • Если реализация алгоритма уже существует и ваша версия отличается от реализованной, пожалуйста, используйте инкрементную цифровую цифру в качестве суффикса. Например, если median_search.cpp уже существует в папке search, и вы предоставляете новую реализацию, имя файла должно быть median_search2.cpp. Для третьей реализации — median_search3.cpp, и так далее.

Правила для каталогов

  • Мы рекомендуем добавлять файлы в существующие каталоги, насколько это возможно.
  • Используйте слова в нижнем регистре с разделителем «» (пробелы или «-» не допускаются).
  • Например:
SomeNew Fancy-Category неверно
some_new_fancy_category верно
  • Пути к файлам будут использоваться для динамического создания каталога наших алгоритмов.
  • Проверка пути к файлу будет выполняться на GitHub Actions для обеспечения соответствия.
Интеграция CMake в новый каталог

Если новый каталог необходим на 100%, файл CMakeLists.txt в корневом каталоге должен быть обновлён, а новый файл CMakeLists.txt должен быть создан в новом каталоге.

Пример того, как должен выглядеть ваш новый файл CMakeLists.txt. Обратите внимание, что если требуются какие-либо дополнительные библиотеки/настройки, вы должны включить их в этот файл.

# При необходимости используйте флаг RELATIVE, иначе каждый исходный файл может быть указан
# с полным путём. Флаг RELATIVE упрощает автоматическое извлечение имени исполняемого файла.

file( GLOB APP_SOURCES RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} *.cpp )
foreach( testsourcefile ${APP_SOURCES} )
    string( REPLACE ".cpp" "" testname ${testsourcefile} ) # Тип файла. Пример: `.cpp`
    add_executable( ${testname} ${testsourcefile} )

    set_target_properties(${testname} PROPERTIES LINKER_LANGUAGE CXX)
    if(OpenMP_CXX_FOUND)
        target_link_libraries(${testname} OpenMP::OpenMP_CXX)
    endif()
    install(TARGETS ${testname} DESTINATION "bin/<foldername>") # Имя папки. Не включайте `<>`

endforeach( testsourcefile ${APP_SOURCES} )

Файл CMakeLists.txt в корневом каталоге следует обновить, чтобы включить новый каталог. Включите свой новый каталог после последнего подкаталога. Пример:

...
add_subdirectory(divide_and_conquer)
add_subdirectory(<foldername>)

Рекомендации по фиксации изменений

  • Рекомендуется группировать изменения логически в отдельных фиксациях. Сопровождающие считают, что легче понять изменения, которые логически распределены по нескольким фиксациям. Попробуйте изменить только один или два файла в одном каталоге. Запросы на вытягивание, охватывающие несколько каталогов, часто отклоняются.
git add file_xyz.cpp
git commit -m "your message"

Примеры сообщений фиксации с семантическими префиксами:

fix: ошибка в алгоритме xyz
feat: добавить алгоритм xyx, класс xyz
test: добавить тест для алгоритма xyz
docs: добавить комментарии и пояснения к алгоритму xyz/улучшить рекомендации по внесению вклада
chore: обновить значок Gitpod

Общие префиксы:

  • fix: исправление ошибки;
  • feat: новая функция;
  • docs: изменения в документации;
  • test: исправление существующих тестов или добавление новых;
  • chore: прочие изменения, не соответствующие ни одному из вышеперечисленных.

Запросы на вытягивание

  • Ознакомьтесь с нашим шаблоном запроса на вытягивание pull request template.

Сборка локально

Перед отправкой запроса на вытягивание: Сборка кода локально или с помощью удобного сервиса

Соберите код локально или используя удобный сервис Gitpod Ready-to-Code.

cmake -B build -S .

Статический анализатор кода

Мы используем clang-tidy в качестве статического анализатора кода с конфигурацией в .clang-tidy.

clang-tidy --fix --quiet -p build subfolder/file_to_check.cpp --

Форматирование кода

Для форматирования кода используется clang-format.

Установка (требуется только один раз):

— Mac (с использованием homebrew): brew install clang-format

— Mac (с использованием macports): sudo port install clang-10 +analyzer

— Windows (MSYS2 64-bit): pacman -S mingw-w64-x86_64-clang-tools-extra

— Linux (Debian): sudo apt-get install clang-format-10 clang-tidy-10

Выполнение (все платформы):

clang-format -i -style="file" my_file.cpp

GitHub Actions

Включите GitHub Actions на своём форке репозитория. После включения он будет выполнять clang-tidy и clang-format после каждого нажатия (не коммита).

Нажмите на вкладку «Actions», затем нажмите на большую зелёную кнопку, чтобы включить его.

Результат может создать ещё один коммит, если действия внесли какие-либо изменения от вашего имени. Поэтому лучше подождать и проверить результаты GitHub Actions после каждого нажатия. Если эти действия внесли много изменений, выполните git pull в вашем локальном клоне, чтобы избежать конфликтов слияния.

Самое главное:

Happy coding!

Опубликовать ( 0 )

Вы можете оставить комментарий после Вход в систему

1
https://api.gitlife.ru/oschina-mirror/TheAlgorithms-C-Plus-Plus.git
git@api.gitlife.ru:oschina-mirror/TheAlgorithms-C-Plus-Plus.git
oschina-mirror
TheAlgorithms-C-Plus-Plus
TheAlgorithms-C-Plus-Plus
master