11:23 AM
@AlexKrass Тоже пишу примерно как во втором, но надо сказать, что приведённый фрагмент кода не показателен.
Во-первых, репозиторий - явная зависимость, поэтому не должен быть параметром метода, а должен приходить на конструктор. Оп, у нас минус один параметр, в строку легче уместить.
А потом мы замечаем, что нам нет нужны описывать набор int'ов как параметры запроса, а мы можем описать класс Request и передать ВСЕГО ОДИН параметр вместо -цати параметров и оп! - у нас совсем просторно стало в параметрах.
Я лично очень уважаю 80 символов по ширине, но пользуюсь более современнными стандартами, т.к. на современных мониторах влезает гораздо больше
Мне например сложно понять программистов, которые по 8 часов в день смотрят в плохой монитор с маленькой диагональю и не берегут глаза. (У меня лично минус семь диоптрий уже на первом курсе было)
Любой кто возьмёт ходовой монитор 21 дюйм не найдёт мелких разрешений, поэтому может взять visual studio, сделать чуть пошире окно Solution Explorer'а и увеличить дефолтный шрифт на 3-4 щелчка колеса мыши - и всё равно будет больше чем 80 символов
Мой личный выбор - 100 символов, мне хватает
Я когда-то ставил в настройках решарпера и по триста, чтобы гарантированной никакие форматтеры не мешали мне писать как я хочу
Потом как-то понял, что смысловые единицы длиной в триста символов на строку - нонсенс и такие длинные строки надо обязательно делить на несколько для большей читаемости
И от любви к слишком длинным методам меня тоже как-то подотпустило, хотя третий монитор до сих повёрнут вертикально, чтобы можно было окинуть взглядом длинный метод - а может как раз отпустило потому что взял третий монитор с поворотным кронштейном
меня долго отучали на ревью от длинных наименований переменных, я обожаю точность формулировок, поэтому для меня лично понятнее звучит contactsForCurrentCompany, чем просто contacts
с контактами ещё ладно, а когда у тебя в коде два контракта и один из них взят по рамочному договору а другой взят текущий активный - меня прямо так и тянет указать какой из них где прямо в имени, а не писать contract1 и contract2
и ещё рядом третий контракт, который не бизнесовый (отдела продаж), а сервисный (ну, типа на техническую поддержку)
Также и тут у вас в коде можно поупрощать названия, хоть в целом норм. Пример который вижу - "секция комментариев", это слишком отдаёт визуальным отображением - "секция", "область" и т.п. В коде никто не будет смешивать получение данных и представление данных (слой view). Да и тут судя по коду просто получаются данные, не форматируются, поэтому GetComments вполне достаточно
В строке с датой тоже правильно задуматься, отчего такая длинная строка вышла - вероятно от того, что сразу много действий делается. Например, для unit test'ов лучше всего получение текущего времени выносить в интерфейс, в отдельный провайдер
177
I have some unit tests that expects the 'current time' to be different than DateTime.Now and I don't want to change the computer's time, obviously.
What's the best strategy to achieve this?
поэтому вероятно строка сократится до var dateTime = _timeProvider.GetCurrent();
и - опа! - опять проблемы длинных строк нет
Много в плане понимания "пора переносить на новую строку" даёт linq
return await this.ApplicationDbContext.Contacts
.Include(x => x.ApplicationUser.City)
.Where(predicate)
.OrderBy(orderBy)
.AsNoTracking()
.ToListAsync();
И работа с fluent builder'ами
(устроили тут филиал шарпового чатика, грунди на нас нету)
