Размышления об IDE

Хм, vim и emacs ты серьезными продуктами не считаешь, MSVS тебе не нравится. А что ты сам используешь-то?

с установкой visual assist все появляется. это трудно признавать, т.к. я сам любитель vim, но с таким объемом кода как у нас в конторе - ничто кроме студии+VA не справляется.

база данных cscope генерируется 50 минут (думаю, это позволит примерно прикинуть количество кода). и даже когда она есть — мало чем помогает. т.к. C++ с шаблонами, классами, интерфейсами и прочими радостями.

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

xcode пробовал. в 2006м. пользоваться не смог.

иными словами, дело не столько в том, что студия супер хороша. просто она единственная может то, что не могут другие IDE, и уж тем более текстовые редакторы.

p.s. у нас в конторе есть несколько хардкорных вимеров, включая меня, но никто из нас ниасилил кодить такой большой проект в виме. навигация по коду нереальна.

> другие IDE

А какие-то еще IDE пробовали?

А вообще любопытно. Я думаю, в мире существует огромное количество коммерческого софта, объем кода которого сравним с вашим. Интересно, они так же мучаются с глюками и тормозами?

ну конкретно на работе - я не пробовал (там все равно все на студию завязано, и с другими IDE не совместимо по определению - свои плагины для студии есть, система сборки на студию завязана, сборка и отладка под xbox360, и т.п.)

пробовал xcode на прошлой работе. ужас.

но пробовал в домашних условиях несколько разных.

eclipse - ужас (пробовал для жабы и C/C++)

всякие поделки типа kdevelop, anjuta и т.п. вообще бесполезно сравнивать. тоже пробовал, хотя и достаточно давно. они никуда не годятся.

netbeans вот не пробовал.. все собираюсь, но пока нет подходящей задачки.

может какие-то еще можешь предложить попробовать, для общего развития?

ах да, я еще забыл упомянуть.. у нас процентов 20 кодобазы на C# + winforms. это тоже большой решающий фактор в пользу студии.

> с таким объемом кода как у нас в конторе - ничто кроме студии+VA не справляется.

база данных cscope генерируется 50 минут (думаю, это позволит примерно прикинуть количество кода)

А зачем всю эту гору кода держать в одном проекте?

Помимо платной солярки есть и открытая. Но я ее не осилил - маловата репка...

если под словом «проект» подразумевается .vcproj — то их много :)

иначе не совсем понял вопрос.

Как же это она медленно работает если под ее управлением даже обычные машины Audi уже ездят? http://www.linux.org.ru/jump-message.jsp?msgid=5603204&cid=5605193

предугадывая, что щас мне начнут писать что у нас неправильные проекты, неправильный код, и т.п. - да, я в принципе заранее согласен. предпочел бы, чтобы они были написаны на C вместо C++, собирались через Makefiles, редактировались в vim, а отладки и рефакторинга вообще не требовали.

но такова реальная жизнь.

>Насчет сравнения с MSVS ничего сказать не могу. Но все же думаю, что в плане сугубо IDE-специфичных фич (вроде того же рефакторинга и дебаггинга) он таки пока уруливает все остальное.
Оно хотя бы плюсовые контейнеры умеет нормально отображать при дебаге?

> если под словом «проект» подразумевается .vcproj — то их много :)

Нет. Под словом «проект» подразумевается «self-contained сущность» :) То есть набор кода, при работе с которым навигация не выходит за пределы этого набора.

>Оно хотя бы плюсовые контейнеры умеет нормально отображать при дебаге?

А кто-то это _не_ умеет?

>Оно хотя бы плюсовые контейнеры умеет нормально отображать при дебаге?

Естественно.

>А кто-то это _не_ умеет?
Ну вот эклипс сам не умеет. Кое как научился правда подхватывать гдбшные pretty print, но мегакриво и убого. Например vector<string> он тебе покажет в каком окошечке в виде текста, но полазить по нему нельзя, не говоря уж о том, чтобы изменять значения. При сложные конструкции говорить не приходится вообще. В общем даже до уровня студии десятилетней давности не тянет.

>Естественно.
Гм, ну ка покажи, как он какой нибудь auto_ptr<vector<pair<string, vector<int> > > > отображает :)

> не выходит за пределы этого набора.

в терминах вижуалов - это sln-файлы. да, их тоже много. но это как мировой океан разделить на 20 частей. выпить даже одну не получится :)

если говорить о причинах - наверное, это потому что интерфейсы между модулями постоянно меняются. надо часто все пересобирать. не думаю, что есть какие-то конкретные причины кроме этих. грубо говоря, если я работаю над менеджером памяти, и меняю в нем реализацию inline-функций в memory.h — то пересобирать придется весь проект :)

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

ну и в этом духе

> это sln-файлы. да, их тоже много. но это как мировой океан разделить на 20 частей. выпить даже одну не получится :)

Ну, если у вас для одного sln база ctags строится 50 минут... круто, да.

у нас неправильные проекты, неправильный код, и т.п. - да, я в принципе заранее согласен.

Быдлокод, nuff said.

