ubuntuusers.de

snafu1 schrieb:

Jetzt mal ernsthaft: Die Diskussion, ob Tabs oder Leerzeichen, wurde schon tausendfach geführt. Wenn dir Tabs lieber sind, dann benutze sie doch einfach. Aber ungefragt mit der o. g. Aussage einen Vortrag in einem Thread von 2009 zu halten, ist - freundlich ausgedrückt - schon etwas merkwürdig.

Wie gesagt ich hatte halt das Problem, dass etwas falsch eingerückt war und hatte gesucht wie man das in Geany formatiert, weil ich Geany neu benutze und eigentlich vim Nutzer bin. Und dieser Thread kam halt ganz oben in der Suche auch wenn er alt war und den fehlerhaften Beitrag von Lysander konnte man meiner Meinung nach nicht so als letzten Beitrag stehen lassen, da er behauptet hat, daß Einrückungen mit Tabulatoren uneinheitlich seien, was sie ganz sicher nicht sind. Ich hätte nicht gedacht, daß deswegen gleich so eine lange Diskussion entsteht.

Die Lösung für mein ursprüngliches Einrückungsproblem war übrigens markieren mit Alt+Shift und dann kann man mehrere Zeilen in Geany gleichzeitig bearbeiten um sie zum Beispiel wie in meinem Fall mit Tabulator einzurücken.

sur3 schrieb:

Die Lösung für mein ursprüngliches Einrückungsproblem war übrigens markieren mit Alt+Shift und dann kann man mehrere Zeilen in Geany gleichzeitig bearbeiten um sie zum Beispiel wie in meinem Fall mit Tabulator einzurücken.

Ich hatte ein ähnliches Problem vor kurzem auch, allerdings wollte ich 4 Leerzeichen statt Tabs haben und mein Editor hatte das wohl nicht automatisch angewendet. Ich hatte mir dann mit einer speziellen Einstellung in der Suche geholfen, indem ich nach \t gesucht habe und in 4x Leerzeichen ersetzt habe.

snafu1 schrieb:

sur3 schrieb:

Die Lösung für mein ursprüngliches Einrückungsproblem war übrigens markieren mit Alt+Shift und dann kann man mehrere Zeilen in Geany gleichzeitig bearbeiten um sie zum Beispiel wie in meinem Fall mit Tabulator einzurücken.

Ich hatte ein ähnliches Problem vor kurzem auch, allerdings wollte ich 4 Leerzeichen statt Tabs haben und mein Editor hatte das wohl nicht automatisch angewendet. Ich hatte mir dann mit einer speziellen Einstellung in der Suche geholfen, indem ich nach \t gesucht habe und in 4x Leerzeichen ersetzt habe.

sur3 schrieb:

Deswegen wenn man ein fremdes Dokument in Geany öffnet einfach einmal Menü->Dokument->Leerzeichen durch Tabulatoren ersetzen.. Und schon ist alles einheitlich.

Das gibt es auch umgekehrt in Geany als Menü->Dokument->Tabulatoren durch Leerzeichen ersetzen, da muß man nur darauf achten die richtige Einzugsbreite vorher einzustellen. Also falls man unbedingt mit Leerzeichen arbeiten will geht das so natürlich auch. 😉

snafu1, bei Deinem kurzzeitigem "in einem Thread von 2019" sind'n paar bit gekippt gewesen. 😉 Mit 2009 sind wir aber schon näher an den hier erwähnten 90ern - und, ja, nicht nur Mode wiederholt sich. sur3 hat wohl einen Blick auf explodierende RAM-Preise geworfen und will nun alles eindampfen.

Vor knapp 3 Jahrzehnten habe ich kurze Zeit mit Assembler zu tun gehabt, habe mich auch über jedes durch meine Optimierung eingesparte Byte gefreut...und verabscheue exorbitante Ressourcenverschwendung wie beim Nvidia-GPU-Treiber, dessen Installationsdatei unter Windows mit mittlerweile >700 MiB ächzt (es muß heutzutage ja unbedingt alles bunt zappeln), um nur ein Beispiel zu nennen.

Die Platzbetrachtung Space<>Tab ist da aber nicht mal ein halber Tropfen auf den heißen Stein.

von.wert schrieb:

...und verabscheue exorbitante Ressourcenverschwendung wie beim Nvidia-GPU-Treiber, dessen Installationsdatei unter Windows mit mittlerweile >700 MiB ächzt

