Во-первых, я понятия не имею кто это, а во вторых мои тексты шикарны, и кликбейта в моих заголовках обчыно ровно ноль (если считать кликбейтом введение в заблуждение), хотя читателей, они, конечно, привлекают (за счет нарративности)
Да, согласен. Моё утверждение, что хороший код всегда красивый — неверное. Читабельный и поддерживаемый код всегда красивый. А в случае с перфомансом — часто есть трейдоф между читабельностью и производительностью, и если код критичен к скорости, то он может быть не красивым и при этом хорошим.
Другой вопрос, что критичность по перфомансу — редкость. а вот читать и поддерживать надо всё.
В целом это и есть посыл статьи. Я вижу вещь, которая как принято, она мне не нравится, я начинаю думать — как лучше. И в итоге-то все равно говно какое-то.
Название API — и правда странное, моя ошибка. Должно быть — WebApi, или %Domain%WebApi
Я бы подискутировал, на самом деле. Хороший код всегда красивый, красивый код не всегда хороший. Но эти вещи связаны. Эстетическая красота кода — это в том числе и красота архитектуры и дизайна — качества именно хорошего кода.
Кроме того, IDE и её возможности — очевидно со временем в гх и перекочуют. И если компилятор языка умеет отличать исключения от ивента, значит и инструмент для работы с этим языком должен и будет их различать
Кстати действительно достаточно здравый способ. Жаль в C# придется отдельный класс исключения фигачить, но, думаю, можно сделать один достаточно универсальный для таких случаев
А при чем тут мои тексты? Я показал, что если тебе ставят минусы, это не всегда заговор большой корпорации
Во-первых, я понятия не имею кто это, а во вторых мои тексты шикарны, и кликбейта в моих заголовках обчыно ровно ноль (если считать кликбейтом введение в заблуждение), хотя читателей, они, конечно, привлекают (за счет нарративности)
Я поставил минусы, но я не работаю в тинькове
Кстати, не знаете, они планируют это поменять, или так будет всегда?
Отличный пример поверхностного комментария человека, который решил не заморачиваться с погружением в статью, и совсем не знает темы
Кстати ведь да
Да, согласен. Моё утверждение, что хороший код всегда красивый — неверное. Читабельный и поддерживаемый код всегда красивый. А в случае с перфомансом — часто есть трейдоф между читабельностью и производительностью, и если код критичен к скорости, то он может быть не красивым и при этом хорошим.
Другой вопрос, что критичность по перфомансу — редкость. а вот читать и поддерживать надо всё.
Я слышал, что у них есть общепринятый инструмент для стат типизации, нет?
В целом это и есть посыл статьи. Я вижу вещь, которая как принято, она мне не нравится, я начинаю думать — как лучше. И в итоге-то все равно говно какое-то.
Название API — и правда странное, моя ошибка. Должно быть — WebApi, или %Domain%WebApi
Я бы подискутировал, на самом деле. Хороший код всегда красивый, красивый код не всегда хороший. Но эти вещи связаны. Эстетическая красота кода — это в том числе и красота архитектуры и дизайна — качества именно хорошего кода.
Кроме того, IDE и её возможности — очевидно со временем в гх и перекочуют. И если компилятор языка умеет отличать исключения от ивента, значит и инструмент для работы с этим языком должен и будет их различать
Надо, да. К сожалению.
Всё так. Только в .net все пишут или в райдере, или в студии с решарпером, который превращает её в райдер. Короче, ide то у всех одна и та же.
Раст шикарен. Как и F#. Но у меня-то работа на сишарпе, куда тут денешься. Хотя нам завозят рекорды, и скоро будут DU, будет получше
Кстати действительно достаточно здравый способ. Жаль в C# придется отдельный класс исключения фигачить, но, думаю, можно сделать один достаточно универсальный для таких случаев
Ну, как минимум оно свалится в default свитча, который, после вашего комента, я теперь буду ставить везде)
Maybe.CreateSuccess может отдавать Maybe, и если пихнули нулл возвращать Failure
Как и человека, который поставил мне минус (простите)
Мне кажется, что случай, когда ты можешь подставить "запасные" данные, или, как в твоем примере, коннекшн, достаточно редкие.
Ох как эмоционально. А теперь мы что, мы идём в любую кодовую базу среднего проекта на C#, и видим, что именно подход с исключениями там — основной.
Думаю такие, которые возможны в любом методе, можно и опустить.