>Тот кто первым делом думает про формочки при упоминании VS заслуживает эвтаназии.

Я ж про это выше писал. Конкретно это сообщение - ответ товарищу, который сказал, что ему так в студии удобно.

в 4ке вроде как появился и git

XCode - хрень, IDEA решает

> C#

Монодевелоп? :3 а вообще, зря кдевелоп не понравился, он вообще сделан на довольно высоком уровне (хотя достаточно давно ветка 4 была совсем сырой, да).

Кстати, уточню.

Насчет сравнения с MSVS ничего сказать не могу. Но все же думаю, что в плане сугубо IDE-специфичных фич (вроде того же рефакторинга и дебаггинга) _он_ таки пока уруливает все остальное.

Под словом «он» я подразумевал таки MSVS (: а то походу неправильно поняли меня.

Ты упоролся

Ну в плане рефакторинга точно не уруливает, там его просто нет для C/C++.

>В общем, тот принцип работы, о котором рассказывал shimon в подобном топике, когда весь UNIX считается IDE...

омг, разве это не так?

еще есть Geany, но это вообще нечто среднее

почему же, вполне себе текстовый редактор для программирования. К IDE его не отнесешь, так как никакой модели кода внутри Geany нет (поэтому и работает быстро, кстати)

>собирались через Makefiles

если у вас все для винды, то определенно CMake

> Монодевелоп?

честно говоря, я сам не шарпист, и вообще не знаю какие есть для него IDE, и чем отличаются. но т.к. у нас многие шарписты одновременно и плюсисты - не думаю, что им будет удобно 2 разных IDE использовать.

> то определенно CMake

это уже детали. мы в одном проекте использовали jam - очень хорошо получалось. лучше, чем система сборки встроенная в студию, всяко :)

>Расскажи, как в этот хваленый XCode интегрировать Git, и я его буду использовать.

Git не надо никуда интегрировать, он замечателен именно своими консольными инструментами

Мне не удобно писать .NET коды и проекты блокнотом и компилировать их msbuild-ом.

Я не вижу не одного аргумента против VS, да платная, а что делать :)

>Git не надо никуда интегрировать, он замечателен именно своими консольными инструментами

Точно.

для c/c++ кода SlickEdit очень неплох. по общим ощущениям приятней студии. еще SourceInsight хорош для навигации по коду.

> но т.к. у нас многие шарписты одновременно и плюсисты - не думаю, что им будет удобно 2 разных IDE использовать.

Monodevelop и на плюсах позволяет писать. Правда насчет качества идешки не ручаюсь, но говорят что вроде хороша.

> Ну в плане рефакторинга точно не уруливает, там его просто нет для C/C++.

Как это нет? Есть же. (или ты не про студию?)

>Git не надо никуда интегрировать, он замечателен именно своими консольными инструментами

Ретрограды, такие ретрограды. Видеть прямо в коде инлайновый дифф, а в дереве проекта измененные файлы намного удобнее чем git status и git diff.

> почему же, вполне себе текстовый редактор для программирования

Ну все же по сравнению с тем же vim возможности редактирования у него очень ограничены. А вообще использую geany для питона. В принципе нравится, хотя конечно не хватает кой-каких фич (:

> Видеть прямо в коде инлайновый дифф

Честно говоря, плохо понимаю удобство это фичи. Как оно выглядит, скрин не покажешь?

Ну например так:
https://wiki.kuali.org/display/KULRICE/Eclipse+Tips
Удобно же. Видишь сразу где есть изменения в файле, плюс можно посмотреть что было до этого и откатить легко блок или одну строку этих изменений.

> https://wiki.kuali.org/display/KULRICE/Eclipse+Tips

Это не inline diff, а жалкая пародия.

Покажешь лучше, или ты просто решил погазифицировать?

> Покажешь лучше

Запусти $VCS diff и посмотри. Заметь, что нормальный diff показывает _два_ фрагмента текста - старый и новый, в отличие от недоразумения, называемого quick diff.

или ты просто решил погазифицировать?

...сказал промышленный генератор сероводорода.

> откатить легко блок или одну строку этих изменений

Это удобно, да. Но что где там на скриншоте я не понял (:

>Запусти $VCS diff и посмотри. Заметь, что нормальный diff показывает _два_ фрагмента текста - старый и новый, в отличие от недоразумения, называемого quick diff.

facepalm.jpg В редакторе новый код, в хинте - старый. А теперь марш убиваться об стенку.

>Это удобно, да. Но что где там на скриншоте я не понял (:
А как ты это на скриншоте посмотришь? Возьми нормальную IDE, да попробуй сам.

>> Запусти $VCS diff и посмотри. Заметь, что нормальный diff показывает _два_ фрагмента текста - старый и новый, в отличие от недоразумения, называемого quick diff.

facepalm.jpg В редакторе новый код, в хинте - старый

Нахрена мне в хинте?

А теперь марш убиваться об стенку.

После тебя.

>Нахрена мне в хинте?
Ты подебил.

>> Нахрена мне в хинте?

Ты подебил.

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