Rock Amadeus,

По-моему это лишнее. Подробности реализации обычно редко комментируются, хорошая декомпозиция убирает эту необходимость.

Тебе проще вынести в приватную функцию кусок кода и прокомментировать его со всеми удобствами. Компилятор его если что заинлайнит.

Rock AmadeusТ. е. ты предлагаешь вынести кусок алгоритма в функцию и комментить его через комментарии для функции, вместо того, чтобы прямо внутри кода к каждой строчке добавить коммент? Согласись, звучит как долбаный сишарпный костыль, а не "проще"?

Нет, не соглашусь. Это вообще не имеет отношения конкретно к сишарпу. Это имеет отношение к программированию вообще, практически к любому языку. Большие функцию для того и дробятся на маленькие, чтобы код стал лучше, понятней, и был самодокументрованным.

Пусть и немного утрировано, но смотри:




Уже ничего не надо даже комментировать. А если очень хочется, ты можешь добавить XML DOC комментарий со всеми плюшками.

Rock AmadeusВот в джаваскрипте почему-то решили, что проще для переменной внутри блока кода сделать возможность комментировать.

Потому что в джаваскрипте переменной внутри блока можно присвоить внушительную функцию. И нет такого понятия, как функция класса, которую можно отдельно описать специальной синтаксической конструкцией. Объекты собираются и настраиваются всегда внутри блока. Это необходимость, а не блажь.

Rock AmadeusНу, т. е. пока в сишарп таких возможностей не ввели, да? А то я думал, что плохо искал. В комментах на StackOverflow за 11 год пишут, что нельзя.

Потому что не надо. Потому что необходимость писать комментарии внутри блока это уже попахивает. Всё должно быть разбито на функции. Так Гай Юлий Цезарь сказал. Не я

Roman Mejtes,

XML возможности в комментариях к функциям нужны для генерации документации. Комментарии внутри реализации метода в документацию тащить не имеет смысла, соответственно нафиг не нужны эти заморочки. В общем хотелка из разряда в "масле каши не хватает".

Rock AmadeusТ. е. ничего лучше рефакторинга "переименование" со строковым поиском пока не придумали?

Ну решапер бодро находит все упоминания во всех комментах и предлагает переименовать при рефакторинге. Проблему решает, чего ещё тут можно придумать?

Rock AmadeusТы, кстати, пробовал поработать на современной Студии без Решарпера? Как оно? "Как бер рук", или "есть почти все аналоги"?

Не, я без решарпера не работаю в студии. Да можно без решарпера жить и нормально работать. Но с ним жить намного лучше. Поэтому у меня лицуха на линейку продуктов JetBrains на 3 года вперёд. Я не сторонник ограничивать себя в комфорте ))

Rock AmadeusЯ видел в разных видео обучающих чуваков, которые по быстрым клавишам "летают". Класс создать - хлоп, и заглушка появляется. Метод там, проперти - всё мгновенно.

Много чего нехватает даже при богатых и развитых возможностях студии. Например, поддержка атрибутов [NotNull] / [CanBeNull], вставка проверок на null и генерация исключений, верблюжий язык (быстро находишь класс, интерфейс, расширение или метод по первым большим буквам), генерация имён переменных на лету, автосоздание out переменных, всякие обёртывания/развёртывания, генерация регионов при имплементации интерфейсов и при переопределении методов, генерация конструкторов, дженерик-типов, грамотная декомпозиция, и т.д, и т.п. Студия умеет много, но до решарпера ей очень далеко.

Rock AmadeusЭто точно рутина, которую надо автоматизировать, или уже AI пишет за тебя не только код, но и по мелочи архитектуру?

Растащить метод по нескольким методам или выделить класс, это не архитектура :)

Roman Mejtesдля этого есть Snippet'ы, да комбинаций в коде полно.

Я не спорю, но многих возможностей решарпера либо нет, либо как-то криво воспроизводятся другими расширениями.


Roman Mejtesне так давно отказался от использования решарпера, особенно всё хорошо стало в 2017 версии VS, в Enterprice версии он практически не нужен, так как тупо дублирует половину функционала который уже там есть. + решарпер тормозит очень злостно, без SSD работать становится не комфортно.

Не знаю, у меня ничего не тормозит :) Тем более, что на подходе Rider, построенный на решарпере. Так что удобно, что не надо переучиваться, и юзать новый тул при необходимости.

Rock AmadeusРазогнанный 8-ядерный Core i7 и SSD для ОС и проектов?

Зачем разогнанный? Нет, в обычном режиме Core i7 6700-HQ, вообще тормозов не замечал.
Другое дело, непонятны жалобы на тормоза на слабой машине. Для разработки нужно мощное железо, и дело тут не только в студии и решарпере.

Rock AmadeusТак-то ещё зависит, сколько всего загружено с этой Студией. Может, доп. расширения. Может, проктов несколько десятков в одном солюшене и кодовая база под миллион строк.

В том-то и дело, что с решарпером, лишние расширения практически не нужны. Засовывать в один солюшен дофигища проектов не благодарное дело, "да у меня в солюшене +100500 проэктаф!!" -- сомнительное и нелепое удовольствие, когда можно поднять нугет и делать независимые проекты, всё по феншую.

