Pull to refresh

Comments 73

имхо далеко даже не 50% кода большинства приложений на C# будет взаимодействовать с кривым API или внешней средой. Так что ваши доводы слишком специфичны для столь широких выводов.

По дату вообще не понял.
Про дату очень просто. В C++ и в C# 64-битным целым кодируются разные типы даты.
С датами вообще ахтунг =).
Я в одном из проектов поимел опыт с разными форматами дат — раньше и понятия не имел сколько разных вариантов хранения в этой жизни. Кто-то считает от 1600 года, кто-то от 1900, кто-то в секундах, кто-то в миллисекундах, кто-то в тиках и т.д. и т.п.
Напишешь адаптер для таких случаев, и потом «радостно» смотришь на получившийся код и думаешь как бы это причесать получше…
Эт я в курсе. Но чем плох тот метод перевода из __time64_t в DateTime кроме названия?
Он плох магической формулой 10000000 * time_t + 116444736000000000, конечно же. Вдруг в ней ошибка?
Так можно сказать о любом методе с вычислениями. Можно сделать тест.
Не нужны тут вычисления. Лишние они. Это проблема прослойки с внешним миром, где C# никак не помогает.
Хорошо, а что тогда помогает?
В том то и дело, что ничто. :)

Пост ведет обреченный бой с убеждением, что смена языка позволяет писать проще/легче/компактней. И хотя это действительно правда, но она как-то извращена в сознании. :) Сложно объяснить. Просто нужно пообщаться с определенными людьми, ставящий язык вперед паровоза. :)
Хм, язык выбирают под задачу. Удачная смена языка действительно позволяет писать проще/легче/компактней. Совет. Не выносите свои трудности в общении с живыми людми в такие посты.
Эм, а если бы нужно было перевести дату из DateTime в __time64_t — то эта формула была бы не такой волшебной?
Неужели не понятно, что хотелось бы иметь готовый метод для этого?
… и еще на полтора милиона разных форматов дат…
А мне бы очень хотелось язык программирования, в котом есть функция СделатьВсёКруто()
R# скоро сделает возможным программирование только при помощи Alt+Enter (избитая шутка, не моя).
Как избавится от кучи throw new исключений
Объявляем в начале

bool exception = true;

if (validInput)
{
        this.currentDropDownComboChoice = dropDownComboChoices[indexInput];
        if (currentDropDownComboChoice == Resources.Viva64)
          UseViva64Analysis(nullnull);
        else if (currentDropDownComboChoice == Resources.GeneralAnalysis)
          UseGeneralAnalysis(nullnull);
        else if (currentDropDownComboChoice == Resources.VivaMP)
          UseVivaMPAnalysis(nullnull);
 
        if( Enum.IsDefined(typeof(Resources), currentDropDownComboChoice))
           exception = false;
}
 
if (exception)
    throw new ArgumentException()
 

Имхо, лучше тогда
Exception exception;
если чтото не так
exception = new…

а в конце
if (exception != null)
throw…
Это с учетом, что исключения могут быть разными, а в данном контексте bool отлично смотрится и мы таки сэкономили пару байт на объекте исключения :D
Да запросто, разными =). Инициализаторы полей и конструкторы никто не отменял.
А вот экономия в пару байтов — не слишком ли рано думать об оптимизации? Это ведь зло… =)
Про оптимизацию — исключительно шутка :)
Думаю код писал 1 человек, если бы было парное программирование, второй разработчик не стал бы мирится с десятком throw new
В общем, журить я не стану, каждый пишет в меру своих знаний, но если знать C# на достаточно глубоком уровне и многие вещи вынести в helper'ы код станет прекрасней ;)
Именно поэтому и надо такие вещи выносить и инкапсулировать подальше от глаз. А наверх выставлять красивый, стройный, строгий интерфейс. При желании написать г.нокод — никакой язык не спасет. А вот наоборот — возможно варианты. Очень сложно на некоторых языках писать так, чтобы не получался код, от которого волосы дыбом встают.
Есть такое дело, что на C# проще писать GUI и всякие там работы с данными и сервисами. Ни кто и не говорил, что C# надо завивать все гвозди на свете.

Напишите код работы с VS на C++, что бы показать на сколько он отличается от кода на C#. Сейчас это не сравнение, это выпячивание косяков написания плагинов к vs на C#. Косяков в любой языке полно, а дописания плагинов к ide помоему ни где не является прям легкой прогулкой.

Я не являюсь специалистом, просто слышал, что если писать на MEF дополнения к студии, то там вроде как не плохо.

На счет конструктора DataTime — не знаю как Вы, а я ни разу не помню, что бы нужно было такое делать. Я понимаю, что задача весьма специфичная у Вас.
>> Ни кто и не говорил, что C# надо завивать все гвозди на свете.

