On giving up and trying an IDE

I dislike IDEs, at least I tell myself and others that. A 200 line long .vimrc gives a lot more street cred than clicking on a colored icon and selecting some profile that mostly fits ones workflow. So does typing out breakpoints in GDB compared to just clicking left of a line. Despite those very good reasons I went ahead and gave Goland and CLion, two JetBrains products for Go and C/C++ respectively, a chance. The following details my experiences with a kind of software I never seen much use for, the problems I ran into, and how it changed my workflow.

Installation and Configuration

A picture of my IDE wouldn’t do much good, they all look the same. So here’s a baby seal.
Source: Ville Miettinen from Helsinki, Finland


First step is always the installation. With JetBrains products being mostly proprietary, there are no repositories for easy installation and updating. But for the first time I had something to put in /opt. When going through the initial configuration wizard one plugin caught my eye: “IdeaVim”. Of course I decided to install and activate said plugin but quickly had to realize it does not work the same simply running vim in a window.
This “Vim emulation plug-in for IDEs based on the IntelliJ platform” sadly does for one not offer the full Vim experience and the key bindings often clash with those of the IDE. Further I started getting bothered by having to manage the Vim modes when wanting to write code.
I sometimes miss the ability to easily edit and move text the way Vim allows, the time I spend using the mouse to mark and copy text using the mouse are seconds of my life wasted I’ll never get back!
Except for the underlying compiler and language specific things both IDEs work the same, identical layout, window options, and most plugins are shared, so I won’t talk about the tool chain too much. But it needs to be said that Goland just works, possibly because building a Go project seems simpler than a C++ one. Getting CLion to work with CMake is tiresome, the only way to edit directives is by giving them to the command like you would on the shell. This would not bother me as much if CMake didn’t already have a great GUI.

Coding and Debugging

Yet I wouldn’t be still using those programs if there weren’t upsides. The biggest being the overview over the whole project, easily finding function declarations and splitting windows as needed. These are things Vim can be made to do, but it does not work as seamless as it does in the IntelliJ world. It made me realize how little time is spent the actual typing of code, most of it is reading code, drawing things and staring at a prototype until your eyes bleed confusion (sometimes code is not well commented). The debuggers, again specifically the one of Goland, work great! Sometimes I have to talk to GDB directly since there are many functions but too few buttons, but the typical case of setting a breakpoint and stepping through to find some misplaced condition is simple and easy.

Alright, here it is.


There are a few features I have not found a use for yet e.g. code generators and I still manage my git repositories from the shell. The automatic formatting is cool, again especially in Go where there is one standard and one tool for it. Other than that I run into a few bugs now and then, one that proved to be quite a hassle is the search/search and replace sometimes killing my entire window manager. Were it free software, there’d be a bug report. But for now I work around it. Maybe I’ll drop CLion but I doubt I’ll be writing any Go code in Vim anytime soon.
If you think you have found the perfect IDE or just want to share Vim tips, meet me at the OSMC in November!

Neue IDE: CLion

Alle paar Monate wage ich einen neuen Versuch, eine bessere Entwicklungsumgebung als vim/make zu finden. Diesmal habe ich mir CLion angeschaut:
clion
Einige interessante Features, die CLion vor allem für die Entwicklung mit Icinga 2 interessant machen sind z.B.:

  • Integrierte Unterstützung für GDB als Debugger
  • CLion verwendet direkt CMake als Buildsystem (was wir zufälligerweise auch für Icinga 2 verwenden)
  • Intelligente Auto-Completion

Die nächsten Wochen werden dann wohl zeigen, ob CLion wirklich taugt oder ich bereits nach kürzester Zeit wieder auf vim zurückfalle.

Klein und gut – Komodo Edit