Ist bei IDEs (z. B. Visual Studio) leider auch so, dass die superviel Platz einnehmen. Ich weiß nicht, inwiefern man nicht benötigte Teile rauskonfigurieren könnte. Aber dann dann muss die Dinger auch aus den Quellen bauen. Ich bevorzuge da sowieso die Mitteldinger zwischen IDE und Editor, zumal die auch schneller hochfahren. Bei Treibern kenne ich mich nicht so gut aus. Bin froh, wenn alles läuft.

von.wert schrieb:

Die Platzbetrachtung Space<>Tab ist da aber nicht mal ein halber Tropfen auf den heißen Stein.

Naja der komprimierte Quelltext-Ordner in meinem Gentoo hat momentan 76 GB, mit Tabulatoren wären das ca. 2 GB weniger, zugegeben nicht viel aber immerhin. ^^

und was hindert dich daran, da ein Skript drüberlaufen zu lassen, das jeweils zwei bis vier sukzessive Leerzeichen in einen Tab umwandelt? Das lässte über Nacht laufen und hast 2 GB Speicherplatz frei.

timothy2068 schrieb:

und was hindert dich daran, da ein Skript drüberlaufen zu lassen, das jeweils zwei bis vier sukzessive Leerzeichen in einen Tab umwandelt? Das lässte über Nacht laufen und hast 2 GB Speicherplatz frei.

Naja momentan habe ich noch 16GB auf der Platte frei und wenn ich die Archivdateien neu komprimiere mit anderem Indenting dann stimmen die Prüfsummen nicht mehr und das ganze build system zerbricht dann und würde versuchen die Dateien neu zu downloaden, wäre also sinnvoll wenn das upstream im Original Quelltext passieren würde, aber das dürfte schwer werden so viele Entwickler dazu zu überreden effizienteres Indenting zu benutzen, bei fast 2000 Programmen. xD

@sur3: Das Argument, dass man bei Tabs einfach einstellen kann was man selbst mag, stimmt nicht. Weder kann man überall einstellen wo die Tabstopp-Positionen sind, noch bleibt dabei die Darstellung sauber erhalten.

Das man nicht überall einstellen kann, führt im Terminal, Webbrowser, oder E-Mail-Programm beispielsweise in der Regel zu Tabstopp alle 8 Zeichen. Was Dir selbst ja aus DOS-Erfahrung zu viel ist.

Wenn man etwas anderes einstellt als das, was beim Schreiben des Quelltextes verwendet wurde, dann muss das nicht mehr einheitlich und so ausgerichtet bleiben, wie dass der Autor mit seiner Einstellung gemacht hat.

Geschrieben mit Tabstopps alle 4 Zeichen, angezeigt mit Tabstopps alle 2 Zeichen:

1
2
3

#define START_YEAR    1882
#define END_YEAR    2025
#define DM_TO_EUR_YEAR  2002

Die Zahlen sollten alle untereinander ausgerichtet sein. Auch bei Tabstopps alle 8 Zeichen sind die Zahlen nicht alle da wo sie sollten.

Bei der Einrückung am Zeilenanfang kann es auch Probleme geben:

  printf("%.2f %s in %"PRIu16" = %.2f %s in %"PRIu16".\n",
       amount, start_currency, start_year, result, result_currency, year);

Das a von amount sollte eigentlich unter den Anführungszeichen in der Zeile darüber stehen.

Das Du einiges mehr tippen müsstest um Zeichen aufzuholen, stimmt nicht, weil das Mehr an Leerzeichen kein Mehr an Tastendrücken bedeutet. Für vier Leerzeichen muss man in der Regel genau so viel tippen wie für ein Tabulatorzeichen. Niemand der Leerzeichen zum Einrücken verwendet, tippt da tatsächlich vier Leerzeichen ein. Das ist auch nur ein Druck auf die Tab-Taste. Fortgesetzte Einrückung aus der vorhergehenden Zeile bekommt man gratis beim betätigen der Eingabetaste. Wenn der Editor was taugt, dann auch gleich plus eine Ebene wenn in der vorherigen Zeile am Ende ein : steht, wenn man Python-Quelltext bearbeitet.

Grossbuchstaben lassen sich besser komprimieren? Und das FAT-Dateisystem macht das? Das ist beides falsch.