Пост ровно об этом :-). Бывает мнение, что к примеру, переписать все на C# надо. Пост подтверждает, что не все на C# лучше.

>> Я не являюсь специалистом, просто слышал, что если писать на MEF дополнения к студии, то там вроде как не плохо.

Врут.

>> На счет конструктора DataTime — не знаю как Вы, а я ни разу не помню, что бы нужно было такое делать.

Может и специфичная задача, но ведь в любом крупном проекте (наш — маленький) задачи специфичные.
Идем далее
int indexInput = -1;
for (indexInput = 0;  indexInput < dropDownComboChoices.Length;  indexInput++)

что там забыл indexInput = -1? :)
Ошибка! Осталось с прошлого кода. Поймали :-).
Сорри за оффтопик, но очень любопытно — Вы это сами заметили или тулза вроде R# подсветила?=)
Я думаю в чужом новом коде (типа как в статьях) ошибки глаз видет легко, так как не замылен. А вот в своем такое в жизни не заметишь.
Указанного рода ошибки, как раз R# покажет автоматом и не надо будет замыленным взглядом смотреть, но в целом согласен.
Я IDE не запускал, просто пробежал 2 раза глазами по коду
Простота-то где?
Простота в голове.
При всем уважении к вашей компании (давно наблюдаю за вами), статья как раз из серии «holy wars».
Язык программирования в данном случае совсем ни при делах, как и евангелисты. На протяжении всей статьи вы ругаете, по сути API расширения Visual Studio, но при этом ссылаетесь на недостатки языка.

Особенно «модной» является тема превосходства одного языка программирования над другим. Ну, к примеру, что C# «круче», чем C++.
выглядит как надуманная фраза. я не вижу, чтобы было «модно» говорить, что «C# круче C++» — они просто разные, у них задачи разные.

Конвертировать __time64_t в DataTime конечно не сложно, для этого всего лишь надо написать функцию типа такой
int t= 1070390676; // value of time_t
DateTime dt= new DateTime(1970,1,1).AddSeconds(t);

DataTime
DateTime

Да, авторы кода не умеют писать на C#, но от этого C# не становится волшебнее
совсем какая-то глупость написана.

Я прекрасно понимаю, что статья вызвана гневом в сторону VS API. Но это не повод писать подобные «разоблачающие статьи». Иногда лучше все-таки промолчать, чем написать глупость.
Нет, VS API тут ни причем. То есть он неудобен конечно, но и злобы нет никакой. Хотелось показать, что как только дело доходит до реального кода, так сразу вся красота о которой много говорится улетучивается. Вот вроде foreach есть, а толку нет. И так с очень, очень многим. Меня это совершенно не удивляет. Я понимаю, откуда ноги растут и что такое прослойка с внешней средой и так далее. Но никак не получается донести на масс мысль, что синтаксический сахар языка и так далее это второстепенно. Сложность решения задачи за редким исключением практически не зависит от языка. И прослойки и прочее как были нужны в Си, так они никуда не ушли и в C#. Но видимо и этот пост также останется без понимания. :)
Это понятно. Я вам про другое говорю: вы пытаетесь говорить о недостатках языка программирования, указывая при этом на недостатки конкретной библиотеки. Это некорректно.
Я много пишу реального кода на C#, и поверьте мне, красота она остается и никуда не улетучивается :-)
Ну и с утверждением что .NET — синтаксический сахар позвольте мне тоже не согласиться, .NET — это, все-таки, нечто большее.
Но никак не получается донести на масс мысль, что синтаксический сахар языка и так далее это второстепенно.

Вообще никак не вяжется с текстом статьи. Пост совсем о другом.
Простой combobox

Код, который вы привели, откровенно «пахнет». Это свидельствует либо о невысокой квалификации автора кода (т.е. отсутствию знаний в области паттернов и базовых навыков рефакторинга), либо о спешке, в которой данный код писался, с заделом на рефакторинг (который, видимо, так и не был выполнен). Думаю, что данный код вполне поддается простому рефакторингу — причем под нож пойдет, скорее всего, вся логика, завязанная в методах UseViva64Analysis, UseGeneralAnalysis и UseVivaMPAnalysis. Какой паттерн использовать — не могу сказать точно, поскольку не обладаю контекстом. Но могу предположить что это будет гибрид стратегии и фабричного метода (а может и абстрактной фабрики).

Навигация по коду в Visual Studio

