Pull request(PR) - это запрос стороннего пользователя на внесение изменений в какой-то проект. В нашем случае проект - репозиторий с лабораторными работами. Используются Pull request для контроля над разработкой - только уполномоченные люди могут принимать PR, что означает, что плохой код не будет принят в общий проект.
К тому же, в PR можно при помощи CI делать проверки линтеров(CE и некоторые UB) и форматтеров(код стайл), что и сделано в данном проекте.
Как упоминалось выше, PR могут принять только уполномеченные пользователи. Перед добавлением вашего кода в общий репозиторий, ваши изменения проходят процедуру code review. Это дословно обзор вашего кода, проверка его на состоятельность, логичность и правильную структурность. По ходу code review, можно писать комментарии(issues) к автору кода, например, если используется верно работающий метод, но очень не понятный мне(чёрная магия, иными словами), я могу попросить его объяснить или переписать во благо удобочитаемости кода для остальных разработчиков.
Очевидно. Проверится на этапе PR.
Очевидно. Проверится на этапе PR.
Очевидно. Проверится на этапе PR.
Нельзя писать всё в одном файле - декомпозируйте код на разные сущности
Вопрос чисто опыта, не нужно из этой идеи делать функции по одной строчке. Каждая хорошая функция должна делать только одно логическое действие. Если у вас в функции происходит и транспонирование, и перемножение, и распечатка матрицы - это повод задуматься над рефакторингом (Как раз в этом примере выделили 3 функции). Также полезно думать, что код, который вы пишите, можно будет потом переиспользовать - намного легче будет взять готовую одну функцию, ежели выдёргивать из общего полотна кода кусок с нужной логикой.
Никакой русофобии - он просто плохо отображается почти везде. Используйте переводчик, если плохо знаете английский. Хорошая привычка - писать на английском. С русским у вас проблем нет, а вот практика с английским очень пригодится из-за огромного количества документации на этом языке.
Плохие названия переменных/функций/классов (запрещён транслит) - по названию должно быть понятно, что функция делает
Думаю, очевидно, что это большой шаг на пути к написанию чистого и понятного кода.
Если у вас какой-то стрёмный цикл с очень странными шагами, много булевых флагов, которые то True, то False - это непонятно, это стоит убрать и больше так не делать. Важно сделать не только рабочую программу, но и понятную. Иногда это забирает больше времени, чем написание алгоритма. Полезно думать, что вы пишите код, который будут читать другие разработчики.
Пример:
// Плохо!
for (size_t i = 0; i < 100; ++i)
for (size_t j = 0; j < 15; ++j)
...
// Хорошо!
size_t size_of_DataArray = 100;
size_t size_of_QArray = 15;
for (size_t i = 0; i < size_of_DataArray; ++i)
for (size_t j = 0; j < size_of_QArray; ++j)
...Хороший код не должен содержать комментариев - он должен быть понятным и без них. Но бывают места, где они прям нужны. Если ваш алгоритм или метод решения не очевиден - стоит пояснить его комментариями.
Копия этого репозитория появится у вас в вашем аккаунте - это можно сделать в веб версии, нажав на кнопку fork в верхней части проекта.
Прописать в терминале с установленным git:
git clone https://github.com/YourGitHubLogin/MAI_109B_22.gitПод каждую лабу должна быть своя ветка. Название веток на ваш вкус. Пример создания ветки и переключения на неё:
git checkout -b NameOfBranchНе требуются пояснения - если не помните, как и что - смотрите документацию по git.
Все ваши коммиты отправляем на удалённый репозиторий командой git push:
git pushНажимаем на создать, выбираем какую ветку хотим отправить и пишем описание PR: в нём должна быть указана лаба, которую вы выполнили.