DOS hat Dateinamen in Grossbuchtaben von CP/M abgeschaut. CP/M hat das von vorhergehenden Mini- und Grossrechnern abgeschaut. Unter anderem technisch bedingt wohl auch deshalb, weil in den Anfangstagen von CP/M, wie bei den Mini- und Grossrechnern, Fernschreiber für die Daten-Ein und -Ausgabe verwendet wurden. Klassisch zum Beispiel ein TeleType 33 ASR. Man kann nur Grossbuchtaben eingeben und das Gerät kann auch nur Grossbuchtaben zu Papier bringen, aber es kann Kleinbuchstaben empfangen, die dann als Grossbuchtaben ausgegeben werden. Und die integrierten Einheiten zum Lochstreifen lesen und stanzen können auch Gross- und Kleinbuchstaben, beziehungsweise ist das da im Grunde egal, die können halt Lochstreifen mit 8 Spuren. Das hat zur Folge, dass man Datenaustausch mit vollem ASCII-Zeichenvorrat per Lochstreifen hat, selbst aber nur über Grossbuchstaben mit dem Rechner kommunizieren kann. Damit es keine Dateinamen geben kann, die man nicht über die Tastatur eingeben kann, müssen die in Grossbuchstaben sein.

Welche ganzen grossen Python-Projekte? Wo würden durch Tabs statt Leerzeichen mindestens 24 MiB eingespart? Die Zahl hast Du Dir doch Ad Hoc ausgedacht. Und solange die nicht in ein Verhältnis zur gesamten Grösse der Dateien im Projekt gesetzt wird, sagt die noch nicht mal wirklich etwas aus.

@snafu1: Funktionen sind schon okay, aber nur um Bytes im Quelltext zu sparen, für Ausdrücke, die lang genug sind und oft genug vorkommen, das man da etwas einsparen kann. 😉

Vorsicht bei Assembler: Da wird der Quelltext in der Regel länger als ein Programm in einer ”Hochsprache”. Und Finger weg von kompilierten Sprachen. Die linken in der Regel zu jedem Kompilat mindestens einen Teil der Laufzeitbibliothek dazu. Am besten eine interpretierte Sprache, die den Quelltext nicht als reinen Text, sondern schon in einem optimierten Zwischenformat bekommt. Da wären wir dann wieder bei BASIC & Co. \o/

@timothy2068: So ein Skript ist ein kleines bisschen aufwändiger als man auf den ersten Blick denken mag. Man sollte beispielsweise keine Leerzeichen in Zeichenkettenliteralen durch Tabs ersetzen, da können Dinge kaputt gehen, denn man weiss nicht wo solche Texte am Ende landen.

Einfach nach einer Anzahl von Leerzeichen suchen, die der gewünschten Tab-Breite entsprechen und durch "\t" ersetzen geht auch nicht, weil das von der Spalte abhängt, wo diese Leerzeichen starten. Ein "\t" ersetzt ja nicht eine feste Anzahl an Leerzeichen, sondern springt zum nächsten Tabstopp, der auch weniger Leerzeichen entfernt sein kann als die gewünschte Tab-Breite.

Weiteres Problem: Was macht man mit Dateien, die bereits Tabs enthalten? Müsste man eigentlich neu ”tabben” wenn die gewünschte Tab-Breite nicht mit der überein stimmt, die der Autor verwendet hat. Welche das ist, kann man aber gar nicht ermitteln, das muss man wissen. Tabs sind toll, yeah. =:O)

Ja gut Tabellen und Zeilenumbrüche sind tatsächlich nicht einheitlich bei anderen Tab Einstellungen. Aber mir ging es ja primär um Einrückungen bei Quellcode. Auch daß manche Programme dafür keine Einstellung haben mag sein, aber die meisten modernen Editoren und insbesondere Geany haben das durchaus. Und sogar in der Shell kann man das bei less mit -xn einstellen z.B. less -x3 test.py für Tabstopp 3.

Marc_BlackJack_Rintsch schrieb:

Bei der Einrückung am Zeilenanfang kann es auch Probleme geben:

  printf("%.2f %s in %"PRIu16" = %.2f %s in %"PRIu16".\n",
       amount, start_currency, start_year, result, result_currency, year);

Das a von amount sollte eigentlich unter den Anführungszeichen in der Zeile darüber stehen.

Das ist ja eine irreguläre Einrückung bei einem Zeilenumbruch, ehrlich gesagt richte ich solche nie aus, sondern mache einen einfachen Indent wie bei anderen Code-Einrückungen auch. Aber wenn man das aus Ästhetischen Gründen exakt an irgendwas ausrichten will muß man in der Tat Leerzeichen verwenden. ^^"

Das Du einiges mehr tippen müsstest um Zeichen aufzuholen, stimmt nicht, weil das Mehr an Leerzeichen kein Mehr an Tastendrücken bedeutet.

Doch wenn ich in meld Einrückungen anpasse muss ich immer an den Anfang der Zeile gehen und entsprechend viele Leerzeichen tippen und das für jede Zeile, habe ich heute schon oft tun müssen..

