Среда разработки для C

Ищете идеи по созданию удобной и продуктивной среды разработки для разработки на C. Я нашел C редактирование с Vim очень полезным, но я хотел бы получить более широкий выбор предложений.

• Emacs / Vim / Eclipse / ... - Лично я пользователь Emacs. Если вы находите контрольные последовательности утомляющими ваш мизинец, просто включите Viper-Mode. Emacs настолько хорошо интегрирован в Unix, что позволяет очень легко контролировать все из одного места. Vim также отлично справляется с этой задачей, но я считаю, что Elisp гораздо более мощный язык расширений, чем Vim Script. Можно часами говорить о всех способах настройки Emacs для разработки на Си. Режим Flymake был упомянут, и это супер начало вещей. Я не знаком с Eclipse, я не нахожу, что он оставляет достаточно места на моем экране для кода, и мне не нравится, насколько он раздутый (пользователи Vim скажут то же самое о Emacs). Я также несправедливо склонен против всего, что написано на Java, по чисто эстетическим причинам.

• Ctags - помечает ваши функции C (или многих других языков) так, чтобы Vim или Emacs, или что-то еще, могли делать немного гипертекстовых ссылок в ваших файлах. Скажем, вы бродите вокруг и видите функцию, и вы почесываете голову, говоря: «Что это делает снова? Названия немного расплывчаты». Plink-plank-plunk, вы можете сразу перейти к его определению.

• Cmake / Gnu-Autotools - Make - это здорово, но в какой-то момент вам нужно немного абстрагироваться, чтобы ваш проект мог работать на всех типах систем, для которых у вас нет возможности протестировать. Если вам нужны только люди для сборки вашего кода на * nix, Autotools - это здорово, но, на самом деле, вы все равно должны ознакомиться с Cmake. Команда Cmake собирает код в любой возможной конфигурации и гарантирует, что вам не придется проходить через головную боль. Если вы хотите, чтобы ваш проект был легко подобран, купите другие, один из этих инструментов имеет решающее значение.

• Git / Mercurial / Subversion / ... - Вы могли бы потратить месяцы на изучение программного обеспечения для контроля версий, но вам, вероятно, стоит просто пойти с Git. Он твердый, он распространяется, ядро ​​@ $! #% & Linux отслеживается с ним. Если это достаточно хорошо для Линуса, это должно быть достаточно хорошо для вас. Я также слышал хорошие вещи о Mercurial, по-видимому, G ** Gle использует их, так что это, вероятно, не плохо. Некоторым людям нравится Subversion, CVS и еще много чего. Мне они не нравятся, потому что они монолитные, что для меня очень неудобно и ограничивает.

• Stumpwm / wmii / XMonad / ... - В какой-то момент вы поймете, что все, что вы можете сделать, чтобы ваша работа продолжалась, значительно улучшит вашу производительность. Один из лучших способов удержать ваш мозг от разрыва контекста - это переключиться на тайлинг, оконные менеджеры KEYBOARD DRIVEN. Я личный фанат StumpWM , Emacs оконных менеджеров. Полностью реализованный в настраиваемом процессе Common Lisp на лету, все, что вы делаете постоянно, может быть изгнано в функции и привязано к командам. Качественный товар. Я не знаю много о других, но, возможно, дальнейшая разработка лучше оставить в другой теме. Используйте клавиатуру как можно больше.

• GDB - я не знаком с другими отладчиками, но это, кажется, стандарт де-факто.

• Valgrind - я не знаю ничего другого, что делает то, что делает так хорошо. Valgrind крайне важен для всех тех досадных попыток профилирования / утечки памяти, которые вы хотите продолжить. Вы просто не можете написать код с помощью malloc / calloc без Valgrind.

Некоторое время я продолжал работать с Vim, стоит знать основы VIM, поскольку вы всегда найдете где-нибудь UNIX-систему, в которой есть только это, но я пробовал Emacs и не оглядывался назад. Eclipse - «современная» альтернатива, у меня все три в моей системе!

Это очень личное предпочтение, поэтому я не думаю, что могу сделать гораздо больше, чем просто рассказать вам, что я использую. У меня Emacs настроен с режимом Flymake , который периодически компилирует файл, над которым вы работаете, и анализирует выходные данные компилятора, чтобы выяснить, какие ошибки вы допустили. Он подсвечивает ошибки / предупреждения в буфере и показывает соответствующее сообщение об ошибке компилятора

Я использую Kate (text) gcc / avr-gcc и make, с Git в качестве VC. В основном я делаю встраиваемые вещи в c и на стороне компьютера в python.

Если вы занимаетесь разработкой C под Unix / Linux, вам обязательно нужно использовать Cscope, если проект имеет значительный размер.

Cscope - это инструмент разработчика для просмотра исходного кода - переход к foobarопределению функции, поиск всех мест, на которые fooссылается переменная , поиск всех файлов, включая bar.h, изменение всех вхождений barв bazи т. Д.

Кроме того, вы упомянули Vim в своем посте ... вот руководство по использованию Vim & Cscope вместе.

Вы можете использовать пакет Netbeans C / C ++, который работает с G ++ / GCC:

netbeans.org/features/cpp

мой личный фаворит - exVim . Он имеет множество плагинов vim, что делает его очень простым в использовании с большой базой кода. Я потратил около 1 дня, чтобы изучить его особенности, но оно того стоит.

Я редактирую C с помощью Vim в консоли. Я использую make-файлы и имею несколько компиляторов для тестирования моего кода, включая gcc, clang (LLVM) и icc. Другие вещи, которые я считаю частью моей среды разработки: использование grep, отладчиков и valgrind. Язык сценариев для более сложных сборок. Git для контроля версий.

На мой взгляд, более важным, чем то, что вы используете для редактирования кода, является то, как вы структурируете свой код. Как это выстроить, возможно, является вопросом для переполнения стека, но, как вы спросили, у меня часто есть отдельный каталог для объектного кода, а не для распространения, и другая папка для результирующего бинарного файла (да). У меня есть папка для тестирования, которая содержит больше C-файлов, которые используют весь общий код, который я пишу, и эти, которые я valgrind, вместе с окончательным файлом проекта.

Вы можете попробовать Motor IDE . Он основан на проклятиях, поэтому вы должны чувствовать себя как дома (тм). Это также немного грустно, потому что он не поддерживается в течение 5 лет, поэтому что-то может быть сломано. Хотя все же - я считаю, что стоит попробовать.

Я использую Gedit со встроенным терминалом.