Но даж так можно выгружать проекты в открытом солюшене и загружать по мере необходимости.

Нет такой острой проблемы, о которой многие почему-то жалуются. В любом случае можно уже скачать и пощупать Rider, который ощутимо по-быстрее студии.

Rock AmadeusВ Решарпере есть кодовая миникарта (крайний правый край), как в Sublime? Для Студии есть расширение, которое в последних версиях уже встроили в саму Студию, где это не просто миникарта, а там куча отметок полезных есть - от точек останова до визуального отображения длины кодовых блоков и прочее.

Что касается отметок, то отметки есть прямо на скроллбаре, кликабельные, этого обычно более чем достаточно. Кодовая миникарта наверное может быть полезна для длинных портянок кода. У нас жёсткий стайлгайд на этот счёт. Длинных портянок кода просто нет, поэтому кодовая миникарта бесполезна.


Rock AmadeusИ ещё надо, чтобы во всяких разметках и в коде, где встречается задание цвета, чтобы всплывало окно со спектром и можно было тыкнуть нужный цвет или выбрать его составляющие - как в графическом редакторе.

Есть такое.

Rock AmadeusЯ, может, что-то не то делаю, но когда надо весь проект в сборе под дебагом смотреть, то там все проекты должны быть включены, чтобы не было проблем с переходом к нужному коду. Со всякими символьными сборками у меня чего-то не заладилось. Есть ситуации, когда их либо нет, либо они не работают. Я не стал разбираться, а заметил, что если проекты все включены в солюшен, то проблем не возникает и под дебагом к коду другого проекта нормально переходит. А раньше тоже пытался по одному-три проекта в солюшене держать, не больше.

Терпеть :) Или переходить на юнит-тесты. Мы вообще режим дебага не поощряем в разработке. Только тормозит процесс разработки и усложняет. Хватает юнит-тестов для испытаний.

Rock AmadeusС юнит-тестами такая запарка, что на хорошие тесты надо времени потратить чуть ли не больше, чем на написание самого кода. Ну и объём их тоже, как правило, больше самого кода. У меня требования и сами алгоритмы в моих задачах постоянно меняются (т. к. идёт постоянная доработка алгоритмов и подходов, то фактически это перманентное прототипирование). Я только буквально для нескольких самых базовых и устойчивых частей несколько тестов написал и всё.

Не согласен. Слишком раздутые юнит-тесты показатель плохой декомпозиции и плохой архитектуры. Если для того, чтобы проверить логику вставки записи требуется замокать всю инфраструктуру, это плохой юнит-тест и действительно, он будет отнимать много времени, больше чем на саму разработку.

Хороший юнит-тест = маленький юнит-тест. Тестируются каждый класс изолированно. Тестируется только то, что делает класс, и ничего кроме этого. Большие тесты это интеграционные тесты и делаются они иначе, чем юнит-тесты, там не надо ничего мокать, надо использовать реальную инфраструктуру и смотреть результаты работы. Так что интеграционные тесты тоже не должны быть жирными.


Rock AmadeusЮнит-тесты, как я понял, это в основном для задач с устойчивым ТЗ, а не когда каждую неделю-две меняют-дорабатывают.

Не согласен. С устойчивым ТЗ как раз таки можно отказаться от юнит-тестов. Так как делается конкретная работа с конкретным сроком в который никто не закладывает написанеи юнит-тестов. Так как ничего не меняется, нет необходимости проверять, что ничего не сломалось после каждого изменения.

Юнит-тесты полезны именно в CI, когда меняется много и часто. Нет времени выяснять, сломалось ли что-то после очередных изменений, пусть это делает машина, а не человек.

Правильный подход к разработке с применением юнит-тестов приходит не сразу. И очень многие разочаровываются раньше, чем успевают научиться применять этот подход. Не стоит отчаиваться. Сначала да, это занимает время, много времени. Но по мере разработки и железобетонным принципом и бараньим упорством всё покрывать тестами, всё сводится к тому, что в целом скорость и качество разработки повышаются. И наступает такой момент рано или поздно, что ты вообще отказываешься от дебага и можешь до запуска приложения сказать, работает ли всё как надо или нет. И можеть точно сказать, что твои изменения ничего не сломают. В работе в команде это очень важно.

Rock Amadeusявляется каким-то замкнутым кругом - без опыта (т. е. сразу делать ПО с хорошей декомпозицией и архитектурой) лучше в юнит-тесты не соваться, а если не знаешь юнит-тесты, то и опыта для нормальной декомпозиции и архитектуры не имеешь. Да ещё такой архитектуры, которая будет устойчива при существенных изменениях ТЗ. Но, в целом, я согласен - что лучше пытаться и чего-нибудь получится, чем сидеть и ничего не делать - тогда точно будешь до конца жизни говнокодить.

Никакого замкнутого круга, просто движение :)
Печально, что абсолютно подавляющее большинство выбирают путь говнокода и безысходности. Да, для профессионального роста надо прилагать усилия. Но многие находят миллион причин и отговорок, чтобы не заниматься развитием.