Grossbuchstaben lassen sich besser komprimieren? Und das FAT-Dateisystem macht das? Das ist beides falsch.

Das hatte ich damals mal gelesen, daß die Codierungstabellen von Archivprogrammen auf Großbuchstaben optimiert waren, weil Opcodes bzw. Binärdateien weniger Kleinbuchstaben verwenden. Aber ein aktueller Test mit heutigen Kompressionsprogrammen scheint das nicht mehr zu bestätigen. Und bei FAT war das ja ganz wild, wenn man nicht im Großbuchstabenformat mit 8.3 Dateinamen geblieben ist dann mußte der ja extra Sektoren für die Langen Dateinamen reservieren.

Welche ganzen grossen Python-Projekte? Wo würden durch Tabs statt Leerzeichen mindestens 24 MiB eingespart? Die Zahl hast Du Dir doch Ad Hoc ausgedacht. Und solange die nicht in ein Verhältnis zur gesamten Grösse der Dateien im Projekt gesetzt wird, sagt die noch nicht mal wirklich etwas aus.

Das habe ich von meinem Test mit dem 600 Zeilen Programm hochgerechnet: 4kB Ersparnis / 27kB Gesamtgröße ⇒ 24 MB / 162 MB Gesamtgröße Zugegeben mir fällt gerade kein Python Projekt mit 162 MB Quelltext ein, aber Indentations gibt es auch bei Java und anderen Sprachen und da gibt es ganz sicher Projekte in der Größe.

@sur3: Ja man kann das in einigen Programmen einstellen, das habe ich ja nicht bestritten. Aber eben an vielen Stellen auch nicht, und dort möchte ich halt auch dass es funktioniert. Bei less wäre es lästig das jedes mal anzugeben, und dann weiss man dort ja auch nicht was man angeben muss.

Dazu kommt dann noch, dass man sich nicht nur den Quelltext selbst, sondern oft auch veränderten Quelltext anschaut, beispielsweise bei diffs, oder in Fehlermeldungen oder Tracebacks, wo in der Regel Text/Einrückung davor eingefügt wird.

Ich würde das Ausrichten von Ausdrücken, die sich über mehrere Zeilen erstrecken nicht als ”irregulär” bezeichnen. Das ist ein durchaus übliches vorgehen bei vielen Programmierern. Und bei einigen Programmiersprachen sogar der Normalfall. Beispielsweise bei allem was eine Lisp-ähnliche Syntax hat. Beispiel:

(defn run [in-🌡️ out-🌡️ pumps end-time]
  (while (< (get-time) end-time)
    (switch-pumps pumps True)
    (try (💤-minutes 3)
         (while (and (< (get-time) end-time)
                     (< (read-temperature in-🌡️)
                        (read-temperature out-🌡️)))
           (💤-minutes 2))
      (finally (switch-pumps pumps False)))
    (💤-minutes 15)))

Hast Du Dich bei Deinem 600-Zeilen-Programm auf die führenden Leerzeichen beschränkt, oder hast Du alle Leerzeichen, die man durch Tabs ersetzen kann, ersetzt? Wie gesagt, darf man beispielsweise in literalen Werten nicht einfach ersetzen. Auch nicht immer am Zeilenanfang wenn die Sprache beispielsweise mehrzeilige Zeichenketten unterstützt.

Das hatte ich damals mal gelesen, daß die Codierungstabellen von Archivprogrammen auf Großbuchstaben optimiert waren...

Mit Kompression hat das aber wenig zu tun. Da sollte nur die Anzahl der benötigten Bits für ein Zeichensymbol relevant sein. Es sei denn, man verringert diese indem man sich auf Großbuchstaben beschränkt. Es gab da mal, vor etlichen Jahren, einen interessanten Artikel im legendären Dr. Dobb’s Journal in dem der LZW Algorithmus beschrieben wurde. Da zählten nur die benötigten Bits.

Zu dem "irregulären" Einrücken: ich setze das seit einiger Zeit verstärkt ein, etwa so:

1
2
3
4
5
6
7
8
9

