A
Size: a a a
2020 May 11
VM
можно кодгеном обходиться
VM
описывать только бизнес логику
VM
Короче подход к коду без комментариев это как подход "хорошо написанный код в тестировании не нуждается"
ну зачем комментарии на какой-нибудь метод
(d *Database) StoreUserData()?VM
тесты на него нужны, это критический узел сервиса
а комментарии к чему?
а комментарии к чему?
A
Короче подход к коду без комментариев это как подход "хорошо написанный код в тестировании не нуждается"
+++
а ещё, у меня лично, бывают моменты, что когда пишу комментарий, понимаю, что нужно назвать метод иначе или вовсе он не нужен. не знаю почему. может из-за того, что как-то перевожу всё в осознанный и понятный текст и сразу вижу нюансы...не знаю.
это уже личностное
а ещё, у меня лично, бывают моменты, что когда пишу комментарий, понимаю, что нужно назвать метод иначе или вовсе он не нужен. не знаю почему. может из-за того, что как-то перевожу всё в осознанный и понятный текст и сразу вижу нюансы...не знаю.
это уже личностное
D🦆
+++
а ещё, у меня лично, бывают моменты, что когда пишу комментарий, понимаю, что нужно назвать метод иначе или вовсе он не нужен. не знаю почему. может из-за того, что как-то перевожу всё в осознанный и понятный текст и сразу вижу нюансы...не знаю.
это уже личностное
а ещё, у меня лично, бывают моменты, что когда пишу комментарий, понимаю, что нужно назвать метод иначе или вовсе он не нужен. не знаю почему. может из-за того, что как-то перевожу всё в осознанный и понятный текст и сразу вижу нюансы...не знаю.
это уже личностное
Аналогично, но после переименовывания комментарий уже часто становится не нужен и я его не делаю.
AP
/report
ЕК
ну зачем комментарии на какой-нибудь метод
(d *Database) StoreUserData()?Приходит в команду новичок, видит этот метод и начинает гадать, какие конкретно данные юзера, в какую таблицу, зачем вообще нужен этот метод, когда есть SaveUserData() тут же рядом, и почему этот метод пишет ещё в какую-то левую таблицу, не имеющую отношения к юзеру.
VM
Приходит в команду новичок, видит этот метод и начинает гадать, какие конкретно данные юзера, в какую таблицу, зачем вообще нужен этот метод, когда есть SaveUserData() тут же рядом, и почему этот метод пишет ещё в какую-то левую таблицу, не имеющую отношения к юзеру.
Ну да, ведь по аргументам и структурам непонятно. Приводите в пример реальные ситуации хоть
ЕК
Аргумент у метода в примере выше вообще инстанс базы. И да, по структурам непонятно. Пример с юзером прост, а если там какая-то бизнес-сущность? Она может иметь вполне читаемые имена, но их бизнес-значение всё равно будет непонятным для новичка. Не знаю как у вас, а я постоянно сталкиваюсь с этим, когда прихожу в новый проект с большой кодовой базой.
ЕК
С аргументом в виде базы чёт я поторопился, но в остальном всё в силе
М
Привет. Имеется вопрос некий) Как мне можно проверить список на пустоту?
Делал типа так:
но это тупо и выдавало ошибку, пробывал и ставить туда
Единственное что помогло, это проверить на количество:
может есть какое рациональное решение? Как бы это не дало сбой когда)))
Делал типа так:
if events != []{
...
}но это тупо и выдавало ошибку, пробывал и ставить туда
!= nilи снова паник.
Единственное что помогло, это проверить на количество:
if len(events) > 0{
....
} else {
log.Print("Пусто")
}может есть какое рациональное решение? Как бы это не дало сбой когда)))
zl
проверка на nil не должна вызывать панику
if events != nil {
...
}zl
если там конечно слайс
М
Панику вызывает следующее log.Print(events[0])