Was ich von einem Editor als Programmierer erwarte

In der Regel arbeite ich mit nur einem oder maximal zwei Fenstern für den Code - und das auch nur, wenn ich mehrere Code-Stellen parallel sehen muss. Dazu brauche ich ein Fenster, in dem ich den Projektbaum sehe und auf- und zuklappen kann. Ideal wäre noch ein Fenster, das mir einen Überblick über die einzelnen Funktionen und Klassen in der aktuell angezeigten Datei gibt, um schnell innerhalb der Datei navigieren zu können. Eine flexible Fensterverwaltung ist für mich essenziell, ohne dass ich mich in zu vielen Fenstern verliere.

Unter Navigation verstehe ich alles, was dafür sorgt, dass ich schnell an den Punkt im Code komme, an den ich gerade möchte, und dass ich keinen Code sehe, der mich gerade nicht interessiert. Daher betrachte ich auch Code-Folding für mich als Teil der Navigation.

Ich möchte im Codebaum auf und ab springen können, sowie ebenenweise navigieren. Wenn ich in einer Funktion bin, möchte ich mit einem Tastendruck am Klassenkopf sein und diese Klasse einklappen können, wenn ich mich um eine andere Klasse kümmern möchte. Sprünge an Dateianfang und Dateiende sollten selbstverständlich sein. Schön wären Sprünge an die Stelle, an der eine Variable deklariert wird. Oder im Falle von Programmiersprachen mit Header-Dateien ein Hin- und Herspringen zwischen der Datei und ihrer Header-Datei oder auch zwischen der Datei und der dazugehörigen Testdatei - weil man ja doch ab und zu an Code arbeitet und parallel an den dazugehörigen Tests.

Zusätzlich möchte ich im Dateibaum navigieren können, entweder indem ich mir die Datei direkt aufrufe oder durch sinnvolle Abkürzungen in passende Ordner springe.

Beim Editieren geht es mir um Kleinigkeiten, die den Arbeitsfluss erleichtern: Beim Schreiben einer öffnenden Klammer soll automatisch eine schließende gesetzt werden. Verschiedene Klammer-Ebenen sollten farblich unterschiedlich angezeigt werden, damit ich sie sofort optisch unterscheiden kann. Ich bin der Typ, der Tabs beim Editieren nutzt - aber Tabs im Code sind für andere einfach hässlich. Daher ist es wichtig, dass ich Tabs beim Editieren verwenden kann, diese aber beim Speichern automatisch in Leerzeichen umgewandelt werden. Besonders in Sprachen wie Python, wo die Einrückung eine semantische Bedeutung hat, muss das sauber funktionieren.

Autocompletion ist ein weiteres spannendes Thema. Was ich bisher immer benutzt habe, ist so etwas wie IntelliSense: Sobald ich den Beginn einer bereits benutzten Variable oder Funktion tippe, wird mir die vollständige Bezeichnung vorgeschlagen. Wichtig ist dabei, weder zu viele Möglichkeiten zur Auswahl zu haben, noch wichtige Dinge nicht auswählen zu können. Eine präzise und kontextbezogene Autocompletion unterstützt mich, ohne mich zu überfordern.

Hier lebe ich immer noch den Traum von einer universellen Snippet-Sprache. Ich möchte Textblöcke einfügen können, in denen ich Variablen einsetze, ähnlich wie es Cookie Cutter erlaubt. Außerdem möchte ich beim Schreiben durch eine zwei- oder dreibuchstabenkombination kurze Textschnipsel wie einen If-Block oder einen Select-Case-Block in Visual Basic oder vergleichbare Strukturen in anderen Sprachen erstellen können. Am liebsten hätten all diese Blöcke, die das Gleiche in verschiedenen Sprachen tun, die gleiche Abkürzung. Deswegen nenne ich das Universal Snippets . Diese Flexibilität würde mir helfen, meine Arbeit zu beschleunigen, ohne mich um Sprachspezifika kümmern zu müssen.

Der Probelauf ist eigentlich ganz simpel: Ich möchte das Programm aus meinem Editor heraus kompilieren und starten können - und damit herumspielen. Je nach Programmiersprache sind dazu noch einige Zwischenschritte nötig. Diese sollen unter der Haube automatisch erfolgen, damit ich mich auf das Wesentliche konzentrieren kann: das Testen und Ausprobieren meines Codes.

