Von Euch geschätzte Merkmale in Entwicklungsumgebungen

[fermion]

Ich bin absoluter Programmierneuling und mich interessieren Eure Vorlieben hinsichtlich Entwicklungsumgebungen.

Mit Code in Form von Markuplanguages habe ich schon lange zu tun.
Auch dort gibt es natürlich einige nützlich Hilfsmittel.

Für IDEs für Programmierer fand ich bisher im Wesentlichen folgende Merkmale:

1. Syntax-Highlighting
2. Auto Pairing (z.B. schließende Klammer oder schließendes Anführungszeichen sofort ergänzen)
3. Autovervollständigung für Sprachkonstrukte und Bibliotheksfunktionen
4. Refactoring
5. Code-Folding
6. Style Cop (Leerzeichen für bessere Lesbarkeit automatisch hinzufügen/rausnehmen)

Ausprobiert habe ich die bei der Installation von Python unter Windows mitgeliefert Shell "IDLE".

Sie beherrscht z.B. die Merkmale 2-6 nicht.

Meinen Augen hilft es bei der Lesbarkeit von Code enorm, wenn Leerzeichen konsistent und ausgiebig verwendet werden.

Beispiel:
statt
foo=59/60
lieber
foo = 59 / 60

Welche Merkmale sind Euch wichtig?
Welche IDEs, die für Windows erhältlich sind, findet ihr exzellent?
Es können sowohl freie als auch kommerzielle sein.

Herzlichen Dank.

Kleinigkeit am Rande:
kann man in Python ohne Probleme sämtliche Einrückungen ausschließlich über Tabulatoren statt über mehrfache Leerzeichen vornehmen?

[/me]

kann man in Python ohne Probleme sämtliche Einrückungen ausschließlich über Tabulatoren statt über mehrfache Leerzeichen vornehmen?

Man kann, aber laut "Style Guide for Python Code" sollte man nicht.

[fermion]

kann man in Python ohne Probleme sämtliche Einrückungen ausschließlich über Tabulatoren statt über mehrfache Leerzeichen vornehmen?

Man kann, aber laut "Style Guide for Python Code" sollte man nicht.

Das weckt meine Neugier.
Weiß jemand, warum sich der Entwickler von Python gegen Tabulatoren entschieden hat?

Es wäre doch klarer, eindeutiger zum Einrücken Leerzeichen sogar zu verbieten.

[BlackJack]

@fermion: Tabulatoren sind eben gerade nicht eindeutig. Wie weit bei einem Tabulator eingerückt wird ist von der Umgebung abhängig in der man den Quelltext betrachtet. Und das kann überall anders sein, im Editor im Terminal, auf einer Webseite, im E-Mail-Programm. Eine feste Anzahl von Leerzeichen pro Ebene ist da viel eindeutiger.

[Hyperion]

Es wäre doch klarer, eindeutiger zum Einrücken Leerzeichen sogar zu verbieten.

Nö, denn Tabulatoren können ja unterschiedlich dargestellt werden! Vier Spaces sind immer und überall gleich und erzeugen damit denselben optischen Eindruck vom Code.

[fermion]

Es wäre doch klarer, eindeutiger zum Einrücken Leerzeichen sogar zu verbieten.

Nö, denn Tabulatoren können ja unterschiedlich dargestellt werden!

Innerhalb eines Editors werden die doch immer gleich breit dargestellt.
Zumindest habe ich das noch nicht anders erlebt. Viele Editoren kenne ich nicht, zugegeben.

[nomnom]

Es wäre doch klarer, eindeutiger zum Einrücken Leerzeichen sogar zu verbieten.

Nö, denn Tabulatoren können ja unterschiedlich dargestellt werden!

Innerhalb eines Editors werden die doch immer gleich breit dargestellt.

Innerhalb eines Editors, ja. Aber häufig wird derselbe Code in mehreren Umgebungen betrachtet, und in diesen werden Tabulatoren gerne mal unterschiedlich dargestellt.

[fermion]

Innerhalb eines Editors werden die doch immer gleich breit dargestellt.

Innerhalb eines Editors, ja. Aber häufig wird derselbe Code in mehreren Umgebungen betrachtet, und in diesen werden Tabulatoren gerne mal unterschiedlich dargestellt.

Als Argument leuchtet mir das noch nicht ein.
Es genügt doch völlig, wenn in einer spezifischen Umgebung, wo sich der Betrachter/Bearbeiter gerade befindet, Tabulatoren konsistent gleich breit dargestellt werden.

