Comments 27
# ----- Обработка чисел -----
Можно просто в отдельную функцию вынести.
import data_base.databases as db
Алиасы нужны для решения конфликта имён и только для этого. Добавление промежуточных имён редко делает код чище. Практики принятые в датасаенсе часто не являются примерам хорошего дизайна.
Мои инструменты это автоматизация. Форматер + линтер + статический анализ задают нижнюю планку качества кода на хорошем уровне. Мой личный шаблон https://github.com/Cjkjvfnby/project_template, давно не обновлялся, но всё еще актуальный.
def save_game(période: int):
Что за перьёд? Товаришь Chat J'ai peté постарался?
Как писать красивый и чистый код питонистам?
А никак, бгггг
Шучу, серьёзный ответ будет: "а так же, как и всем остальным"
И про комментарии в корне не согласен. Если человек не может перевести "save_period", то пусть идёт в дворники. Тот, кто пишет комментарий "период сохранения" тоже пусть в дворники идёт. Комментарий должен быть "Период сохранения в секундах после последнего действия пользователя".
те кто не поймут про какой период сохранения - тоже в дворники
Ну вообще-то это переводится примерно так: "Сохрани период". С именами все очень и очень непросто.
Я в курсе. И назвал бы переменную SaveDelayAfterLastActionSec, ой, простите, тут питоний, значит save_delay_after_last_action_sec
И вообще бы вынес нахер в константы в начало файла. Соответственно, капсом.
Вопрос: а нужен ли мне после этого вообще комментарий?
. Если человек не может перевести "save_period", то пусть идёт в дворники
Переведи, пожалуйста сложный медицинский термин с русского на английский и обратно быстро и однозначно.
Зачем? Медтермины обычно на латыни, пусть в латыни и остаются. Это общепризнанный общемировой формат
Издеваешься
Состояние (шаг) бизнес процесса:
Проведено медицинское обследование после производственной травмы.
Возможно 10 вариантов перевода на английский. А с английского неоднозначности в понимании на русском
Вот тебе в панамку от LLM
1. MedicalExamCompleted
2. PostInjuryAssessmentDone
3. InjuryMedicalReviewCompleted
4. OccupationalExamConducted
5. WorkInjuryDiagnosisDone
6. PostTraumaMedicalEvaluation
7. InjuryAssessmentFinalized
8. MedicalReviewConcluded
9. WorkTraumaEvaluationComplete
10. PostInjuryCheckupFinished
Какой-то один реализован в коде, но ты не знаешь какой. Теперь найди его, зная только русское название, которое и употребляет бизнес, а значит в ТЗ тоже русское
И это я названия заболеваний ещё не приводил
Я не понимаю, почему я издеваюсь.
Есть английский язык как стандарт для айти. Что это вообще за вопрос такой был: переведи медицинский термин туда и обратно? Зачем? Как это связано с темой разговора?
Если у вас есть предметная область и вы пишете исходный код для системы, работающей в ней, у вас УЖЕ ЕСТЬ термины, от которых можно отталкиваться. У вас уже есть медицинское обследование. У вас есть производственная травма. Вам рассказать, как перевести на английский термин "после"?
И, пожалуйста, не надо мне тыкать. Может оказаться, что я старше вас лет на 10.
О. Вспомнил, кто вы такой. Отрицатель ООП. Тогда ладно. Мои аргументы бессильны. Сдаюсь.
Бизнес говорит: нужно сделать выгрузку всех обследований в состоянии "Проведено медицинское обследование после производственной травмы", а таких состояний штук 30. Ладно, если они в явном виде перечислены в каком-то enum с комментариями и в одном месте программы. А если это просто тупой ключ в словаре / хешмэпе?
Ну ладно состояние
А если это поле? И нет карты однозначного соответствия бизнес термина (что я слышу от заказчика) и того что в коде или БД
карты однозначного соответствия бизнес термина
Вообще карты соответствия делают даже англоговорящие разрабы. Просто, чтобы в коде и в обсуждениях с бизнесом термины совпадали.
Но не хотите - не делайте. Кто я такой, чтобы вам указывать, что делать?
Это ваши проблемы будут дальше, когда (или если) вы попадёте в другую компанию, а там будет всё незнакомо. Думаете почему люди стремятся стандартизировать что-то? Вот именно поэтому. Чтобы на одном языке шёл разговор.
Как я уже сказал - международный язык для разработки - английский. Если вы пишете переменные по-русски, то я не имею права вас осуждать. Но осуждаю.
Мои аргументы бессильны. Сдаюсь.
Слабак! )))
В случаи, если вы пытаетесь делить на ноль, чего нельзя делать в математике, то данная функция возвращает значение
None. Это не самый правильный вариант, лучше использоватьraiseи "вызывать" конкретную ошибку
лучше подбирать примеры не настолько странно, ведь всё красиво, по математике верно
...а потом оказывается что это код - кусок парсера какихто данных где у значения b может быть вполне штатный показатель - 0 (нуль), а ф-ция возвращает какуюто расчетную ф-цию относительно него и эта цифра опциональна...по этому она возвращает None и вешать сюда еще и исключение - это будет излишнее усложнение кода
тут вероятно правильным выходом переименовать divide в правильное название или более конкретно рассматривать поставленную задачу вместе с контекстом
Сюда же можно отнести использование PyCharm, потому что иначе смысла от аннотаций нет.
А также использование виртуальных окружений под каждый отдельный проект.
Давайте своим переменным понятные и очередные названия, например, если переменная содержит период сохранения каких-то данных, так и назовите её
save_period, а не как-нибудь
Вам бы сначала в английский, а ещё ранее, в следование тому, что сами советуете...
Есть же замечательное исключение ZeroDivisionError. Зачем всюду пихать ValueError?
У вас с исключениями беда. Вот представьте себе, что вашу библиотеку кто-то вызывает и получает то ValeError, то TypeError, а где вы забыли проверить на 0 - ZeroDivisionError. И при этом ещё летят исключения, которые возникают в местах, где вы допустили ошибку. В этом случае будет проще обернуть вызов вашей фунции в общий Exception, но тогда будет совершенно не ясно: является ли исключение запланированным, или код библиотеки словил баг, а может это вообще клинтский код отработал с ошибкой и всё смешалось в кашу. Поэтому лучше делать хотябы общее исключение, например, MyLibException, и выбрасывать его. А если из вашего кода полетят стандартные исключения, то уже можно принимать меры и писать багрепорты.
Как писать красивый и чистый код питонистам?