Как стать автором
Обновить
0
0

.NET программист

Отправить сообщение

Это авторская терминология.

С единицей на конце или чем-то вроде)

А еще Windows это Visual Studio
Только про… JetBrains не надо.
Чем именно продукты джетов не угодили? Дотнетчики с R# и раньше писали под .NET Framework, а теперь радостно радостно пересаживаются на Rider. А компании в общем-то без разницы: покупать R# или Rider, разница в цене не велика.
Настольных компьютеров было бы вполне достаточно.
Рабочий стол. “Окна” здесь лидируют на всю катушку.

Рабочий стол? Серьезно?)
Вы буквально описываете разницу между императивной парадигмой и декларативной.
GUI десктопных приложений тоже требует совместимых системных вызовов в ОС. А иксы в никсах вовсе построены на клиент-серверной архитектуре.
То, что приходит снаружи — это тем более ответственность того кода, который это что-то посылает. А контракт с нашей стороны контролируется типами и явными гуардами.
Но иногда почтовые адреса с цифры и подчеркивания реально должны хендлиться отдельно...
Тому должны быть какие-то рациональные объяснения. Пусть даже это будет называться просто legacyFormat, а не низкоуровневое: «цифры» или «подчеркивания».
Где же тут «каким образом»? Мы можем использовать регулярные выраженя, можем написать конечный автомат

Конкретный формат — это часть реализации, равно как и механизм его поиска.

«Поиск адресов отделов рекламаций закрытых региональных подразделений в старом формате» — легко выносится?

А в чем проблема? Похоже на параметры.
А если посложнее: «ищем почтовые адреса в нашем домене, начинающиеся с цифры или подчеркивания»?
Этот коммент как раз отвечает на вопрос: «Каким образом?» (реализация) и совершенно не дает ответа на: «Зачем?».
Здесь должно быть что-то значимое с точки зрения бизнес-логики, вроде: «Поиск адресов региональных подразделений», не расрывая нюансов реализации. А это уже легко выносится в имя переменной/функции.
Ответ на вопрос: «Зачем?» (в смысле: «Почему именно так?») в отрыве от конкретной реализации бесполезен.

Как пример — те же регулярные выражения.
Разве имя функции parseDateTime или переменная с регуляркой identifierFormat не отвечают на вопрос: «Зачем?»?
нафига задаваться такими вопросами читаюему и нафига пишущему код об этом задумываться и подбирать комментарии

Чтобы у читающего не появилось соблазна без нужды лезть в кроличью нору, чтобы убрать костыли, что может потребовать много времени и/или серьезную переработку архитектуры.
Мемас
image

Будет дублировать смысл, который и без того хорошо читается по коду реализации. В статье это отражено разделом «Избыточные комментарии».
Когда сделаете — комментарий начнет копетанить относительно кода, к которому он относится.
Если конкретной реализации еще нет, то какой смысл вы комментируете? Todo-комментарии обычно выпиливают взамен на реализацию, ведь будет дублирование смысла.
Todo-Driven Development
Простые регулярки не нужно комментировать, сложные — вовсе использовать не стоит.
// Для дополнительных задач требуется добавлять префикс перед идентификатором, чтобы он не совпадал с каким-либо из id выездов
orderStateDTO.setOrderId(«f_» + additionalTask.getId());
Почему бы не заложить это поведение в сам тип?

Информация

В рейтинге
3 865-й
Зарегистрирован
Активность

Специализация

Software Developer, Fullstack Developer
Senior
C#
Rust