Środowisko programistyczne dla C.

Poszukuję pomysłów na stworzenie wygodnego i produktywnego środowiska programistycznego dla rozwoju C. Uważam, że edycja C z Vimem jest bardzo pomocna, ale chciałbym uzyskać szerszą próbkę sugestii.

• Emacs / Vim / Eclipse / ... - Osobiście jestem użytkownikiem Emacsa. Jeśli okaże się, że sekwencje kontrolne męczą Twój mały palec, po prostu włącz tryb Viper. Emacs jest tak dobrze zintegrowany z Unixem, że bardzo łatwo można kontrolować wszystko z jednego miejsca. Vim również wykonuje tutaj dobrą robotę, ale uważam, że Elisp jest znacznie potężniejszym językiem rozszerzenia niż Vim Script. Można godzinami rozmawiać o wszystkich sposobach konfiguracji Emacsa dla rozwoju C. Wspomniano o trybie Flymake, który jest świetnym początkiem. Nie jestem zaznajomiony z Eclipse, nie uważam, że pozostawia wystarczająco dużo miejsca na ekranie na kod, ani nie podoba mi się, jak jest on rozdęty (użytkownicy Vima powiedzą to samo o Emacsie). Jestem również niesprawiedliwie stronniczy w stosunku do wszystkiego, co napisano w Javie, ze względów czysto estetycznych.

• Ctags - oznacza twoje funkcje C (lub wiele innych języków), dzięki czemu Vim, Emacs lub cokolwiek może zrobić trochę hiperłącza tekstowego w twoich plikach. Załóżmy, że wędrujesz i widzisz jakąś funkcję i drapiesz się po głowie, mówiąc: „Co ten robi ponownie? Nazywanie jest nieco niejasne”. Plink-plank-plunk, możesz przejść bezpośrednio do jego definicji.

• Cmake / Gnu-Autotools - Make jest świetny, ale w pewnym momencie musisz trochę streścić, aby Twój projekt mógł zbudować się na wszelkiego rodzaju systemach, dla których nie masz możliwości przetestowania. Jeśli potrzebujesz tylko ludzi do zbudowania twojego kodu na * nix, Autotools jest świetny, ale tak naprawdę powinieneś zapoznać się z Cmake. Zespół Cmake buduje kod w każdej możliwej konfiguracji i upewnia się, że nie musisz przechodzić przez ból głowy. Jeśli chcesz, aby Twój projekt był łatwo dostępny, kup inne, kluczowe jest jedno z tych narzędzi.

• Git / Mercurial / Subversion / ... - Możesz spędzić miesiące badając oprogramowanie do kontroli wersji, ale prawdopodobnie powinieneś po prostu skorzystać z Git. Jest solidny, rozproszony, @ $! #% I jądro Linuksa jest z nim śledzone. Jeśli jest wystarczająco dobry dla Linusa, musi być wystarczająco dobry dla ciebie. Słyszę też dobre rzeczy o Mercurial, najwyraźniej G ** gle używa ich, więc prawdopodobnie nie jest źle. Niektórzy ludzie lubią Subversion i CVS i tak dalej. Nie lubię ich, ponieważ są monolityczne, co dla mnie jest bardzo niewygodne i ograniczające.

• Stumpwm / wmii / XMonad / ... - W pewnym momencie zdasz sobie sprawę, że wszystko, co możesz zrobić, aby utrzymać płynność pracy, znacznie poprawi wydajność. Jednym z najlepszych sposobów, aby powstrzymać mózg przed zerwaniem z kontekstem jest przejście na kafelki, menedżery okien z KLAWIATURĄ. Jestem osobistym fanem StumpWM , Emacsa menedżerów okien. W pełni zaimplementowane w trakcie procesu Common Lisp, który można dostosowywać w czasie rzeczywistym, wszystko, co robisz powtarzalnie, może zostać przeniesione do funkcji i powiązane z poleceniami. Świetne rzeczy. Nie znam się zbytnio na żadnym z pozostałych, ale być może lepiej będzie, aby dalsze opracowywanie zostało zakończone na inny wątek. UŻYWAJ KLAWIATURY JAK DUŻO, JAK MOŻLIWE.

