3 hours later…
8:03 AM
public void GetCommentSection(Repository repository, int AuthorId, int CommentId, int needSubComment){ var comment = _repository.Select(commentId, commentType, attributes, false); var subComment = _service.GetModel(comment.Attributes["subComment"], "ru") as Dictionary<string, object>; var DateTime = new Storage.Dal.Common.DateTime {Ticks = DateTime.Now.ToUniversalTime().Ticks} }
public void GetCommentSection(Repository repository, int AuthorId, int CommentId, int needSubComment) { var comment = _repository.Select(commentId, commentType, attributes, false); var subComment = _service.GetModel(comment.Attributes["subComment"], "ru") as Dictionary<string, object>; var DateTime = new Storage.Dal.Common.DateTime { Ticks = DateTime.Now.ToUniversalTime().Ticks } } public void GetCommentSection( Repository repository, int AuthorId, int CommentId, int needSubComment) { var comment = _repository.Select(
@AlexKrass я пишу примерно как во втором, но иду еще дальше, в заголовке метода можно каждый параметр разместить на новой строке, в инициализаторе фигурные скобки размещаю каждую на новой строке, каждый инициализируемый член тоже, в примере с
as
скорее всего сделал несколько переменных, в первую сохранил вызов GetModel, а во вторую результат каста, такой висящий as
мне как-то не нравится
8:42 AM
@АндрейNOP, примерно так же, если заголовок функции длинный, то параметры идут на новых строках по отдельности. Тоже самое с вызовом этих функций, переданные параметры тоже уходят на новые строки каждый, если это помогает читабельности.
3 hours later…
11:23 AM
@AlexKrass Тоже пишу примерно как во втором, но надо сказать, что приведённый фрагмент кода не показателен.
Во-первых, репозиторий - явная зависимость, поэтому не должен быть параметром метода, а должен приходить на конструктор. Оп, у нас минус один параметр, в строку легче уместить.
А потом мы замечаем, что нам нет нужны описывать набор int'ов как параметры запроса, а мы можем описать класс Request и передать ВСЕГО ОДИН параметр вместо -цати параметров и оп! - у нас совсем просторно стало в параметрах.
Я лично очень уважаю 80 символов по ширине, но пользуюсь более современнными стандартами, т.к. на современных мониторах влезает гораздо больше
Мне например сложно понять программистов, которые по 8 часов в день смотрят в плохой монитор с маленькой диагональю и не берегут глаза. (У меня лично минус семь диоптрий уже на первом курсе было)
Любой кто возьмёт ходовой монитор 21 дюйм не найдёт мелких разрешений, поэтому может взять visual studio, сделать чуть пошире окно Solution Explorer'а и увеличить дефолтный шрифт на 3-4 щелчка колеса мыши - и всё равно будет больше чем 80 символов
Я когда-то ставил в настройках решарпера и по триста, чтобы гарантированной никакие форматтеры не мешали мне писать как я хочу
Потом как-то понял, что смысловые единицы длиной в триста символов на строку - нонсенс и такие длинные строки надо обязательно делить на несколько для большей читаемости
И от любви к слишком длинным методам меня тоже как-то подотпустило, хотя третий монитор до сих повёрнут вертикально, чтобы можно было окинуть взглядом длинный метод - а может как раз отпустило потому что взял третий монитор с поворотным кронштейном
меня долго отучали на ревью от длинных наименований переменных, я обожаю точность формулировок, поэтому для меня лично понятнее звучит 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?
12:30 PM
New record for shortest time between Meta post and fix being developed? Less than 20 minutes :-) — Ryan M 16 hours ago
4 hours later…
4:41 PM
@AK Да, согласен, это немного надуманный пример, хотя визуально используемые конструкции повторены 1 в 1. Мне больше хотелось узнать, испытывают ли люди дискомфорт при работе с длинным кодом и есть ли смысл еще и за этим следить.
Ну и думаю ответ на свой вопрос я получил, раз уже два человека находят это полезным. В разумных пределах разумеется и без фанатизма. А так на проекте и без того куча проблем и вопросов, которые долго описывать и они выбиваются за рамки ответ-вопрос. Если уж говорить о них по существу, то мы тут точно устроим филиал шарпового чатика.
3 hours later…
7:40 PM
[ SmokeDetector | MS ] Mostly punctuation marks in answer (37): Не работает триггер MYSQL by Phil on
ru.stackoverflow.com
« first day (2201 days earlier) ← previous day next day → last day (1125 days later) »