t
сначала пишешь как попало, потом рефакторишь
Size: a a a
2020 June 25
S🕶
потом программа станет больше - будет легче орентироваться, кто знает кто насрет туда
SI
в классе User нет смысла, от заачи зависит
если класс не является моделью.
S🕶
в entity ясное дело что будет просто id
P
смотрю я .net core проект и вижу что часто вот так пишут:
userRepository.findAsync(x => x.id == ....)мне вот интересно, почему называют все x, почему не назвать user?, это ведь в понятней для человека, никогда так просто не делал и в java писал бы "user", хочу понять просто от куда ноги ростут.
И да, назови как хочешь, все равно будет понятно что там будут элементы из userRepository
S🕶
в общем, я считаю что вещи должны называться своими именами,
если передаешь переменную в сервис - то называть ее userId,
если передаешь полностью весь user, то ясное дело что ничего конвертировать и переименовывать ненадо, ну блин бейсик
если передаешь переменную в сервис - то называть ее userId,
если передаешь полностью весь user, то ясное дело что ничего конвертировать и переименовывать ненадо, ну блин бейсик
DK
ну это все хорошо когда у тебя userid
S🕶
окай, пусть даже так - но почему-то вот такой подход я вижу только в C#
DK
а когда у тебя ApplicationExternalServiceUserDataModelQueryId
DK
уже не очень да?
S🕶
значит что-то не так делаете
S🕶
что за имя такое, 🧐
DK
но в целом нейминг это дело команды, как и в целом кодстайл
DK
значит что-то не так делаете
ну если у тебя сущность так называется, что можно не так делать?
λР
А где бот?
DK
А где бот?
у тебя пропуск
SI
а когда у тебя ApplicationExternalServiceUserDataModelQueryId
СинхронизироватьДанныеСПриложениемВИнтернетеПриЗавершенииРаботыПрограммы , извините, не удержался. Такой нейминг в 1С.
S🕶
но в целом нейминг это дело команды, как и в целом кодстайл
мне кажется уже давно пора более мене одинаково весь код писат, а не в каждой компании писать код по разному, у меня нет особо проблем с неймингом, особенно если писать использая подход архитктурный из DDD
V🧀
мне кажется уже давно пора более мене одинаково весь код писат, а не в каждой компании писать код по разному, у меня нет особо проблем с неймингом, особенно если писать использая подход архитктурный из DDD
поздрввляю, вы изобрели PEP
S🕶
программист поймет чужой код сразу, если они оба разбираются в DDD,
мыслить будут одинаково
мыслить будут одинаково