Середовище розробки для C

Шукаємо ідеї щодо створення зручного та продуктивного середовища для розвитку C. Мені здалося, що редагування C за допомогою Vim дуже корисне, але я хотів би отримати більш широкий вибір вибір пропозицій.

• Emacs / Vim / Eclipse / ... - Особисто я користувач Emacs. Якщо ви виявите, що контрольні послідовності втомлюються, просто вимкніть його в режимі Viper-Mode. Emacs настільки добре інтегрований в unix, що дозволяє дуже просто контролювати все з одного місця. Тут також Vim робить непогану роботу, але я вважаю, що Елісп є набагато потужнішою мовою розширення, ніж Vim Script. Можна говорити годинами про всі шляхи створення Emacs для розвитку C. Режим Flymake був згаданий, і це супер початок для речей. Я не знайомий з Eclipse, я не вважаю, що він залишає достатньо місця на екрані для коду, і мені не подобається, наскільки він роздутий (користувачі Vim скажуть те саме про Emacs). Я також несправедливо ухиляюся від того, що написано на Яві, з чисто естетичних причин.

• Ctags - Позначте свої C (або багато інших мов) функції, щоб Vim або Emacs або що-небудь ще могли трохи посилання на гіпертекст у ваших файлах. Скажіть, ти блукаєш, і бачиш функцію, і ти дряпаєшся головою, кажучи: "Що це робить знову? Іменування трохи розпливчасте". Plink-plank-plunk, ви можете переключитися прямо на його визначення.

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

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

• Stumpwm / wmii / XMonad / ... - У якийсь момент ви зрозумієте, що все, що ви можете зробити, щоб робота працювала, значно покращить ваш результат. Один з найкращих способів уберегти ваш мозок від порушення його контексту - це перейти на плитку, менеджери вікон KEYBOARD DRIVEN. Я особистий шанувальник StumpWM , Emacs віконних менеджерів. Повністю реалізований під час налаштування під час звичайного Lisp-процесу на ходу, все, що ви виявите, що ви робите неодноразово, можна вигнати у функції та прив’язати до команд. Чудові речі. Я не знаю багато про будь-який з інших, але, можливо, подальше опрацювання краще залишити на іншій темі. ВИКОРИСТОВУЙТЕ КЛЮЧІВ, ЩО МОЖЛИВО

• GDB - я не знайомий з іншими налагоджувачами, але це, здається, стандарт де-факто.

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

Я деякий час наполегливо працював з Vim, варто знати основи VIM, оскільки ви завжди знайдете поле UNIX десь там, де тільки це є, але я спробував Emacs і не оглядався. Eclipse - це «сучасна» альтернатива, у мене в системі все троє!

Це дуже особисті переваги, тому я не думаю, що я можу зробити набагато більше, ніж сказати вам, чим я користуюся. У мене Emacs створений у режимі Flymake , який періодично збирає файл, над яким ви працюєте, і аналізує вихід компілятора, щоб з'ясувати, які помилки ви зробили. Він приховує помилки / попередження в буфері та показує відповідне повідомлення про помилку компілятора

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

Якщо ви займаєтесь розробкою C під Unix / Linux, вам абсолютно доведеться використовувати Cscope, якщо проект має значні розміри.

Cscope є інструментом розробника для перегляду вихідного коду - перехід до функції foobar«s визначенням, знайти всі місця , де змінний fooпосилаються, знайти всі файли , в тому числі bar.h, змінити все входження barв bazі т.д.

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

Ви можете використовувати пакет Netbeans C / C ++, який працює з G ++ / GCC:

netbeans.org/features/cpp

мій особистий фаворит - exVim . У ньому багато плагінів vim, що робить його дуже простим у використанні з великою базою коду. Мені знадобиться приблизно 1 день, щоб дізнатися його особливості, але воно того варте.

Я редагую C з Vim у консолі. Я використовую makefiles та маю ряд компіляторів, щоб перевірити свій код на, зокрема gcc, clang (LLVM) та icc. Інші речі, які я вважаю частиною свого середовища розвитку: використання грепу, налагоджувачів і вальгринд. Мова сценаріїв для більш складних побудов. Git для контролю версій.

На мою думку, важливіше, ніж те, що ви використовуєте для редагування коду, - це структура вашого коду. Як викласти це, мабуть, питання для переповнення стека, але, як ви вже запитували, у мене часто є окремий каталог для об'єктного коду, який не поширюється, та інша папка для результуючого бінарного файлу (y | ies). У мене є тестова папка, яка містить більше файлів С, які використовують увесь загальний код, який я пишу, і ці знаки, і кінцевий файл проекту.

Ви можете спробувати Motor IDE . Це прокляття, тому вам слід відчувати себе як вдома (тм). Це також трохи сумно, оскільки його не підтримують вже 5 років, щоб щось не було порушено. Хоча все ж - я вважаю, що варто спробувати.

Я використовую gedit із вбудованим терміналом.