Не вижу ничего плохого в этом коде. Его сложность обусловлена большим количеством обращений к большому количеству сервисов и обработкой промежуточных результатов. Вполне нормальная ситуация, называемая «decomposition overhead». Все лучше чем «high coupling». А по поводу того, сложен этот код или нет… Что ж — брось новичка на более-менее большой реальный проект — ему все покажется сложным, вплоть до точки с запятой.

Работа с датой

DateTime.FromXXX — вы не пропустили этот методы? Возможно среди них скрывается нужный вам. Я не вникал, но там как минимум один метод, который принимает long в качестве параметра.

Перебор всех проектов одного решения (solution)

Данные классы являются обертками над COM-компонентами IDE. Именно поэтому выглядят и ведут себя подобным образом. Да — это плохо, некрасиво. Но это — тяжелое наследство.

Выводы
Как выше верно заметили, пост напоминает какой-то наброс. Автор увидел массу кода, которая испугался его и убежал программировать на Visual Basic-е, где все просто и понятно.
Если уж на то пошло, я могу нарыть такую массу гавнокода на С++, что будет просто жутко от того, насколько неумело и не к месту используются конструкции и возможности этого великолепного и гибкого языка.
Код в разделах «Простой combobox» и «Навигация по коду в Visual Studio» сгенерирован машиной или же написан руками? В первом случае он может быть сколь угодно ужасен (т.к. генерированный код не должен быть предназначен для чтения). Во втором случае очевидно, что автора такого кода надо пороть сажать за изучение рефакторинга. Срочно!!!

Взгляните, например, на этот пример. Лучше всего вместе с этим.

Автор совершенно точно подметил, что "Язык здесь «перпендикулярен» к решаемой задаче и практически не оказывает влияния". Язык влияет на сложность решения задачи меньше, чем умение программиста работать с программными абстракциями (выявлять, обобщать, разделять...)
Этот код ручной. Почему такой — исторически сложилось (многократные вынужденные правки). Постепенно перепишем. Собственно сейчас и разгребаем чердаки. Попутно было решено написать о том, что вот C# как-то не помешал создать подобное. :)
И это не смотря на классическую мантру — пишите на C# и ваши волосы будут неотразимы. Так вот заявляю — нихрена C# писать более качественный и простой код не помогает. Вообще никакой разницы. :)
Вторая мантра — рефакторинг. Я тоже тут очень скептичен, хоть и не отрицаю пользу.
C# как-то не помешал создать подобное.

Очень похоже на
Перила моста как-то не помешали самоубийце сброситься вниз.


Читаю и умиляюсь… А КАК именно он должен был вам помешать писать ПЛОХОЙ код? Если вы хотите писать хотя бы отчасти правильный и безопасный код — включайте Code Analisys в проектах и радуйтесь жизни.
Фразы про «Если вы хотите писать хотя бы отчасти правильный и безопасный код» и упоминание «Code Analisys» меня умилило просто… :))) Прям даже настроение поднялось! Спасибо!

p.s.
Если причина не понятна, то приглашаю в профиль и на наш сайт www.viva64.com. :)
Все-таки DangerT прав. Как вы представляете, чтобы язык программирования мешал вам писать плохой код? :-)
И еще раз повторюсь — никаких мантр типа «пишите на C# и ваши волосы будут неотразимы» нет вокруг, для каждого языка — свой контекст и своя задача (может быть предоставите источник с опровержением?).
Что касается Code Analysys, то это, пожалуй, единственный инструмент, которых хоть и косвенно, но хоть как-то может «помешать писать плохой код».
Так что не вижу причин для умиления.
«Как вы представляете, чтобы язык программирования мешал вам писать плохой код?»
Я — никак. Это не мои мысли. Они чужие. И их много. :) Я затрудняюсь привести конкретные примеры. Это скорее на уровне постоянного фонового шума который нас окружает: «а вот если писать на C#/X/Y/Z то ошибок/сложностей не будет».

Умиление возникло от того, что мне напомнили про статический анализ кода. :) Я только всеми руками и ногами за! Просто я и так в данной теме по самые уши. Уж дальше некуда. ;)
Скорее фоновый шум, окружающий нас говорит о том, что в некоторых ситуациях действительно проще решать задачи на C#, чем C++ (не умоляя достоинств C++).
Вот, например, вам уже приводили в комментариях пример, который на C++ будет выглядеть менее элегантно. Не спорю, есть и обратные примеры. Поэтому и говорю — каждой задаче свое.
Перечитал все ваши комментарии еще раз, отчасти вашу позицию понять можно. Но на мой взгляд вы смотрите на ситуацию однобоко: говорите о том, что в некоторых ситуациях C# плох, при этом умалчиваете о других, где C# очень хорош. Поэтому не будьте так критичный и категоричны — лично мне, например, C# сэкономил за всю жизнь не одну сотню часов.