Wie rückt ihr in Eurem Programmieralltag eigentlich ein?
Ist es üblich mehrmals die Leertaste zu drücken oder verwendet ihr die Tabulatortaste, habt Euren Editor jedoch so konfiguriert, dass er statt des Tabulatorzeichens eine fixe Anzahl an Leertasten einfügt.

Falls Letzteres:
Warum fügt dann innerhalb von IDLE, der Default-IDE von Python, ein Druck auf die Tabulatortaste keine Leerzeichen ein?

[BlackJack]

@fermion: Das genügt IMHO nicht weil es dann überall anders wo der Autor es nicht geschrieben hat, es potentiell anders aussieht. Die 8 Spalten die ein Tabulator in vielen Umgebungen springt sind auch etwas viel um es gut lesen zu können. Auf der anderen Seite habe ich schon Blogsoftware gesehen die aus einem Tab *ein* Leerzeichen macht, was superschlecht lesbar war. Es wird mit einer Anzahl von Spalten die man nicht kennt auch schwierig die 80-Zeichen-Grenze für die Zeilenlänge einzuhalten wenn die Anzeigeumgebung mehr Spalten pro Tab verwendet als der Editor in dem man das geschrieben hat.

Und dann wäre da noch das Problem das Tabs unsichtbar sind, genau wie Leerzeichen, und man sich ein gemisch einhandeln kann ohne das visuell zu sehen, und dann hat man Code dessen Aussehen nicht der Ausführung entspricht, was extrem blöd bei der Fehlersuche ist.

Also bei mir hat IDLE Autovervollständigung und Tooltips für Argumente und es wird im Editor auch vier Leerzeichen eingerückt wenn ich Tab drücke. Auf der anderen Seite kenne ich niemanden der ernsthaft IDLE verwendet.

[fermion]

@BlackJack
OK, mir war nicht klar, dass es Editoren gibt, die per Default solche Extreme wie 8 oder 1 Spalte bei einem Tabulator darstellen.
Es bleibt natürlich die Frage, ob es nicht in der Verantwortung der Benutzer dieser Editoren liegt, sich eine für sie passende Darstellung von Tabulatoren einzurichten.

Auch zum Argument "Darstellung in klassischen 80er Breiten" merke ich, wie wenig vertraut ich mit Editoren und Programmiersprachen bin.
Ich hätte vermutet, es gäbe längst Konventionen, wie Zeilenumbrüche (in schmalen Entwicklungsumgebungen) sinnvoll dargestellt werden.
Damit Programmierer problemlos, falls gewünscht, größere Zeilenlängen verwenden können.

Bei mir erzeugt IDLE beim Druck der Tabulatortaste ein Tabulatorzeichen. Das meinte ich.

[BlackJack]

@fermion: 8 ist kein Extrem sondern eigentlich die Default-Einstellung, das ist doch quasi der Standardwert den man aus dem Terminal kennt. Und es sind ja nicht nur Editoren und man kann nicht überall tatsächlich Einstellungen vornehmen, beziehungsweise macht das keiner. Ich hatte Terminals, E-Mails, und Webseiten ja schon genannt. Quelltext wird ja nicht nur in Editoren gelesen. Anzeigen im Terminal auf dem Server mal schnell mit ``less`` oder man sucht mit ``ack-grep`` nach etwas, Diffs im Terminal oder in E-Mails, Quelltext oder Diffs im Browser mit den entsprechenden Webanwendungen um sich Repositories anzuschauen, oder Plattformen zum Code-Review, und so weiter.

Also im Editor, und nur da finde ich das auch interessant, erzeugt IDLE bei mir beim Druck auf die Tabulatortaste vier Leerzeichen. Da ich IDLE nicht verwende, gehe ich mal davon aus, dass das die Standardeinstellung ist.

[fermion]

@BlackJack
Danke für die Hinweise.
Jetzt verstehe ich den Nutzen der 80er-Breite besser.

Auch das andere ist geklärt. Ich sprach von der IDLE-Shell, nicht vom Editor.

OK, also zurück zum eigentlichen Thema des Threads

Welche Merkmale schätzt ihr besonders?

[BlackJack]

In keiner besonderen Reihenfolge: Syntax-Hervorhebung, „multiple cursors” und mehrfache Selektionen, Autovervollständigung (wobei mir eigentlich „Worte aus allen offenen Dateien” ausreicht), Suchen/Ersetzen mit regulären Ausdrücken, die Möglichkeit (ausgewählten) Text durch beliebige externe Programme zu pipen, Emmet für HTML & CSS, Plugin-Architektur, und Plugins in Python natürlich.

