Dlaczego powinienem używać IDE? [Zamknięte]

W innym pytaniu Mark bardzo wysoko wypowiada się na temat IDE, mówiąc: „niektórzy ludzie wciąż po prostu nie wiedzą,„ dlaczego ”powinni użyć jednego ...”. Jako ktoś, kto używa vima do programowania i pracuje w środowisku, w którym większość / wszyscy moi koledzy używają vima lub emacsa do całej swojej pracy, jakie są zalety IDE? Dlaczego powinienem go użyć?

Jestem pewien, że jest to problem obciążony dla niektórych osób i nie jestem zainteresowany rozpoczęciem wojny z płomieniami, więc proszę odpowiedz tylko z powodów, dla których uważasz, że podejście oparte na IDE jest lepsze . Nie chcę wiedzieć, dlaczego nie powinienem używać IDE; Już go nie używam. Chcę powiedzieć „z drugiej strony ogrodzenia”, że tak powiem.

Jeśli uważasz, że IDE mogą być odpowiednie do niektórych rodzajów pracy, ale nie do innych, również jestem zainteresowany, aby dowiedzieć się, dlaczego.

To naprawdę zależy od używanego języka, ale w C # i Javie uważam, że IDE są korzystne dla:

• Szybka nawigacja do typu bez martwienia się o przestrzeń nazw, projekt itp
• Nawigowanie do członków, traktując ich jak hiperłącza
• Autouzupełnianie, gdy nie pamiętasz imion wszystkich członków na pamięć
• Automatyczne generowanie kodu
• Refaktoryzacja (ogromna)
• Organizuj import (automatyczne dodawanie odpowiednich importów w Javie, używając dyrektyw w C #)
• Ostrzeżenie podczas pisania (tzn. Niektóre błędy nawet nie wymagają cyklu kompilacji)
• Najechanie kursorem na coś, aby zobaczyć dokumenty
• Utrzymywanie widoku plików, błędów / ostrzeżeń / testów konsoli / jednostek itp. I kodu źródłowego na ekranie w przydatny sposób
• Łatwość uruchamiania testów jednostkowych z tego samego okna
• Zintegrowane debugowanie
• Zintegrowana kontrola źródła
• Nawigowanie do miejsca, w którym wystąpił błąd podczas kompilacji lub wyjątek w czasie wykonywania, bezpośrednio ze szczegółów błędu.
• Itp!

Wszystko to oszczędza czas. Są rzeczy, które mógłbym zrobić ręcznie, ale z większym bólem: wolałbym kodować.

Uzupełnianie kodu. Bardzo pomaga w eksplorowaniu kodu.

Krótka odpowiedź na pytanie, dlaczego używam IDE, to lenistwo.

Jestem leniwą duszą, która nie lubi robić rzeczy w trudny sposób, jeśli zamiast tego istnieje łatwy sposób. IDE ułatwiają życie i dlatego przyciągają nas leniwych ludzi.

Kiedy piszę kod, IDE automatycznie sprawdza poprawność kodu, mogę wyróżnić metodę i nacisnąć F1, aby uzyskać pomoc, kliknąć prawym przyciskiem myszy i wybrać „przejdź do definicji”, aby przejść bezpośrednio do miejsca, w którym został zdefiniowany. Nacisnąłem jeden przycisk, a aplikacja z automatycznie dołączonym debuggerem jest dla mnie uruchomiona. I tak lista jest długa. Wszystkie rzeczy, które programista robi na co dzień, znajdują się pod jednym dachem.

Nie ma potrzeby używania IDE. Po prostu trudniej jest nie pracować.

Nie sądzę, aby można było robić klasyczne „edytory tekstu i okno konsoli vs IDE”, gdy „edytor tekstu” jest naprawdę emacsem. Większość funkcji typowych dla IDE: s także w emacs. A może nawet tam powstały, a współczesne IDE to głównie ulepszenia / uproszczenia interfejsu.

Oznacza to, że w przypadku pierwotnego pytania odpowiedź nie jest tak jednoznaczna. Zależy to od tego, w jaki sposób ludzie w danej witrynie używają emacsa, jeśli używają go głównie jako edytora tekstu lub jeśli robią wszystko i używają niestandardowych skryptów, uczą się poleceń odpowiednich trybów, wiedzą o znakowaniu kodu i tak dalej.

Przychodzę na to pytanie z przeciwnego kierunku. Wychowałem się w programowaniu z bardzo małą liczbą postojów w Makefile + Emacs. Od mojego najwcześniejszego kompilatora na DOS, Microsoft Quick C, miałem IDE do automatyzacji rzeczy. Spędziłem wiele lat pracując w Visual C ++ 6.0, a kiedy ukończyłem Enterprise Java, pracowałem z Borlandem JBuilderem, a potem zdecydowałem się na Eclipse, który stał się dla mnie bardzo produktywny.

Podczas mojej początkowej samokształcenia, college'u, a teraz kariery zawodowej, doszedłem do wniosku, że wszelkie większe prace programistyczne wykonywane wyłącznie w ramach IDE stają się bezproduktywne. Mówię to, ponieważ większość IDE chce, abyś w nich pracowałosobliwy styl sterowania światem. Musisz kroić i kroić swoje projekty wzdłuż ich linii. Zarządzasz kompilacjami projektu za pomocą nieparzystych okien dialogowych. Większość IDE źle zarządza złożonymi zależnościami kompilacji między projektami, a zależności mogą być trudne do uzyskania w 100%. Byłem w sytuacjach, w których IDE nie tworzyłoby działającej wersji mojego kodu, chyba że wykonałem Wyczyść / Odbuduj wszystko. Wreszcie, rzadko istnieje czysty sposób na przeniesienie oprogramowania z obszaru programowania do innych środowisk, takich jak QA lub Production z IDE. Zasadniczo budowanie wszystkich jednostek wdrożeniowych jest zwykle bardzo kłopotliwe, lub masz jakieś niezręczne narzędzie, które sprzedawca IDE daje ci do pakowania. Ale znowu,

Nauczyłem się, że aby opracować program na dużą skalę z zespołem, możemy być najbardziej produktywni, jeśli opracujemy nasz kod przy użyciu IDE i wykonamy wszystkie nasze kompilacje przy użyciu ręcznie napisanych skryptów wiersza poleceń. (Lubimy programować Apache Ant for Java). Odkryliśmy, że uruchamianie naszych skryptów poza środowiskiem IDE to tylko festyn kliknięć lub koszmar automatyzacji dla skomplikowanych kompilacji, znacznie łatwiej (i mniej zakłócająco) Alt + Tab przejść do shell i uruchom tam skrypty.

Ręczne kompilacje wymagają od nas pominięcia niektórych subtelności współczesnego IDE, takich jak kompilacja w tle, ale to, co zyskujemy, jest znacznie bardziej krytyczne: czyste i łatwe kompilacje, które mogą funkcjonować w wielu środowiskach. „Kompilacja jednym kliknięciem”, o której mówią wszyscy zwinni faceci? Mamy to. Nasze skrypty budowania mogą być również wywoływane bezpośrednio przez systemy ciągłej integracji. Zarządzanie kompilacjami poprzez ciągłą integrację pozwala nam na bardziej formalne przygotowanie i migrację twoich wdrożeń kodu do różnych środowisk i daje nam niemal natychmiastową informację, gdy ktoś sprawdza zły kod, który psuje kompilację lub testy jednostkowe.

Prawdę mówiąc, odebranie mi roli kompilacji od IDE nie zaszkodziło nam tak bardzo. Narzędzia Intellisense i refaktoryzujące w Eclipse są nadal całkowicie przydatne i aktualne - kompilacja w tle służy po prostu do obsługi tych narzędzi. I osobliwe krojenie projektów w Eclipse służyło jako bardzo fajny sposób na mentalne rozbicie naszych zestawów problemów w sposób, który każdy może zrozumieć (choć trochę grzecznie na mój gust). Myślę, że jedną z najważniejszych rzeczy w Eclipse jest doskonała integracja SCM, dzięki czemu rozwój zespołu jest tak przyjemny. Używamy Subversion + Eclipse, a to było bardzo produktywne i bardzo łatwe do wyszkolenia naszych ludzi, aby byli ekspertami.

Będąc autorem odpowiedzi, którą wyróżniasz w swoim pytaniu i co prawda spóźniasz się na to pytanie, muszę powiedzieć, że spośród wielu wymienionych powodów produktywność profesjonalnego programisty jest jedną z najbardziej wysoko cenione umiejętności.

Mówiąc o wydajności, mam na myśli zdolność do wydajnego wykonywania pracy z możliwie najlepszymi wynikami. IDE umożliwiają to na wielu poziomach. Nie jestem ekspertem od Emacsa, ale wątpię, aby brakowało w nim cech głównych IDE.

Projektowanie, dokumentacja, śledzenie, opracowywanie, budowanie, analiza, wdrażanie i konserwacja, kluczowe etapy w aplikacji korporacyjnej, mogą być wykonane w środowisku IDE.

Dlaczego nie użyłbyś czegoś tak potężnego, gdybyś miał wybór?

Jako eksperyment zobowiązaj się do używania IDE przez, powiedzmy, 30 dni i zobacz, jak się czujesz. Chciałbym przeczytać twoje przemyślenia na temat tego doświadczenia.

Posiadanie IDE ma następujące zalety:

• Kompilacja odbywa się zwykle „w locie”, co oznacza koniec przełączania się do wiersza poleceń w celu kompilacji
• Debugowanie jest zintegrowane, a posiadanie go w środowisku IDE oznacza, że ​​debugger kroków faktycznie używa edytora lokalnego do wizualnego pokazania, który kod jest wykonywany
• IDE zazwyczaj mają większą wiedzę semantyczną na temat języka, w którym pracujesz, i mogą pokazywać możliwe problemy podczas pisania. Refaktoryzacja jest znacznie bardziej wydajna niż „wyszukiwanie zamień”.

Jest o wiele więcej, może powinieneś spróbować.

IDE to w zasadzie:

• Edytor z uzupełnieniem kodu, refaktoryzacją i dokumentacją
• Debuger
• Eksplorator systemu plików
• Klient SCMS
• Narzędzie do budowania

wszystko w jednym pakiecie.

Możesz mieć to wszystko (i kilka innych) za pomocą oddzielnych narzędzi lub po prostu świetnego programowalnego edytora i dodatkowych narzędzi, takich jak Emacs (również Vim, ale ma nieco mniej IDEbility IMO).

Jeśli zauważysz, że często przełączasz się między jednym narzędziem a drugim, które można zintegrować ze środowiskiem lub jeśli brakuje Ci niektórych umiejętności wymienionych tutaj (a dokładniej w innych postach), być może nadszedł czas, aby przejść do IDE (lub w celu poprawy IDEbility środowiska poprzez dodanie makr lub czegoś innego). Jeśli zbudowałeś „IDE” (w sensie, o którym wspomniałem powyżej) przy użyciu więcej niż jednego programu, nie ma potrzeby przechodzenia do rzeczywistego IDE.

Zaćmienie:

Podświetlanie kodu, kompilowanie w tle, wskazanie moich błędów podczas pracy.

Integracja z javadoc, sugerowanie nazw zmiennych za pomocą ctrl-Space.

Podczas kompilacji dostaję błędy. Mogę kliknąć dwukrotnie błąd, który wyświetli odpowiednią linię.

Naprawdę dobrze zintegrowany z JUnit, ctrl-F11 uruchamia test, mówi mi, że testy się nie powiodły. Jeśli w oknie wyjściowym występuje wyjątek, mogę dwukrotnie kliknąć linię i zabrać mnie do linii, która nie powiodła się. Nie tylko to, ale ctrl-F11 upewnia się, że wszystko jest skompilowane przed uruchomieniem testów (co oznacza, że ​​nigdy tego nie zapomnę).

Integracja z mrówką Jedno polecenie do zbudowania i wdrożenia aplikacji.

Integracja z debuggerami, w tym zdalne debugowanie serwerów WWW.

Narzędzia do refaktoryzacji FANTASTIC, szukają odniesień do części kodu. Pomaga mi poznać wpływ zmiany.

Podsumowując, sprawia, że ​​jestem bardziej produktywny.

Używam Emacsa jako mojego podstawowego środowiska zarówno do programowania, jak i poczty / wiadomości przez około 10 lat (1994-2004). Odkryłem moc IDE, kiedy zmusiłem się do nauki języka Java w 2004 roku i ku mojemu zaskoczeniu, że tak naprawdę lubiłem IDE ( IntelliJ IDEA ).

Nie będę przedstawiał konkretnych powodów, ponieważ wiele z nich zostało już tutaj wspomnianych - pamiętaj tylko, że różni ludzie kochają różne funkcje. Ja i mój kolega korzystaliśmy z tego samego IDE, oboje korzystaliśmy tylko z części dostępnych funkcji i nie lubiliśmy siebie nawzajem korzystania z IDE (ale oboje podobało nam się samo IDE).

Ale jest jedna zaleta IDE w porównaniu ze środowiskami Emacsa / Vima, na których chcę się skupić: spędzasz mniej czasu na instalowaniu / konfigurowaniu pożądanych funkcji.

Z Wing IDE (dla Pythona) jestem gotowy, aby zacząć rozwijać 15-20 minut po instalacji. Nie mam pojęcia, ile godzin potrzebowałbym na uruchomienie funkcji, z których korzystam w Emacs / Vim. :)

