⛔️ НЕ ОТПРАВЛЯЙ ТАКОЙ КОД НА CODE REVIEW. ЧЕК-ЛИСТ 🍁
Друзья, вы знаете, что я очень часто провожу код-ревью у студентов, новичков и уже давно работающих дата саентистов. Ошибки, как правило, похожи между собой. Поэтому сегодня мы с вами обсудим список моментов, на которые стоит обратить внимание программисту, перед тем как оправить свой код на ревью проверяющему. Обязательно дополняйте его в комментариях!
🟥 Обращаем внимание на имена файлов:
⁃ Название должно быть понятным
⁃ Не стоит использовать большие буквы в названии файла
⁃ Название файла не должно быть слишком длинным
⁃ Если вы работаете внутри репозитория, который был создан до вас, ориентируйтесь на его структуру и на «стиль именований» файлов в этом репозитории – делайте по примеру.
🟥Имена переменных, функций и методов (мы уже обсуждали это более подробно в отдельном посте, укажем основные пункты):
⁃ Имена переменных должны быть понятны всем. И вашему ревьюеру, и вам, открывшему файл с кодом спустя три месяца 🤓
⁃ Не используйте «очевидные слова» в названии переменных (тоже самое касается функций и методов). 🔹Плохой пример: get_list_features_names() -> Хороший: get_features_names(), когда вы определяете функцию, вы указываете, что она отдает на выходе, повторять, что в данном примере функция вернет лист в названии не стоит. 🔹Пусть вы указываете в конфигурационном файле таблицу, куда будут сохраняться данные после отработки модели. Плохое название: table_result_boosting_model, хорошее название: result_boosting_model. Опять же, очевидно, что данные запишутся в какую-либо таблицу, не дублируем это в названии.
⁃ Следите за названиями переменных с точки зрения английского языка. Например, если вы храните уже обученные модели, то пусть структура называется fitted_models (модели, которые УЖЕ были обучены), вместо fitting_models
✅ CHECK YOURSELF:
⁃ Проверьте, все ли переменные, таблицы, файлы, которые определили или импортировали вы используете в коде?
⁃ Ваш код должен быть эффективным. Новичку написание эффективного кода, конечно же, дается трудно. И если вы пока в этом теряетесь, сильно переживать не стоит – более опытные специалисты вам обязательно подскажут. Однако, не забываем базовые вещи, например, что операция проверки “принадлежит ли объект множеству” происходит значительно быстрее аналогичных операций в других структурах данных😎
⁃ Держите в голове разные развития событий, которые могут произойти в результате работы вашей программы. Например, на вход из конфигурационного файла могут быть переданы некорректные данные
⁃ Создавайте несколько файлов с кодом, чтобы внутри них можно было легко ориентироваться. Например, файл с моделями отдельно, файл с обработкой данных отдельно, стратегия программы со всеми необходимыми методами отдельно
⁃ Don’t repeat yourself. Помним про наследование. Создавайте базовый класс и наследуйте другие похожие классы от него, пользуйтесь функциями
⁃ Старайтесь писать максимально универсальный код, который в дальнейшем можно будет легко пере использовать, сильно не меняя код программы
⁃ Избегайте сложных однострочных конструкций. Помните, что главная цель любого программиста - написать как можно более простой для понимания код
⁃ Комментарии к коду. Если вы считаете, что программа сложна для понимания, оставляйте комментарии. Однако увлекаться ими сильно не стоит.
Друзья, вы знаете, что я очень часто провожу код-ревью у студентов, новичков и уже давно работающих дата саентистов. Ошибки, как правило, похожи между собой. Поэтому сегодня мы с вами обсудим список моментов, на которые стоит обратить внимание программисту, перед тем как оправить свой код на ревью проверяющему. Обязательно дополняйте его в комментариях!
🟥 Обращаем внимание на имена файлов:
⁃ Название должно быть понятным
⁃ Не стоит использовать большие буквы в названии файла
⁃ Название файла не должно быть слишком длинным
⁃ Если вы работаете внутри репозитория, который был создан до вас, ориентируйтесь на его структуру и на «стиль именований» файлов в этом репозитории – делайте по примеру.
🟥Имена переменных, функций и методов (мы уже обсуждали это более подробно в отдельном посте, укажем основные пункты):
⁃ Имена переменных должны быть понятны всем. И вашему ревьюеру, и вам, открывшему файл с кодом спустя три месяца 🤓
⁃ Не используйте «очевидные слова» в названии переменных (тоже самое касается функций и методов). 🔹Плохой пример: get_list_features_names() -> Хороший: get_features_names(), когда вы определяете функцию, вы указываете, что она отдает на выходе, повторять, что в данном примере функция вернет лист в названии не стоит. 🔹Пусть вы указываете в конфигурационном файле таблицу, куда будут сохраняться данные после отработки модели. Плохое название: table_result_boosting_model, хорошее название: result_boosting_model. Опять же, очевидно, что данные запишутся в какую-либо таблицу, не дублируем это в названии.
⁃ Следите за названиями переменных с точки зрения английского языка. Например, если вы храните уже обученные модели, то пусть структура называется fitted_models (модели, которые УЖЕ были обучены), вместо fitting_models
✅ CHECK YOURSELF:
⁃ Проверьте, все ли переменные, таблицы, файлы, которые определили или импортировали вы используете в коде?
⁃ Ваш код должен быть эффективным. Новичку написание эффективного кода, конечно же, дается трудно. И если вы пока в этом теряетесь, сильно переживать не стоит – более опытные специалисты вам обязательно подскажут. Однако, не забываем базовые вещи, например, что операция проверки “принадлежит ли объект множеству” происходит значительно быстрее аналогичных операций в других структурах данных😎
⁃ Держите в голове разные развития событий, которые могут произойти в результате работы вашей программы. Например, на вход из конфигурационного файла могут быть переданы некорректные данные
⁃ Создавайте несколько файлов с кодом, чтобы внутри них можно было легко ориентироваться. Например, файл с моделями отдельно, файл с обработкой данных отдельно, стратегия программы со всеми необходимыми методами отдельно
⁃ Don’t repeat yourself. Помним про наследование. Создавайте базовый класс и наследуйте другие похожие классы от него, пользуйтесь функциями
⁃ Старайтесь писать максимально универсальный код, который в дальнейшем можно будет легко пере использовать, сильно не меняя код программы
⁃ Избегайте сложных однострочных конструкций. Помните, что главная цель любого программиста - написать как можно более простой для понимания код
⁃ Комментарии к коду. Если вы считаете, что программа сложна для понимания, оставляйте комментарии. Однако увлекаться ими сильно не стоит.