Python - tolle Sprache krankes Styleguide

[mimi]

Beruflich komme ich aus der IBM-Ecke was das
Programmieren betrifft. Die Programmiersprache RPG
ist "positionsorientiert": So müssen Befehle wie
zum Beispiel "CHAIN" [1] an einer bestimmten
Stelle in der Source stehen. Schreibe ich den
Befehl "CHAIN" auch nur um eine Stelle versetzt so
erhalte ich vom Compiler (bzw. dem Editor SEU;-)
die Fehlermeldung "HAIN" is not valid. Das ist
krank. Python ist hier aber leider nicht viel
besser [2].

Lange Rede kurzer Sinn: Jahrelang programmierte
ich begeistert in Perl. Irgendwann stimulierte
mich die unendliche Freiheit in Perl nicht mehr
sondern schränkte mich letzlich in meiner
Kreativität ein. Ich entdeckte Python und bin bis
heute von dem kompakten Sourcecode begeistert.

Das kalte Kotzen bekomme ich aber wenn mich dieser
dumme Compiler dazu zwingt meine Sourcen so
einzurücken wie es ihm (Ihm :) gefällt: Ich hasse
das.

Deshalb kann ich Python nur für kleine Aufgaben
verwenden. Schade.


---------------
[1] - der Befehl Chain liest einen Datensatz aus einer Datenbank.
[1] - Für Besserwisser: Natürlich gibt es auch das sog. "Freeformat". Stimmt.
[2] - Nunja - ein wenig.

[EyDu]

Wenn der Interpreter dich immer wieder auf die Einrückung hinweist, dann machst du irgend etwas falsch: Entweder rückst du einfach vollkommen unsinnig ein oder du vermischt Leerzeichen mit Tabs. Du solltest dich an PEP 8 halten, dann sieht der Code standardkonform aus und ist gut lesbar.

[numerix]

Also entweder ist es so, wie EyDu geschrieben hat, oder es ist so, dass es dich grundsätzlich stört, dass Blöcke eingerückt werden MÜSSEN und du nicht selbst entscheiden kannst, wann du überhaupt etwas einrückst. Wenn letzteres der Fall ist, dann verstehe ich das wahrhaftig nicht, denn für mich ist das eines der positiven Merkmale Pythons, dass ich gezwungen werde, meinen Code erkennbar strukturiert anzulegen.

Ich habe vor einiger Zeit mal einen Video-Vortrag einer Vorlesung eines US-Professors im Web gefunden, der tatsächlich behauptete, gerade das wäre ein Nachteil, weil man durch die fehlenden Klammerkonstrukte bei längeren Quelltexten nicht mehr gut erkennen könne, was zusammengehöre.

[mimi]

Ja Du hast das richtig erkannt: Ich kann einrücken, will
aber nicht dazu gezwungen werden. Der Lesbarkeit des
Sourcecodes ist das natürlich zuträglich. Trotzdem: Lesbaren
Code zu schreiben ist Aufgabe des Programmierers und sollte
nicht vom Compiler erzwungen werden.

[lunar]

Dann musst du dir eben eine andere Sprache suchen.

[mimi]

Dann musst du dir eben eine andere Sprache suchen.

Nein. Dafür ist Python einfach zu überwältigend.

[lunar]

Warum beschwerst du dich dann? Was willst du damit erreichen?

[Defnull]

Ich habe vor einiger Zeit mal einen Video-Vortrag einer Vorlesung eines US-Professors im Web gefunden, der tatsächlich behauptete, gerade das wäre ein Nachteil, weil man durch die fehlenden Klammerkonstrukte bei längeren Quelltexten nicht mehr gut erkennen könne, was zusammengehöre.

Genau dieses Argument habe ich letztens von einem jahrelangen C++ Programmierer gehört. Ich kann das absolut nicht nachvollziehen. Warum sind Klammern übersichtlicher als Einrückungen? Warum rücken die meisten C-Programmierer ihre Blöcke ein (obwohl sie es nicht müssen) wenn die Klammern doch vollkommen ausreichen?

Abgesehen davon hindert einem keiner an folgendem:

Code: Alles auswählen

if somevar:
  pass