To zdecydowanie prowadzi do poprawy wydajności. Do tego stopnia, że ​​nawet koduję aplikacje Linuksa w Visual Studio na Vistę, a następnie używam wirtualnej maszyny Linux do ich zbudowania.

Nie musisz zapamiętywać wszystkich argumentów funkcji lub wywołania metody, gdy zaczniesz pisać, IDE pokaże ci, jakie argumenty są potrzebne. Dostajesz kreatorów do ustawiania właściwości projektu, opcji kompilatora itp. Możesz wyszukiwać rzeczy w całym projekcie zamiast tylko bieżącego dokumentu lub plików w folderze. Jeśli pojawi się błąd kompilatora, kliknij go dwukrotnie, aby przejść do linii obrażeń.

Integracja narzędzi, takich jak edytory modeli, łączenie się z zewnętrznymi bazami danych i przeglądanie ich, zarządzanie kolekcjami „fragmentów kodu”, narzędzi do modelowania GUI itp. Wszystkie te rzeczy można mieć osobno, ale posiadanie ich wszystkich w tym samym środowisku programistycznym oszczędza wiele czas i sprawia, że ​​proces rozwoju przebiega bardziej wydajnie.

Mogą istnieć różne powody dla różnych osób. Dla mnie to są zalety.

1. Zapewnia zintegrowany charakter projektu. Na przykład będę mieć wszystkie powiązane pliki projektów w jednym widoku.
2. Zapewnia zwiększoną produktywność kodu jak
   1. Podświetlanie składni
   2. Odwoływanie się do zespołów
   3. Intellisense
   4. Scentralizowany widok bazy danych i powiązanych plików interfejsu użytkownika.
   5. Funkcje debugowania