int
MainWindow::manage_thumbs( const char * dt_dir,  // destination thumb directory
                           const char * st_dir,  // source thumb directory
                           const char * d_name,  // new thumb name
                           const char * s_name,  // old thumb name
                           png_info_t * info_ptr,// pointer to info structure
                           int          flags ) {
    Fl_Image *  t_image;
...

Und ja, dass der Datentyp hier eine eigene Zeile bekommt ist auch Absicht. Die Klasse steht dann immer am Anfang einer Zeile. Die Einrückung orientiert sich dabei nicht unbedingt an den Tabstops.

Marc_BlackJack_Rintsch schrieb:

Hast Du Dich bei Deinem 600-Zeilen-Programm auf die führenden Leerzeichen beschränkt, oder hast Du alle Leerzeichen, die man durch Tabs ersetzen kann, ersetzt? Wie gesagt, darf man beispielsweise in literalen Werten nicht einfach ersetzen. Auch nicht immer am Zeilenanfang wenn die Sprache beispielsweise mehrzeilige Zeichenketten unterstützt.

Nee habe nur die Indentations ersetzt, das wäre übrigens ein weiteres Argument für Tabs, daß die im sonstigen Quelltext nicht wirklich vorkommen und man die daher leichter mit sed oder tr ersetzen kann. Die Lisp Syntax sah tatsächlich so aus als wenn es da sinnvoll wäre Leerzeichen zu verwenden um das so zu formatieren. Mit Lisp habe ich noch nicht gearbeitet, ich würde die Art der Einrückung aber dennoch als irregulär bezeichnen, da die Einrückungsbreite eben nicht einheitlich über die Datei ist, erinnert mich ein wenig an "Brainfuck" diese esoterische Programmiersprache wo man genau an der richtigen Stelle ein Zeichen setzen muß. Im Thread ging es ja auch primär um Python, bei den meisten Programmiersprachen ist die Einrückungsbreite ja egal und bloß ästhetisches Empfinden der Programmierer.

@sur3 Das was Du als irreguläre Einrückung bezeichnest und wo Duakan ja auch ein Beispiel für gebracht hat, kann man auch in Python so machen. Das ist in PEP 8 explizit vorgesehen. Mit einem Beispiel für mögliches Einrücken von Parameter- und Argumentlisten. Das Beispiel dort ist:

1
2
3

# Aligned with opening delimiter.
foo = long_function_name(var_one, var_two,
                         var_three, var_four)

Ich persönlich mache das in Python nicht so (aber in anderen Programmiersprachen), aber wenn das im offiziellen Style-Guide steht, würde ich davon ausgehen, dass es Leute geben wird, die das so machen. Womit ich mich dann schwer tue das als irregulär zu bezeichnen.

Den Vergleich mit Brainfuck kann ich so gar nicht nachvollziehen. Zunächst muss man dort in Relation zu Whitespace keine Zeichen exakt positionieren, weil die Sprache Whitespace komplett ignoriert. Man kann da alles in eine Zeile schreiben, oder jedes einzelne Zeichen in eine eigene Zeile und vor, zwischen, und nach den Zeichen beliebig viel oder wenig Leerzeichen. Die Sprache an sich ist relativ “unlesbar”. Sie ist halt super primitiv und ”esoterisch”. Formal gesehen ist das die Umsetzung einer einfachen Turingmaschine, und damit sehr minimalistisch, aber turing-vollständig. Heisst man kann damit alles berechnen was berechenbar ist. Will man in der Form natürlich nicht, weil das praktisch noch mehr Sisyphusarbeit wäre, als ein komplexeres Programm in Maschinensprache zu schreiben.

Einrückung sollte ja üblicherweise der Lesbarkeit dienen. Das man an der Formatierung besser erkennen kann was zusammen zu bestimmten Konstrukten wie Funktionen, Aufrufen, Schleifen und so weiter gehört. Und bei Lisp-ähnlichen Sprache mit den ganzen Klammern und der ansonsten strukturellen Gleichförmigkeit der Syntax bietet sich diese Art der Formatierung an. Aber die kann man genau so gut in anderen Programmiersprachen anwenden um den Code lesbarer und verständlicher zu gestalten. Und das wird ja auch gemacht.

... Brainfuck ... Sie ist halt super primitiv und ”esoterisch”. Formal gesehen ist das die Umsetzung einer einfachen Turingmaschine, und damit sehr minimalistisch, aber turing-vollständig. Heisst man kann damit alles berechnen was berechenbar ist. Will man in der Form natürlich nicht, weil das praktisch noch mehr Sisyphusarbeit wäre, als ein komplexeres Programm in Maschinensprache zu schreiben.

Da hast Du recht. Ich habe ein wenig Erfahrung mit Assembler (Z80, MC68000 & MC68010) und daher kann ich sagen, dass ich lieber ein kleines Projekt (muss ja nicht die Intel CPU sein) in Assembler schreibe, als einen kurzen Einzeiler in Brainfuck.

Formal korrekt und funktioniert reicht nicht. Man muss auch 3 Sekunden nach dem Abspeichern noch nachvollziehen können, was man da gemacht hat 👿