#endif for somevar

Das macht bei mehr als einen Bildschirm langen Blöcken oder komplexen Strukturen durchaus Sinn. Auch wenn es meistens noch viel mehr Sinn macht, den Kram einem ordentlichen Refactoring zu unterziehen.

[Defnull]

Lesbaren Code zu schreiben ist Aufgabe des Programmierers und sollte nicht vom Compiler erzwungen werden.

In allen Teams, in denen ich bisher gearbeitet habe, war es üblich, einen automatischen Sourcecode-Formatierer zu benutzen, damit die Versionskontrolle sich nicht an veränderten Whitespaces verschluckt. Von daher ist es nichts Besonderes, das man als Entwickler gezwungen wird, bestimmte Regeln einzuhalten. Und das ist auch gut so.

Tipp: Besorg dir einen Editor, der eine 'Convert spaces to tabs bevor saving python files' Funktion hat.

[BlackJack]

@mimi: Das Problem existiert nur in Deinem Kopf. Auch ohne diesen Zwang schreibe ich in allen anderen Sprachen, die dafür Klammern oder ähnliche Konstrukte verwenden, Quelltext mit der entsprechenden Einrückung, weil das dem Verständnis des Quelltextes dient. In den meisten Fällen übernimmt das sogar die IDE für mich. Man könnte also sagen Eclipse und meine Kollegen zwingen mir ihre Einrückung bei Java-Quelltext auf, OMG!!1!elf!

Der Vergleich mit der Sprache, die Du erwähntest, oder auch mit klassischem FORTRAN, hinkt gewaltig, weil die vorgeschriebene Formatierung dort dazu dient dem Compiler das Leben einfacher zu machen, während das Einrücken nach Programmstruktur das Programm hauptsächlich für den Menschen einfacher verständlich präsentiert. Wie kann man so etwas als "krank" bezeichnen!? Was genau ist der Nachteil? Das man nicht mehr alles in eine Zeile quetschen kann, oder Programme drüberlaufen lassen kann, die den Quelltext in die Form eines Kamels bringen!? Bitte mal einen rational nachvollziehbaren Grund, warum man den Quelltext nicht für Menschen verständlich schreiben möchte.

Apropos Formatierungen: Du wirst es vielleicht auch als Einschränkung Deiner Ausdrucksfreiheit ansehen, wenn ich Dich bitten würde die vielen Zeilenumbrüche zu unterlassen, und es dem Empfänger zu überlassen wie breit, oder auch schmal, er Deine Texte gerne lesen möchte!?

[gkuhl]

@mimi: Kannst du ein Beispiel geben, wo das erzwungene Einrücken unter Python für dich ein Problem ist. Mir ist das nämlich noch nie passiert.

[HerrHagen]

Die Kritik an der Einrückung kann ich überhaupt nicht nachvollziehen.
Bei Sprachen wie C macht man sich die Arbeit ja doppelt, einmal formatiert man den Code so, dass er für den Compiler lesbar wird (Klammern) - Einmal für sich selbst (Einrückung) um nicht die Übersicht zu verlieren. Was spricht nun dagegen diese (gefährliche) Redundanz zu entfernen? So kann kein Wiederspruch mehr zwischen dem was man ausdrücken wollte (zumindest bzgl. Blockbildung) und dem was der Rechner liest auftreten.
Zudem finde ich diese ganzen Klammern fürchterlich unübersichtlich und hässlich (nur noch übertoffen von dem Semikolin am Ende jeder Zeile).

MFG HerrHagen

[Defnull]

Für Sprachen, die Quick&Dirty unterstützen oder sogar fördern (Perl, Ruby, ECMA) sind Klammern und Separatoren (;) durchaus sinnvoll, um Einzeiler zu erlauben. Bei Python ärgert mich ab und zu, das ich folgendes nicht schreiben kann:

Code: Alles auswählen

if not valid(input1): log.error('Fehler1'); return
if not valid(input2): log.error('Fehler2'); return
if not valid(input3): log.error('Fehler3'); return

oder das lambda so eingeschränkt ist:

Code: Alles auswählen

array = map(lambda{x: func1(x); func2(x); return x}, array)