Ungefähr alle zwei Monate begebe ich mich auf die Suche nach einem neuen Texteditor. Zu schwerfällig sind manche IDEs – starten dauert lange oder man kann einzelne Dateien gar nicht erst editieren wenn man sich nicht in einem Projektkontext befindet. Meistens ist die Suche dann aber schnell beendet. Entweder reicht mir das Featureset nicht aus oder er ist schon wieder mit zu viel Firlefanz überladen. Nicht so mit Komodo Edit, einem freien Editor der Firma ActiveState (Die mit dem Perl unter Windows), welcher frei erhältlich ist.
Komodo Edit ist eine abgespeckte Version der Komodo IDE, beinhaltet aber alles wichtige für den ambitionierten Schreiberling. Ein kleiner Abriss, was mitgefällt:

  • Guter Editor, Syntax Highlighting, Code Folding, Call Tips, Code Completion, Matching Braces
  • Projekt Support – oder eben auch nicht
  • Unterstützt automatisch die wichtigsten Script Sprachen auch ohne Datenerweiterung
  • FastOpen: Öffnen von Dateien anhand von Namensfragmenten
  • Gutes Design und ergonomische Darstellung von Text und Elementen

Das System basiert auf dem von Mozilla entwickelten XML Userinterface (XUL) und startet erträglich schnell. Dank dem mitgelieferten Installer integriert er sich nahtlos in die bekanntesten Linuxdistros und ersetzt für mich die systeminternen Texteditoren, z.B. gedit. Perfekt finde ich ihn für Perl. Die meisten IDEs kommen mit dem Code und der redundanten Schreibweise eh nicht sonderlich gut zurecht. Der kleine Drache ist nicht perfekt, erkennt aber zuverlässig die wichtigsten Dinge um nicht auf Nase zu fallen. Ansonsten funktioniert er auf jeder erdenklichen Plattform von Windows bis Linux und natürlich auch für alle anderen Randgruppen!
Genug der Ode. Mein Fazit: Einfach mal testen!

Marius Hein
Marius Hein
Head of Development

Marius Hein ist schon seit 2003 bei NETWAYS. Er hat hier seine Ausbildung zum Fachinformatiker absolviert, dann als Application Developer gearbeitet und ist nun Leiter der Softwareentwicklung. Ausserdem ist er Mitglied im Icinga Team und verantwortet dort das Icinga Web.

Die Suche nach dem heiligen Gral

Alle Monate aufs Neue mache ich mich auf die Suche nach einer neuen, tolleren IDE, die hoffentlich alle meine Probleme lösen kann. Bisher jedoch leider vergeblich, obwohl – wie ich finde – meine Anforderungen doch eigentlich gar nicht so unrealistisch sind:

  • Syntax-Highlighting und Code-Completion für C/C++
  • Plattformunabhängigkeit: Sollte unter Linux und Windows verwendbar sein
  • Unterstützung für autoconf/automake wäre ganz nett
  • Integration von GDB inkl. Remote Debugging
  • Ich möchte gerne mehr Zeit damit verbringen, Code zu schreiben, als die IDE zu konfigurieren oder gegen deren Macken anzukämpfen

Und so fange ich an, diverse IDEs zu testen – in der Hoffnung, dass die jeweils aktuelle Version inzwischen halbwegs erträglich ist.
Zunächst einmal Eclipse CDT und NetBeans. Plattformunabhängig sind sie ja, das muss man den Java-IDEs lassen. Aber da hört es für mich leider auch schon wieder auf. Mal eben Eclipse starten, um eine Datei zu bearbeiten?: Fehlanzeige – die IDE startet so träge, dass es mich wundert, dass die Entwickler nicht gleich noch einen Lade-Screen für den Splash-Screen implementiert haben.
Auch das Indexing für die Code Completion lässt sich bei beiden IDEs gerne mal etwas mehr Zeit. Im Allgemeinen scheinen sowieso viele Hintergrund-Tasks zu laufen, die meine CPU zum Kochen bringen wollen. – Nein, danke.
Der Vollständigkeit halber will ich Visual Studio erwähnen. Was die Editor-Features und v.a. IntelliSense angeht, ist Visual Studio wirklich absolute Spitze. Leider ist es für mich nur eingeschränkt verwendbar, da ich meine Software primär unter Linux teste. Und jedes Mal meinen Quellcode zwischen einer Windows-VM und meiner Linux-Workstation hin- und herzukopieren ist mir zu aufwändig.
Nach weiteren Versuchen mit Anjuta, KDevelop, Code::Blocks und diversen anderen unbekannteren IDEs bin ich dann wieder bei meinen “klassischen” Tools gelandet: GNOME Terminal bzw. PuTTY unter Windows, vim und gdb (mit cgdb-Frontend). Nunja, zumindest habe ich wohl nun wieder für einige Monate keinen Bedarf mehr, die ideale IDE zu finden.