• GDB - Nie znam innych debuggerów, ale wydaje się, że jest to de facto standard.

• Valgrind - Nie wiem o niczym innym, że robi to, co robi to tak dobrze. Valgrind ma kluczowe znaczenie dla wszystkich tych nieznośnych profilowań / poszukiwań wycieków pamięci, które chcesz kontynuować. Po prostu nie możesz pisać kodu w malloc / calloc bez Valgrind.

Trwałem z Vimem przez pewien czas, warto znać podstawy VIM, ponieważ zawsze znajdziesz pudełko UNIX, które tylko to ma, ale wypróbowałem Emacsa i nie oglądałem się za siebie. Eclipse to „nowoczesna” alternatywa, mam wszystkie trzy w swoim systemie!

To bardzo osobiste preferencje, więc nie sądzę, że mogę zrobić więcej niż powiedzieć, czego używam. Mam Emacsa skonfigurowanego w trybie Flymake , który okresowo kompiluje plik, nad którym pracujesz, i analizuje dane wyjściowe kompilatora, aby dowiedzieć się, jakie błędy popełniłeś. Podświetla błędy / ostrzeżenia w buforze i wyświetla komunikat o błędzie kompilatora

Używam Kate (tekst) gcc / avr-gcc i make, z Git jako VC. W Pythonie robię głównie rzeczy osadzone po stronie c i komputer.

Jeśli tworzysz C w systemie Unix / Linux, absolutnie musisz używać Cscope, jeśli projekt ma znaczny rozmiar.

Cscope to narzędzie programistyczne do przeglądania kodu źródłowego - przejdź do foobardefinicji funkcji, znajdź wszystkie miejsca, do których fooodwołuje się zmienna , znajdź wszystkie pliki, w tym bar.hzmień wszystkie wystąpienia barna baz, itp.

Wspomniałeś także o Vimie w swoim poście ... oto tutorial na temat wspólnego używania Vima i Cscope.

Możesz użyć pakietu Netbeans C / C ++, który działa z G ++ / GCC:

netbeans.org/features/cpp

moim osobistym faworytem jest exVim . Ma wiele wtyczek vim, dzięki czemu jest bardzo łatwy w użyciu z dużą bazą kodu. Zajmuję około 1 dnia, aby poznać jego funkcje, ale będzie warto.

Edytuję C z Vimem w konsoli. Korzystam z plików makefile i posiadam wiele kompilatorów do testowania mojego kodu, w tym gcc, clang (LLVM) i icc. Inne rzeczy, które uważam za część mojego środowiska programistycznego: użycie grep, debuggerów i valgrind. Język skryptowy dla bardziej skomplikowanych kompilacji. Git do kontroli wersji.

Moim zdaniem ważniejsze niż to, czego używasz do edycji kodu, jest jego struktura. Jak to ułożyć, jest prawdopodobnie pytanie dotyczące przepełnienia stosu, ale, jak pytałeś, często mam osobny katalog dla kodu obiektowego, który nie jest przeznaczony do dystrybucji, i inny folder dla wynikowego binarnego (y | ies). Mam folder testowy, który zawiera więcej plików C, które używają całego kodu ogólnego, który piszę, i te wartości, wraz z końcowym plikiem projektu.

Możesz spróbować Motor IDE . Opiera się na klątwach, więc powinieneś czuć się jak w domu (tm).) Jest to również trochę smutne, ponieważ nie jest utrzymywane przez 5 lat, więc coś może zostać zepsute. Chociaż nadal - uważam, że warto spróbować.

Używam gedit z wbudowanym terminalem.