Es ist halt viel Gewöhnungssache. Grundsätzlich kommt man mit jeder IDE für die meisten Hobby-Projekte zurecht. Sie haben ggf. etwas andere Konzepte im Detail, aber jede tut es. Man ist am Anfang gut beraten, auf die zu setzen, für die man den besten Support hat, wobei man am ehesten Leute fragen kann, wenn was klemmt. So hat jede IDE andere Shortcuts, etc. Zudem sind die Standard-Formatter in jeder IDE auch etwas unterschiedlich, so dass es hilfreich ist, wenn man gemeinsam an einem Projekt arbeitet, dass alle die gleiche IDE verwenden.
Interessant wird es dann eher, wenn man in den professionelleren/Enterprise Bereich geht. Da kann es je nach Firma sein, dass eine IDE gesetzt ist - daher ist es auch nicht schlecht mal über den Tellerrand zu schauen. Auch treten dann Stärken & Schwächen einzelner IDEs deutlich stärker raus. Aber auch da kommt man mit jeder IDE noch zu rande.
Pff - Spalter!
Mal ein paar Worte zu Eclipse, weil
@mihe7 mich da erwähnt hat
🙂
Ich bin Eclipser Nutzer seit Ewigkeit - ich glaub seit Eclipse aus den Kinderschuhen entwachsen und lange bevor es eine RCP wurde. Dementsprechend bin ich dran gewöhnt wie man damit arbeitet und wie man mit Problemen umgeht, weswegen es auch aktuell Privat noch die IDE meiner Wahl ist. Insbesondere für den Kram den ich Privat mache hab ich keine Probleme.
Auf der Arbeit bin ich an Eclipse gebunden, weil wir in der Firma ein Eclipse Plugin haben zur Modellierung & Code-Generierung. Dementsprechend kommen wir da (noch) nicht weg. Aber - und da muss ich
@mihe7 leider Recht geben - Eclipse hat ein paar Unschönheiten, wo ich auch regelmäßig fluche. Das eine ist das Zusammenspiel mit JavaEE-Servern - das Deployment aus Eclipse heraus macht immer wieder mal Probleme, dass eine persistence.xml nicht aktualisiert wird oder doppelte Beans rumliegen, so dass ich immer über die Kommandozeile baue & deploye. Auch das virtuelle FileSystem von Eclipse, wenn man einen Branch auf der Konsole wechselt führt immer wieder zu seltsamen Effekten, auch im Zusammenspiel mit der Code-Generierung. Da läuft dann die Code-Generierung auf einem Zwischenstand zwischen alten & neuen Branch, was einfach Murks produziert. Ist mit einem git reset --hard schnell behoben, nervt aber.