[fermion]

@BlackJack
Was genau ist bitte mit "Plugin-Architektur" und "Plugins in Python" gemeint?

Ist gemeint, dass die ganzen Teile der Plugins übersichtlich in der IDE auswählbar sind?

Kann jemand eine IDE für Windows empfehlen, die die erwähnten Merkmale 1-6 aus dem Ursprungsposting beherrscht?
Inklusive "Style Cop", also einer automatisierten Umsetzung von Teilen des Python "Style Guides".

[BlackJack]

@fermion: Der Editor soll halt durch Plugins erweiterbar sein und es ist nett wenn man diese Plugins in Python schreiben kann. Hatte ich nicht explizit geschrieben: Mir reicht ein guter Editor, es muss keine ausgewachsene IDE sein. Wobei die Grenzen da ja auch fliessend sind.

1, 2, und 5 kann eigentlich jeder Editor der zum Programmieren geeignet ist. 3 und 4 sind bei dynamischen Programmiersprachen wie Python zumindest nicht 100%ig möglich. 3 bieten mehrere Editoren/IDEs so gut es halt geht. Beispiele wären PyCharm, das PyDev-Plugin für Eclipse, oder die Komodo-IDE. Ob es was für 6 gibt — keine Ahnung. Ich würde wahrscheinlich mehr Zeit investieren müssen mir das lesbare schreiben von Ausdrücken *abzugewöhnen* als ich durch ein automatisches Formatieren von Ausdrücken ohne Leerzeichen jemals wieder einsparen könnte.

Ansonsten ist das hier eine Frage nach einer IDE die schon zigtausend mal gestellt wurde…

[fermion]

@BlackJack
Den Sinn von Reformatierung (Herstellen eines einheitlichen Layout-Stils) sehe ich anders als Du.
Es geht IMHO nicht darum, zu verlernen, händisch guten Stil zu schreiben.

Nur ein Beispiel:
Manchmal ändert man bereits existierendem Code, der von anderen geschrieben wurde. Dazwischen selbst geschriebener.
Da gefällt es mir mit einem Befehl "Reformat" alles in einem Rutsch konsistent zu haben.
Bei Markuplanguages und CSS jedenfalls schätze ich Reformatierung sehr.

Aber vermutlich sind das weltanschauliche Fragen

Am liebsten wäre es mir, wenn die meisten Teile des Pyton Style Guides nicht optional sondern vorgeschrieben wären.
Dann würde das Programm einen Syntaxfehler bei

foo=3

melden.

Ein befreundeter Programmierer schrieb mir, dass in seiner Firma die Entwicklungsumgebung so konfiguriert sei.
Bei schlecht layoutetem Code wird ein Fehler ausgegeben und er wird gar nicht ausgeführt.

Ich werde mir mal einige IDEs ansehen.
PyCharm macht jedenfalls einen sehr guten ersten Eindruck.

Komodo-IDE erhält auf
http://www.pythoncentral.io/comparison- ... komodo-ide
eine vernichtende Kritik. Das werde ich mir wohl schenken.

Über einige weitere Antworten hier im Thread, welche Merkmale Euch wichtig sind, würde ich mich freuen

[BlackJack]

Also erstmal gibt es natürlich Werkzeuge dafür: https://pypi.python.org/pypi/autopep8

Bei diesen kompletten Reformatierungen hat man das Problem viele Änderungen vorgenommen zu haben ohne tatsächlich etwas geändert zu haben, und dass Patches die vorher noch angewendet werden konnten, hinterher viel wahrscheinlicher fehlschlagen. Solange also der Quelltext nicht wirklich ganz furchtbar unlesbar war, würde ich mir sorgfältig überlegen ob ich damit die Versionsgeschichte belasten möchte. Ich verbessere so etwas nur wenn ich die entsprechende Code-Zeile sowieso anfasse um eine *tatsächliche* Änderung vorzunehmen.

``foo=3`` als Syntaxfehler zu sehen wäre schon ziemlich hart. Mir reicht es das mir der Editor eine Warnung für die Zeile anzeigt.

[fermion]

Mir fehlt als absolutem Programmieranfänger naturgemäß die Erfahrung, dass Layout-Änderungen überhaupt dazu führen können, dass "Patches" nicht mehr funktionieren.
Hätte ich nicht mal entfernt vermutet.