Aber wenn man auch nur eine Sekunde drüber nach denkt, kann man es durch simples Refactoring (lokale funktionen) eh besser lösen.[/code]

[hendrikS]

Ich kann mich den anderen nur anschließen. Ich kann nicht verstehen warum die Einrückungen ein Problem sein sollen.
Es gibt andere Probleme. Wenn ich nur an Py3 denke...

[mimi]

Vielen Dank an alle die meine Meinung mit einer Antwort würdigen.

@lunar
Dieses Posting möchte ich als Meinungsäußerung verstanden wissen. Ich habe keine konkrete Zielsetzung und möchte demnach auch nichts bestimmtes erreichen.

@Defnull
Wie erwähnt verwende ich Python nur privat ohne ein CVS. Ich habe also keine Erfahrung mit Python im Team. Vim habe ich so eingestellt dass ein Tab mit drei Leerzeichen dargestellt wird - Ein anderer Editor für Sourcecode kommt mir nicht ins Haus.

@BlackJack
Geschickt formuliert: Anfangs hattest Du mich "kalt erwischt". Wie Dir aber sicherlich aufgefallen ist habe ich nur meine Meinungsäußerung gesondert formatiert. Antworten schreibe ich im Fließtext. Aber genau darum geht es: Ich entscheide wie sich mein Text, meine Anweisungen am Bildschirm präsentieren.

@HerrHagen
Ja das Semikolon am Ende der Zeile empfinde ich auch als unangenehm. Mit C kenne ich mich nicht aus. Selbstverständlich formatiere ich meinen Sourcecode. Damit verbunden ist auch ein höherer Eingabeaufwand als nur ein einfaches TAP.

@ an alle
Python ist viel zu erfrischend als dass ich über diese Programmiersprache lästern möchte. Vielleicht berührt dieser dumme Einrückzwang auch nur mein viel zu schäbiges Programmiererherz... (Eine mir nahe stehende Person würde jetzt sagen: "Getroffene Hunde bellen"

[EyDu]

Vim habe ich so eingestellt dass ein Tab mit drei Leerzeichen dargestellt wird - Ein anderer Editor für Sourcecode kommt mir nicht ins Haus.

Es sollten vier sein

Geschickt formuliert: Anfangs hattest Du mich "kalt erwischt". Wie Dir aber sicherlich aufgefallen ist habe ich nur meine Meinungsäußerung gesondert formatiert. Antworten schreibe ich im Fließtext. Aber genau darum geht es: Ich entscheide wie sich mein Text, meine Anweisungen am Bildschirm präsentieren.

Nein, damit entscheidest du, wie der Text bei uns aussieht:
http://www.python-forum.de/post-139498.html#139498 und http://www.python-forum.de/viewtopic.php?p=139615.

[BlackJack]

An dieser Stelle mal wieder der Tipp: ``from __future__ import braces``.

[str1442]

@Defnull: Trenn doch einfach alle "inputs" und alle Fehlermeldungen in zwei Listen, verknüpfe das mit zip() und nutze eine For Schleife. Dann kannst du dir die zwei extra Zeilen für das if auch gönnen. Wenn du Dinge wegen "logischer Abgeschlossenheit" in eine Zeile quetschen willst, dann meist doch nur, weil du diese Dinge sowieso duplizierst und das Muster gleich erkennen willst. Stattdessen solltest du die Duplikation beseitigen und das Muster einmal hinschreiben.

[Klip]

Mir ist die erzwungene Einrückung bei Python ehrlich gesagt noch nie negativ aufgefallen. Ich würde in jeder anderen Programmiersprache genau so einrücken, wie ich es bei Python muss, deswegen gab es zwischen dem Interpreter und mir noch nie einen Ehekrach.

Dafür ist bis zu einem gewissen Anteil garantiert, dass man lesbaren Code erhält, wenn man Python-Code von Dritten liest, was bei Sprachen wie Perl eher selten der Fall ist.

Also wo liegt das Problem?

[Pekh]

Also wo liegt das Problem?

Das ist wie mit dem Tempolimit auf Autobahnen: Man will halt die Freiheit haben, auch wenn man sie eigentlich gar nicht nutzen kann oder gar will.