Умиление возникло от того, что мне напомнили про статический анализ кода. :) Я только всеми руками и ногами за! Просто я и так в данной теме по самые уши. Уж дальше некуда. ;)
Именно поэтому я и продолжил с вами дальнейшую дискуссию. Был бы кто-то другой — возможно, и убеждать не стал.
Такое ощущение, что Вы спорите не с нами, а с кем-то еще? Я (или мой коллега) где-то говорили, что C# плох? Или может быть Вы такой вывод сделали из того, что у нас часть кода на C# в нашем проекте? Или еще из-за чего-то?

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

Приписывание мне «нелюбви» к C# абсолютно напрасно.
Ну как минимум:

Так вот заявляю — нихрена C# писать более качественный и простой код не помогает.

Вся изящность теряется, стоит захотеть написать что-то реальное, а не пример «сам в себе».

Хотелось показать, что как только дело доходит до реального кода, так сразу вся красота о которой много говорится улетучивается


ну и далее по тексту/комментариям.
Я скажу последнее слово — скачайте ЛЮБОЙ проект команды Patterns&Practicies и изучите хотя бы поверхностно. Думаю вам (или вашему коллеге, которого вы тут так рьяно защищаете) станет очень стыдно за этот пост.
Я не говорил что Code Analisys — панацея от всех бед. Но уж по крайней мере он, например, помешает вам обратиться к виртуальным свойствам или методам в конструкторе класса и спасет таким образом от весьма трудноотлаживаемых ситуаций.
Если уверены что C# ничуть не лучше C++, интересно увидеть этот участок кода, переписанного на С++ не превышая объем кода в 2-3 раза минимум
И чего? Повторюсь, сие есть косяк криворуких создателей BADA SDK, которые видимо об c++0x не слышали
Та собсно статьи одного уровня. Можно еще было приплести что Лондонская Биржа ушла с .NET.
Неконструктивно, написав пост, воспринятый в штыки, показывать пальцем на других — «а вот смотрите — они еще хуже чем я пишут!».
Не понятно, за что в штыки. Но я подумал и кажется чувствую в чем диссонанс.
Например, я уже достаточно компетентен в некоторых вопросах и имею смелость заявить о себе следующее:

1) Я пишу плохой, ужасный код.
2) Я не знаю язык Си++, на котором пишу. А уж про C# вообще только слышал.

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

Другой вопрос, что я в вкладываю в свое «я не знаю Си++» и «пишу плохой код». Но это уже остается за кадром. :) Юмор поймут только единицы, а остальные оставят еще свой минус.
Ну вот — совсем другое дело. Следы раскаяния налицо. А минусовали вас, скорее всего не за нерадивость, а за то упорство, с которым вы пытались поддержать автора и доказать тут всем, что эта статья хорошая и пушистая, и ее автор вовсе не хотел сказать что все C# программисты нубы и могут писать только ХеллоуВорлд.

ЗЫ Я кстати не минусовал ни один ваш комментарий, поскольку все ваши комментарии не были лишены смысла.
На всякий случай призовем на помощь К.О. Andrey2008 — разработчик статического анализатора для C++ кода.
Ой! Вы лично знакомы с кэпом? Передавайте привет :)
Прошу прощения, но зачем все это?
Любой здравомыслящий человек понимает что код на императивных языках, предоставляющих приблизительно одни и те-же механизмы абстракции, будет выглядит одинаково херово
Не, не понимают. :) Что и подтверждается минусиками к комментарию.
На хабре минусики к комментарию могут быть вызваны чем угодно
Это лишь говорит о кривом проектировании API конкретной библиотеки, а не об убогости языка
Данным постом я хотел показать, что далеко не всегда код на C# (или другом языке) проще, чем код на C/C++. И поэтому слепо верить в то, что «надо все переписать на C#» не нужно.

Данным постом вы показали, что интероп между нативными и управляемыми решениями имеет некоторый оверхед. Вот если бы студия была написана на WPF, например, то все бы означенные проблемы испарились, как будто их и не было. Так что вывод вообще мимо.
VS 2010 написана на WPF. Правда не смотрел еще внутрь API для нее, но, по многочисленным утверждениям, расширения пишутся на порядок проще.
поэтому, когда мне говорят, что ява плохой язык, а есть лучшие языки, я думаю что человек, который это пишет, — идиот, ну или просто не думал, что писать.
кстати, в VCL, в delphi и c++ builder работать с комбобоксом просто. очень просто.
по поводу функции преобразования времени. ну была бы она не в вашем коде, а в библиотеке. и следить за ее правильностью пришлось бы не вам, а разработчикам языка. напишите один раз и вынесете в библиотеку. проблемы почти нет.
Sign up to leave a comment.