Koniec dnia pomaga mi pisać szybciej, niż mogę to zrobić w notatniku lub wordpadzie. To całkiem dobry powód, dla którego wolę IDE.

IDE może być „lepszym” wyborem w zależności od tego, co programista chce osiągnąć.

Edytor tekstowy może być „lepszy”, ponieważ IDE są zazwyczaj nastawione na jeden (lub niewielki wybór) języków.

Jeśli programista spędza większość czasu w jednym języku lub „klastrze” powiązanych języków (takich jak C # i T-SQL), w jednym systemie operacyjnym, wówczas narzędzia do projektowania GUI, debugowania, inteligencji, refaktoryzacji itp. Oferowane przez dobre IDE może być bardzo przekonujące. Jeśli, na przykład, spędzasz większość czasu pracując w VB.NET, czasem z odrobiną T-SQL, w środowisku Windows, byłoby głupio nie patrzeć na Visual Studio lub porównywalne IDE .

Nie mam uprzedzeń do tych, którzy wolą IDE lub edytory tekstu, oba mogą być bardzo produktywne i przydatne, jeśli dobrze się nauczysz !

Myślę, że ma to głównie związek z zakresem świadomości dewelopera. IDE zapewnia makroskopowe spojrzenie na kontekst pracy programisty. Możesz jednocześnie zobaczyć hierarchie klas, zasoby referencyjne, schematy bazy danych, odwołania do pomocy SDK itp. A przy tak wielu rzeczach, na które wpływają i wpływają twoje naciśnięcia klawiszy, a także rosnąca liczba architektur i skrzyżowań architektonicznych, coraz trudniej jest pracować wyłącznie z jednej wyspy kodu na raz.

OTOH, „tylko ja i vim i strony man” daje mi znacznie szczuplejszy mikroskopijny - ale intensywny i precyzyjny - widok mojej pracy. Jest to w porządku, jeśli mam dobrze zaprojektowaną, podzieloną na partie, rzadko sprzężoną, bardzo spójną bazę kodu zbudowaną w jednym języku z jednym zestawem bibliotek statycznych do pracy - nie jest to typowa sytuacja, zwłaszcza gdy rozmiary zespołów programistów rosną i zmieniają strukturę kodu na przestrzeni czasu, odległości i osobistych preferencji.

Obecnie pracuję nad projektami w Flex i .NET. Jedną z fajniejszych rzeczy w Flex jest to, jak mało jest różnych sposobów na osiągnięcie standardowej rzeczy - pobieranie danych z bazy danych, otwieranie / zamykanie / czytanie / zapisywanie pliku itp. (Jednak używam Flex Builder / Eclipse IDE - typowy przykład wagi ciężkiej, jak VS, ponieważ wciąż uczę się podstaw i potrzebuję kół treningowych. Spodziewam się ewolucji, aby vim, gdy będę pewien swoich wzorów.) W tym widoku mogę zrobić to, co Muszę robić to zawodowo, znając kilka naprawdę dobrze rzeczy.

OTOH, nie wyobrażam sobie, aby dojść do tego punktu z .NET, ponieważ widok, który powinienem utrzymać, ciągle się rozwija i zmienia. Istnieje znacznie mniej integralności koncepcyjnej, a przez kilku programistów projektu w ciągu kilku miesięcy, znacznie mniej spójności - ale IDE to popiera, może to zachęca. Tak więc programista naprawdę musi (i może łatwiej) wiedzieć o wiele więcej rzeczy odpowiednio. Ma to również tę zaletę, że pomaga im odpowiedzieć (a nawet zrozumieć) o wiele wyższy odsetek pytań na StackOverflow. To znaczy, że możemy mieć głębszy stos wiedzy. I możemy odpowiedzieć na szerszą gamę reklam, które były potrzebne.

W obu kierunkach może być za daleko. Może z lunetą „tylko dla redaktora” jest to jak „jeśli masz tylko młotek, wszystko wygląda jak gwóźdź”. Dzięki podejściu IDE, do wszystkiego, co chcesz połączyć razem, masz szeroki wybór elementów złącznych i powiązanych zakresów narzędzi do wyboru - nals / młoty, wkręty / wkrętaki, śruby / klucze, kleje / pistolety do kleju / zaciski, magnesy , i tak dalej i dalej - wszystko na wyciągnięcie ręki (z pomocą kreatora, który pomoże Ci zacząć).

Nie myśl o tym jako o wyłączności. Użyj IDE dla korzyści, które zapewnia, i przełącz się na vim / preferowany edytor tekstu, gdy potrzebujesz poważnego skupienia.

Uważam, że IDE jest lepsze do refaktoryzacji, przeglądania i debugowania oraz do zastanawiania się, co robić. Małe rzeczy są następnie robione bezpośrednio w IDE, duże rzeczy, które odwracam, aby vim, aby dokończyć zadanie.

Oprócz innych odpowiedzi, uwielbiam łączyć rozwijającą się moc IDE z mocą edytorską Vima za pomocą czegoś takiego jak ViPlugin dla Eclipse .

IntelliSense , zintegrowany debugger i bezpośrednie okno zwiększają produktywność ( Visual Studio 2008 ). Mając wszystko na wyciągnięcie ręki, mogę pisać ogromną większość ogromnego projektu w głowie. Microsoft może upuszczać piłkę w swoich systemach operacyjnych, ale Visual Studio jest jednym z najlepszych produktów, jakie kiedykolwiek opracowano.

Nie rozumiem o co pytasz. Pytasz „Powinienem użyć IDE zamiast ...”, ale nie rozumiem, co to jest alternatywa - Vim i Emacs spełniają wiele funkcji, które daje ci IDE. Jedynym aspektem, z którym nie radzą sobie, że większe IDE może być takie, jak projektanci interfejsu użytkownika. Następnie twoje pytanie sprowadza się do „tego, czego IDE powinienem użyć” wraz z argumentami, które należy przedstawić dla prostszej dziedziny Vima i Emacsa.

Dla mnie IDE jest lepsze, ponieważ pozwala na szybszą nawigację w kodzie, co jest ważne, jeśli masz coś do zaimplementowania. Zakładając, że nie używasz IDE, dotarcie do celu zajmuje więcej czasu. Twoje myśli mogą być częściej przerywane. Oznacza to, że należy nacisnąć więcej kliknięć / więcej klawiszy. Trzeba bardziej skoncentrować się na myśli, jak wdrażać różne rzeczy. Oczywiście możesz też zapisać rzeczy, ale wtedy musisz przeskakiwać między projektem a implementacją. Również projektant GUI robi dużą różnicę. Jeśli zrobisz to ręcznie, może to potrwać dłużej.

IDE oparte na GUI, takie jak Visual Studio i Eclipse, mają kilka zalet w porównaniu z IDE tekstowymi, takimi jak Emacs lub vim, ze względu na ich możliwości wyświetlania:

• Podgląd WYSIWYG i edycja na żywo dla projektu GUI
• Wydajne edytory właściwości (np. Wybór koloru za pomocą palety GUI, w tym pozycjonowanie punktów zatrzymania gradientu itp.)
• Graficzne przedstawienie konturów kodu, powiązań plików itp
• Bardziej wydajne wykorzystanie nieruchomości ekranowych do wyświetlania punktów przerwania, zakładek, błędów itp
• Lepsza obsługa przeciągania i upuszczania w systemie operacyjnym i innych aplikacjach
• Zintegrowana edycja rysunków, obrazów, modeli 3D itp
• Wyświetlanie i edycja modeli baz danych

Zasadniczo za pomocą interfejsu IDE opartego na graficznym interfejsie użytkownika można uzyskać na ekranie bardziej przydatne informacje, a także przeglądać / edytować graficzne części aplikacji tak łatwo, jak fragmenty tekstu.

Jedną z najfajniejszych rzeczy dla programistów jest edytowanie metody, która oblicza niektóre dane, i wyświetlanie wyników na żywo kodu wyświetlanego graficznie w innym oknie, tak jak użytkownik zobaczy to po uruchomieniu aplikacji. Teraz to edycja WYSIWYG!

Tekstowe IDE, takie jak Emacs i vim, mogą dodawać funkcje takie jak uzupełnianie kodu i refaktoryzacja w czasie, więc na dłuższą metę ich głównym ograniczeniem jest oparty na tekście model wyświetlania.

Prawie wyłącznie używam Vima (prawie dlatego, że próbuję teraz nauczyć się emacsa) do wszystkich moich prac programistycznych. Myślę, że sama intuicyjność (oczywiście z GUI) jest głównym powodem, dla którego ludzie lubią używać IDE. Będąc intuicyjnym, nie jest wymagane żadne narzędzie do nauki. Im mniejszy narzut związany z nauką, tym więcej mogą wykonać pracę.

IDE pozwala na łatwe pracować szybciej i bardziej ... Zauważyłem, spędziłem dużo czasu przechodząc w kodzie w prosty edytor tekstu ...

W dobrym IDE czas ten skraca się, jeśli IDE obsługuje przeskakiwanie do funkcji, do poprzedniej pozycji edycji, do zmiennych ... Również dobre IDE skraca czas eksperymentowania z różnymi funkcjami językowymi i projektami, jako czas rozruchu może być mały.

Kilka powodów, dla których mogę wymyślić użycie IDE:

• Zintegrowana pomoc jest ulubionym.
• Wbudowany refaktor z podglądem programu Visual Studio
• IntelliSense , podświetlanie składni, łatwość nawigacji w dużych projektach, zintegrowane debugowanie itp. (Chociaż wiem, że dzięki dodatkom możesz prawdopodobnie dostać dużo tego w Emacsie i Vimie ).
• Myślę też, że IDE mają obecnie szerszą bazę użytkowników i prawdopodobnie więcej osób opracowuje dla nich dodatki, ale mogę się mylić.

I szczerze mówiąc, podoba mi się moja mysz. Kiedy korzystam z edytorów opartych na czystym tekście, robi się samotny.

Oszczędza czas na rozwój
Ułatwia życie, zapewniając takie funkcje, jak zintegrowane debugowanie, intellisense.

Jest ich wiele, ale zalecam użycie jednego, są bardziej niż oczywiste.

Nie jestem pewien, czy istnieje wyraźna linia podziału między edytorem tekstu a IDE. Na jednym końcu skali masz Notatnik, a na drugim najlepsze nowoczesne IDE, ale między nimi jest wiele rzeczy. Większość edytorów tekstu ma podświetlanie składni; edytory skierowane do programistów często mają różne inne funkcje, takie jak łatwa nawigacja kodu i automatyczne uzupełnianie. Emacs pozwala nawet zintegrować debugger. IDE jeszcze dziesięć lat temu miały znacznie mniej funkcji pomagających programistom, niż można by się spodziewać po poważnym edytorze tekstu.

Moim głównym powodem, aby użyć jednego, jest przekroczenie 100 plików.

Chociaż ctagi mogą wykonać tę pracę, niektóre IDE mają całkiem niezły sposób na szybkie i łatwe poruszanie się po plikach.

Oszczędza czas, gdy masz dużo pracy.

Dla mnie to tylko wersja GUI wszystkiego, co zrobiliśmy w starych dobrych czasach terminalu. Zawsze będę się zgadzać, że IDE nie są bardzo lepsze, ponieważ ukrywają wiele rzeczy, szczególnie dotyczących łączenia, ale w niektórych przypadkach mają znaczącą przewagę, na przykład w przypadku niektórych platform programistycznych, takich jak Qt.

Niektóre wizualne IDE innych wydają się nawet analizować kod podczas pisania i wykrywa błędy przed kompilacją: wydaje się logiczne, że tylko IDE może ściśle współpracować z kompilatorem, aby natychmiast wykryć problem w typowanym źródle.

Moja dzika odpowiedź, że wojna z płomieniami w IDE / Command istnieje, jest po prostu dlatego, że budynek wykonywalny C / C ++ nie jest dobrze obsługiwany ze standardowego punktu widzenia, w przeciwieństwie do języka D; każda platforma obsługuje kompilację / linkowanie / etc na swój własny sposób, więc aby było mniej bałaganu, tworzą IDE.

Z twojego punktu widzenia korzystanie z wiersza poleceń może być prostsze, gdyby był tylko jeden kompilator ze standardowymi opcjami, byłoby to łatwe, ale prawda jest taka, że ​​C / C ++ jest elastyczny, więc w końcu cała platforma zrób to po swojemu, dlatego IDE nie marnuje się na wyjaśnianie, jak to zrobić.

Jeśli możesz dowiedzieć się, jak plik wykonywalny mówi do jądra lub jeśli wiesz coś o projektowaniu kompilatora, być może istnieje sposób pracy z odpowiednim wierszem poleceń, ale wątpię, że tak.

Microsoft czy Apple, bez względu na to, jakie byłyby zło, musiałyby zaproponować prosty sposób na zbudowanie aplikacji bez wprowadzania szczegółów, a ponieważ tworzenie aplikacji zależy bezpośrednio od architektury systemu operacyjnego, raczej nie będzie ona „standardowa”, ponieważ wiersz polecenia to.

Mówiąc prosto, duże i złożone aplikacje, w których nie chcesz zagłębiać się w to, co robi -> IDE, małe oprogramowanie lub proste projektowanie oprogramowania systemowego -> wiersz poleceń. Oprócz oczywiście tych fajnych bibliotek, które zawierają plik Makefile, ale to już inna historia.

Myślę też, że IDE są używane, gdy dostarczona aplikacja ma coś wspólnego z, jak na ironię, GUI lub czymś, co ma interfejs lub jest bezpośrednio związana z systemem operacyjnym, więc znowu, jest to również dla osób, które będą korzystać z interfejsu użytkownika / GUI bez wiedzy jak to działa, a ludzie, którzy będą programować systemy, nie będą potrzebować wszystkiego.

IDE to po prostu nowoczesne gówno, ale myślę, że za 100 lat linia poleceń będzie nadal istnieć.

Lubię IDE, ponieważ daje ono wiele funkcji na wyciągnięcie ręki. Edycja / Kompilacja / widoczność plików w projekcie to wszystko, co cenię w IDE. Teraz używam Visual Studio, ale w poprzednim życiu korzystałem ze SlickEdit i stwierdziłem, że usprawniło to mój proces rozwoju, niż kiedy go nie używałem.

Przy podejmowaniu decyzji, czy użyć IDE, czy nie, należy wziąć pod uwagę tylko jedną kwestię: czy to zwiększa wydajność, czy nie.

Krótkie pytanie, tak krótka odpowiedź :)

Zależy to w dużej mierze od tego, co robisz i w jakim języku to robisz. Osobiście zwykle nie używam IDE (lub „moje IDE składa się z 3 xterms z uruchomionym vimem, jednego z klientem bazy danych i jednego z bash prompt lub tailing logs, w zależności od tego, jak szeroko definiujesz „IDE”) dla większości mojej pracy, ale gdybym odkrył, że opracowuję natywny interfejs GUI, to sięgnę po IDE odpowiednie dla języka w natychmiast - IMO, IDE i edytowanie formularzy graficznych są dla siebie jednoznaczne.