Условности и соглашения
Я уже почти согласился с тем, что исходный код должен быть в каталоге с именем приложения.
Вместе с именем репозитория это приводит вот к таким речекрякам:
/github/foobar/foobar/foobar.py
Rust стоит же на позиции, близкой к C/C++ (точнее, к некоторой части оного) - сырцы - в src. Это же автоматически снимает вяло поднятый вопрос почему в питоне код в именованном каталоге, а тесты - просто в test (tests). Такая модель более логичная - src, tests, etc.
Не то, чтобы это было очень важно, но из таких мелочей инженерная практика и складывается. Какой толщины должна быть линия на чертеже, в каком каталоге должны лежать сырцы.
Основное назначение этих мелочей - упрощение знакомства с чужим кодом совершенно новых людей. Свои и так знают где что смотреть, но когда приходит новый человек, чем меньше ему нужно думать над тривиальными вещами, тем больше он может думать о нетривиальном - то есть читать сам код.
Так что одна из целей хорошего software engineering должна быть в том, чтобы вызывать наименьшее количество недоумения у окружающих. Отсюда всякие стайлгайды кода и паттерны разработки в тривиальных вопросах. Хорошо знакомый с этими условностями человек, открыв хорошо написанный незнакомый ему код, просто пропустит его весь, ухватывая лишь важные детали и изменения. В хорошем коде все такие изменения будут иметь конкретную цель и нести с собой минимум, собственно, отклонений от "идеального, сферического в ваккууме, приложения".
Вместе с именем репозитория это приводит вот к таким речекрякам:
/github/foobar/foobar/foobar.py
Rust стоит же на позиции, близкой к C/C++ (точнее, к некоторой части оного) - сырцы - в src. Это же автоматически снимает вяло поднятый вопрос почему в питоне код в именованном каталоге, а тесты - просто в test (tests). Такая модель более логичная - src, tests, etc.
Не то, чтобы это было очень важно, но из таких мелочей инженерная практика и складывается. Какой толщины должна быть линия на чертеже, в каком каталоге должны лежать сырцы.
Основное назначение этих мелочей - упрощение знакомства с чужим кодом совершенно новых людей. Свои и так знают где что смотреть, но когда приходит новый человек, чем меньше ему нужно думать над тривиальными вещами, тем больше он может думать о нетривиальном - то есть читать сам код.
Так что одна из целей хорошего software engineering должна быть в том, чтобы вызывать наименьшее количество недоумения у окружающих. Отсюда всякие стайлгайды кода и паттерны разработки в тривиальных вопросах. Хорошо знакомый с этими условностями человек, открыв хорошо написанный незнакомый ему код, просто пропустит его весь, ухватывая лишь важные детали и изменения. В хорошем коде все такие изменения будут иметь конкретную цель и нести с собой минимум, собственно, отклонений от "идеального, сферического в ваккууме, приложения".