Beim Debugging habe ich schon so ziemlich alles erlebt. Die allerspartanischste Art zu debuggen ist es wohl, irgendwo im Programmcode ein Beep einzufügen und zu schauen, ob es beim Programmlauf irgendwo piept. Konsolenausgaben, die ich direkt in den Code schreibe, sind nur ein wenig komfortabler. Aber was ich eigentlich möchte, ist es, sinnvoll im Code steppen zu können: Step In, Step Over, Step Out . Dabei möchte ich mir den Status diverser Variablen anzeigen lassen können.

Breakpoints zu setzen ist für mich essenziell - und zwar nicht nur an festen Stellen im Code, sondern auch abhängig von Ausdrücken. Zum Beispiel: Ein Breakpoint, wenn ein Ausdruck wahr ist, oder ein Breakpoint, wenn sich der Wert einer Variablen ändert. Ich möchte also nicht stoppen, wenn der Wert der Variablen a gleich 7 ist, sondern immer dann, wenn er sich vom aktuellen Wert in irgendeinen anderen Wert verändert. Das ist etwas, das mein uraltes Visual Basic 6 konnte, aber in vielen modernen Entwicklungsumgebungen fehlt.

Ebenso wichtig ist für mich, dass ich Fehlermeldungen des Compilers oder Parsers direkt sehe und durch einen Klick in die entsprechende Datei und Zeile springen kann.

Beim Testen kommen ja mittlerweile fast alle modernen Programmiersprachen mit einem integrierten Testframework daher. Und ich finde, das sollte auch genutzt werden. Ich möchte diese Testframeworks direkt aus dem Editor heraus nutzen können, damit ich meine Tests schnell und effizient ausführen kann. Dabei wäre es schön, wenn ich nicht jedes Mal die gesamte Testsuite durchlaufen muss, sondern auch nur die aktuelle Datei und die dazugehörigen Tests ausführen könnte. So kann ich gezielt und ohne unnötigen Zeitverlust arbeiten.

Für die Git-Integration gibt es Magit - muss ich mehr sagen? Das Ding funktioniert einfach und ist rund. Einzig beim Diffing bin ich noch ein bisschen verwöhnt: Da nutze ich, egal auf welcher Maschine, die Software Beyond Compare von Scooter Software. Für mich das ultimative Diffing-Tool. Wenn ich etwas Vergleichbares in Emacs herstellen könnte, wäre das super. Das ist mir bisher aber noch nicht gelungen.

Eine coole Funktion der Git-Integration wäre, wenn ich jedes Mal beim Speichern einen internen Git-Commit im Entwicklungsbranch erzeuge, in dem ich gerade arbeite. Wenn ich dann 27 Mal gesichert habe und der Tag zu Ende ist, und ich beschließe, diesen Stand zu behalten, kann ich diese Commits squashen und habe dann einen einzigen sauberen Commit.

Beim Deployment ist es ja so: Manchmal ist es Teil der Git-Integration durch irgendwelche Hooks wie bei GitHub. Oder es muss manuell gemacht werden. Wenn ich es manuell machen sollte, dann würde ich gerne Targets auswählen können. Und das Ganze sollte eng mit Git verzahnt sein.

Refactoring habe ich hier nochmal getrennt aufgeführt. Obwohl ich es manchmal bereits direkt während des Code-Editierens mache, ist es sinnvoller, sich in regelmäßigen Abständen hinzusetzen und nichts anderes als Refactoring zu machen. Wenn ich dabei strukturell etwas umbauen möchte, dann ist das meiste Cut, Paste und Neuschreiben. Was mir dabei aber schon ungeheuer helfen würde, ist, wenn ich mir sicher sein könnte, dass ich Variablen- oder Klassennamen projektübergreifend suchen und ersetzen könnte - ohne dass mir das Projekt dabei um die Ohren fliegt.

Am Ende geht es nicht darum, den "perfekten" Editor zu finden - den gibt es nicht. Aber es geht darum, einen Editor zu haben, der mich unterstützt, statt mich zu behindern. Ein Tool, das mir hilft, schneller und effizienter zu arbeiten, ohne dass ich mich ständig mit ihm herumschlagen muss. Mit Emacs habe ich die Möglichkeit, mir genau diese Umgebung zu schaffen.

Und ja, ich weiß, dass ich anspruchsvoll bin. Aber wenn ich schon acht Stunden am Tag vor einem Bildschirm verbringe, dann will ich wenigstens ein Werkzeug, das mich nicht in den Wahnsinn treibt.

In weiteren Artikeln möchte ich mich mit jedem dieser Abschnitte einzeln befassen und konkret schauen, welche Lösungen Emacs dabei bietet, welche kleinen Funktionen ich mir vielleicht selbst schreiben kann oder wo sich noch tricksen lässt.