Чем именно продукты джетов не угодили? Дотнетчики с R# и раньше писали под .NET Framework, а теперь радостно радостно пересаживаются на Rider. А компании в общем-то без разницы: покупать R# или Rider, разница в цене не велика.
То, что приходит снаружи — это тем более ответственность того кода, который это что-то посылает. А контракт с нашей стороны контролируется типами и явными гуардами.
Но иногда почтовые адреса с цифры и подчеркивания реально должны хендлиться отдельно...
Тому должны быть какие-то рациональные объяснения. Пусть даже это будет называться просто legacyFormat, а не низкоуровневое: «цифры» или «подчеркивания».
А если посложнее: «ищем почтовые адреса в нашем домене, начинающиеся с цифры или подчеркивания»?
Этот коммент как раз отвечает на вопрос: «Каким образом?» (реализация) и совершенно не дает ответа на: «Зачем?».
Здесь должно быть что-то значимое с точки зрения бизнес-логики, вроде: «Поиск адресов региональных подразделений», не расрывая нюансов реализации. А это уже легко выносится в имя переменной/функции.
нафига задаваться такими вопросами читаюему и нафига пишущему код об этом задумываться и подбирать комментарии
Чтобы у читающего не появилось соблазна без нужды лезть в кроличью нору, чтобы убрать костыли, что может потребовать много времени и/или серьезную переработку архитектуры.
Если конкретной реализации еще нет, то какой смысл вы комментируете? Todo-комментарии обычно выпиливают взамен на реализацию, ведь будет дублирование смысла.
// Для дополнительных задач требуется добавлять префикс перед идентификатором, чтобы он не совпадал с каким-либо из id выездов
orderStateDTO.setOrderId(«f_» + additionalTask.getId());
Это авторская терминология.
С единицей на конце или чем-то вроде)
Рабочий стол? Серьезно?)
System.Text.Json
теперь умеет генерировать сериализаторы.legacyFormat
, а не низкоуровневое: «цифры» или «подчеркивания».Конкретный формат — это часть реализации, равно как и механизм его поиска.
А в чем проблема? Похоже на параметры.
Здесь должно быть что-то значимое с точки зрения бизнес-логики, вроде: «Поиск адресов региональных подразделений», не расрывая нюансов реализации. А это уже легко выносится в имя переменной/функции.
Разве имя функции
parseDateTime
или переменная с регуляркойidentifierFormat
не отвечают на вопрос: «Зачем?»?Чтобы у читающего не появилось соблазна без нужды лезть в кроличью нору, чтобы убрать костыли, что может потребовать много времени и/или серьезную переработку архитектуры.
Будет дублировать смысл, который и без того хорошо читается по коду реализации. В статье это отражено разделом «Избыточные комментарии».