Zur Striktheit:
Ganz sicher ist sowas Geschmacksache.
Mein bisher sehr bescheidenes Verständnis der Intentionen von Python sagten mir:
noch mehr Striktheit hätte gut zum Geschmack gepasst.

Aber mir fehlen auch die geschichtlichen Kenntnisse zu Programmiersprachen und zu Gewohnheiten von Programmierern.

Mir ist es sozusagen ein Rätsel, warum formale Sprachen überhaupt soviel Freiheiten beim Layout lassen.
Hätte man mich, bevor ich nur irgendein Stück Code irgendeiner Programmiersprache gesehen hätte, gefragt: was sind Deine Vermutung zur Syntax?

Ich hätte aus vollster Überzeugung geantwortet:
Freiheiten beim Layout, beim Gebrauch von Spaces gibt es nicht. Alles ist bis in Details festgelegt.

Vielleicht ist mein eigenes Auge (ich schreibe ja bisher nur Markupsprachen und CSS) auch außergewöhnlich empfindlich, was Inkonsistenz angeht.

[BlackJack]

@fermion: Mehr erzwungene Striktheit würde IMHO gar nicht zu Python passen. Da wird doch so vieles nur über Konventionen geregelt und nicht syntaktisch oder sonst irgendwie erzwungen. Philosophie ist, dass es sich um „consenting adults” handelt die wissen was sie tun und auch wissen wann und warum sie gegen Konventionen verstossen. Zum Beispiel ist ``import pdb; pdb.set_trace()`` als Zeile mitten im Quelltext nicht PEP8-Konform, trotzdem ist genau das die idiomatische Verwendung. Ähnlich ``import cgitb; cgitb.enable()`` was man in der Form in CGI-Skripten antreffen kann.

Wenn man mit Operatorüberladung spielt und sich eigene benannte „Operatoren” erstellt, dann möchte man auch nicht das irgendein Automatismus aus ``value_a |op| value_b`` einfach so ``value_a | op | value_b`` macht.

diff/patch sind Werkzeuge die allgemein auf Textdateien operieren und von der Sprache und deren Struktur absolut keine Ahnung haben, demenstprechend können sie auch nicht erkennen ob sich nur das Layout oder tatsächlich semantisch etwas am Quelltext geändert hat. Vorteil davon ist, dass sie mit jeder Sprache, oder auch mit formlosen Textdateien funktionieren, solange es eben Textdateien sind. Ein Diff/Patch enthält dabei ein paar unveränderte Zeilen als Kontext, damit man ihn auch anwenden kann wenn sich durch andere Änderungen die Zeilen verschoben haben sollten.

Ich denke mit einer Sprache die fehlende Leerzeichen um Operatoren als Syntaxfehler ansehen würde, will keiner arbeiten. Das wäre extem nervig. For allem bräuchte man dann tatsächlich zwingend einen Mechanismus um den Quelltext entsprechend zu formatieren, denn zum Beispiel in einer Python-Shell mache ich mir bei weitem nicht immer die Mühe alles möglichst lesbar zu schreiben, denn das was man dort schreibt ist ja nicht von Dauer und verschwindet nach Beenden der Shell.

Was wirklich lesbar formatieren heisst, hängt manchmal auch von der Semantik ab, dass heisst das kann man gar nicht formal festlegen. Siehe das Beispiel mit ``|op|``.

[fermion]

@BlackJack
Danke für Deine ausführliche Antwort.
Es bleibt mir zum jetzigen Zeitpunkt nur, Dir zu vertrauen

Ob auch für Operatorüberladungsspieler anderer, besser lesbarer Code möglich wäre, kann ich nicht sagen.
Zu diff/patch:
Ich dachte bei "striktere Syntax" natürlich an Überprüfungsmethoden, die die Struktur,Syntax und Semantik interpretieren. Simpler Textvergleich wäre natürlich zuwenig.

Vermutlich müsste ich diverse Codeteile sehen (und verstehen), die durch eine Reformatierung nachvollziehbar leiden.
Das ist für einen Anfänger wie mich wohl ausgeschlossen.
Also komme ich damit später nochmal

Zu fehlenden Leerzeichen um Operatoren:
Bei meinem Gedanken dazu, würde der Programmierer ja im Alltag nicht mit solchen Fehlermeldungen belästigt, da seine IDE die passende Leerzeichen automatisch on-the-fly einfügt.
Egal, wo er arbeitet. Auch in der Konsole.
Ist natürlich Utopie. Gibt es nicht, klar.
Aber denkbar wäre es.