Code-Formatierung

Programmiersprachen, APIs, Bibliotheken, Open Source Engines, Debugging, Quellcode Fehler und alles was mit praktischer Programmierung zu tun hat.
Antworten
Benutzeravatar
starcow
Establishment
Beiträge: 523
Registriert: 23.04.2003, 17:42
Echter Name: Mischa Schaub
Kontaktdaten:

Code-Formatierung

Beitrag von starcow »

Tach Zusammen (-:

Ich hab mich eben gefragt, wie man eigentlich sein Code formatieren sollte? Sehe ich das richtig, dass man heutzutage nicht länger ANSI verwenden sollte, sondern ausschliesslich UTF-8? Ist dann UTF-8 mit BOM oder ohne zu wählen - resp. gibt es einen Grund, weshalb das eine dem anderen vorzuziehen ist? Wie handhabt ihr das?
Etwas verwandt auch die Frage, ob man für den Zeilenumbruch nur "LF" oder "LFCR" verwenden sollte. Code wird ja oft auf verschiedenen Plattformen betrachtet und allenfalls bearbeitet. Hat man sich da, im Bereich der Programmierung auf etwas geeinigt?

Eine andere Frage, bei welcher ich immer etwas unsicher werde:
Sollte man anstelle des Tabulators einfach vier Leerzeichen verwenden und seinen Editor entsprechend so konfigurieren? Ich sehe das ziemlich oft.
Oder ist vielleicht von dieser Praxis eher abzuraten und man sollte stattdessen den richtigen Tab-Charakter verwenden? Bei Makefiles funktionieren ja ausschliesslich "echte" Tab-Characters - zumindest mit den Standardeinstellungen.
Zudem weiss ich auch nicht, ob Leerzeilen ebenfalls Tab-Einrückungen bekommen sollten. So, dass sie nachher die selbe Einrückung aufweisen, wie der unmittelbare Kontext. Einige Programme ergänzen das ja automatisch.

Beispiel:

Code: Alles auswählen

if(true){
    int x = 0;
    // sollte eine Leerzeile wie diese komplett leer bleiben oder die selbe Einrückung aufweisen (ob mit Tab oder Spaces),
    // wie die benachbarten Zeilen?
    i++;
}
Gruss starcow
Freelancer 3D- und 2D-Grafik
mischaschaub.com
Benutzeravatar
Lord Delvin
Establishment
Beiträge: 574
Registriert: 05.07.2003, 11:17

Re: Code-Formatierung

Beitrag von Lord Delvin »

Kommt jetzt auf die Sprache an.
Falls möglich UTF-8, kein BOM, nur '\n'.
Falls C++, clang-format:

Code: Alles auswählen

BasedOnStyle: LLVM
IndentWidth: 4
UseTab: Never
ContinuationIndentWidth: 2
ConstructorInitializerAllOnOneLineOrOnePerLine: true
BreakConstructorInitializers: AfterColon
ConstructorInitializerIndentWidth: 2
Bei Formattersettings ist aber immer viel persönliches Empfinden im Spiel :)
In Java habe ich sehr gute Erfahrungen damit gemacht, "? :" hart wie if-then-else umzubrechen.
XML/JSON/EMF in schnell: OGSS
Keine Lust mehr auf C++? Versuche Tyr: Get & Get started
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Code-Formatierung

Beitrag von Krishty »

Auf Linux: Nur UTF-8 + LF. Was anderes gibt es da ja kaum.

Auf Windows: Mittlerweile auch UTF-8; CR+LF umstritten. Git konvertiert in seinen Standardeinstellungen LF automatisch zu CR/LF, falls du auf Windows arbeitest. Selbst wenn du lokal LF siehst, wird der nächste, der das Repository auf Windows pullt, dort CR+LF sehen.
MSBuild/Visual C++ haben Probleme, #error und #warning mit Sonderzeichen aus UTF-8-Dateien anzuzeigen.
Einige Projektdateien (Windows-Resource-Skripts) erfordern spezielle Kodierung.

Die Leerzeichen statt Tabs sind häufige Wahl, aber ich verfechte weiter Tabs für Einrückung und Leerzeichen für Ausrichtung. Tabs sind effizienter und lassen sich schneller anpassen. (Tab-Größe schnell auf 2 runter, wenn du was auf dem großen Beamer präsentierst, oder falls du für einen sehbehinderten Kollegen die Schriftgröße auf 300% hochdrehen musst.)

Clang-Format ist ein rieser Schritt auf dem Weg zur Utopie, dass jeder selber entscheiden kann, in welchem Stil ihm der Code angezeigt wird. Außerdem nimmt es einem viel nutzlose Arbeit ab (einfach alles in eine Zeile klatschen, speichern, wie von Zauberhand ist alles sauber formatiert). Leider habe ich immer wieder Fälle, in denen clang-format mit unterschiedlichen Stilen keinen stabilen Zustand findet; ist also nur anwendbar, wenn alle mit den gleichen Einstellungen arbeiten.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Tiles
Establishment
Beiträge: 1990
Registriert: 11.01.2003, 13:21
Kontaktdaten:

Re: Code-Formatierung

Beitrag von Tiles »

Mit Python kommst du eh nicht an Tabs vorbei. Da hast du mit Leerzeichen den Spass mit den Intendation Errors. Alles sieht eigentlich korrekt aus ...
Free Gamegraphics, Freeware Games https://www.reinerstilesets.de
Die deutsche 3D Community: https://www.3d-ring.de
Benutzeravatar
Jonathan
Establishment
Beiträge: 2352
Registriert: 04.08.2004, 20:06
Kontaktdaten:

Re: Code-Formatierung

Beitrag von Jonathan »

"Tabs for indentation, Spaces for alignment" ist die einzige richtige Variante :P

Mehrere Spaces zum Einrücken verwenden hat keinen einzigen Vorteil, aber viele Nachteile. In einer idealen Welt hätte man am liebsten ein Zeichen, dessen semantische Bedeutung eben eine Einrückungstiefe ist. Das gibt es nicht (zumindest nicht etabliert), also sind Tabs das nächstbeste. Verwendet man Spaces, kann man den Cursor z.B. auf eine dreiviertel-Einrückung positionieren, was keinerlei sinnvolle Bedeutung hat. Eine gute IDE würde das nicht zulassen und beim Navigieren zusammengehörige Spaces immer überspringen, in der Praxis funktioniert das nie wirklich. Bei Tabs kann jeder selber einstellen, welche Einrückungstiefe er schön findet, bei Spaces nicht. Außerdem machen Spaces natürlich die Codedateien nutzlos größer (das ist natürlich in der Praxis egal, aber elegant ist das halt auch einfach nicht). Für Spaces zur Einrückung sind also in allen Punkten schlechter, zumindest habe ich noch nie von einem Vorteil gehört.
Code ausrichten ist nicht das selbe wie Code einrücken, hat man also einen langen Funktionsaufruf über mehrere Zeilen und möchte diese schöner ausrichten, kann man dazu dann Spaces verwenden. Im Zweifelsfalle hat man dann also erst die passende Anzahl Tabs und dann nochmal Spaces. Aber das ist halt auch semantisch sinnvoll, weil es zwei unterschiedliche Dinge sind.

Zu Zeilenenden habe ich keine so extremistische Meinung, was aber auf jeden Fall gar nicht geht ist die automatische Konvertierung von git. Ein Versionsverwaltungssystem hat meine Inhalte unverändert zu speichern und soll bitteschön nicht ungefragt an irgendetwas herum pfuschen. Wer heutzutage mit Tools arbeitet, die nicht mit alle 3 Arten von Zeilenumbrüchen gleichberechtigt klar kommt lebt ohnehin noch in der Vergangenheit und sollte halt einen vernünftigen Editor verwenden. Man könnte sich jetzt überlegen, ob man die Bedeutung von Carriage Return, Line feed, oder beide zusammen semantisch netter findet, aber da wir ja nicht mehr mit Schreibmaschinen arbeiten scheint mir diese Diskussion nirgendwohin zu führen.
Lieber dumm fragen, als dumm bleiben!
https://jonathank.de/games/
Benutzeravatar
Schrompf
Moderator
Beiträge: 4838
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Code-Formatierung

Beitrag von Schrompf »

UTF8 ohne BOM, ansonsten hab ich keine Prinzipien mehr. Ich lese über Whitespace drüber, egal wieviel Leerzeichen, Tabs oder Zeilenumbrüche da jemand drinhaben will. Formatierungs-Zanken ist sowas von 2008.

Ein ordentlich konfiguriertes Clang-Format sorgt für Einheitlichkeit und Ruhe im Team. Dann ist gut.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
EyDu
Establishment
Beiträge: 100
Registriert: 24.08.2002, 18:52
Wohnort: Berlin
Kontaktdaten:

Re: Code-Formatierung

Beitrag von EyDu »

Kann ein automatisches Tool, eigentlich egal welches, zur Formatierung nur unterschreiben. Das macht das Leben einfacher und man muss sich um solche unwichtigen Sachen keine Gedanken machen. Außerdem kann man auch prima so sein gesamtes Projekt, oder alle seine Projekte, auf einen Schlag formatieren. Was sehr praktisch ist, wenn eine Formatierungsregel doch mal Quatsch ist.

Und wenn es um Projekte mit mehreren Entwicklern geht: In Git gibt es hooks für alle möglichen Aktionen, so dass man beim pullen automatisch in seine eigene Formatierung umwandelt und beim pushen wieder in den globalen Standard. Das funktioniert natürlich mal weniger gut, aber prinzipiell kann jeder so seine eigenen kleinen Eigenheiten pflegen ^^
Tiles hat geschrieben: 01.08.2021, 18:37 Mit Python kommst du eh nicht an Tabs vorbei. Da hast du mit Leerzeichen den Spass mit den Intendation Errors. Alles sieht eigentlich korrekt aus ...
Die Fehler bekommst du nur, wenn du Tabs und Spaces vermischt. Standard in Python sind vier Spaces pro Einrückungsebene.
Benutzeravatar
starcow
Establishment
Beiträge: 523
Registriert: 23.04.2003, 17:42
Echter Name: Mischa Schaub
Kontaktdaten:

Re: Code-Formatierung

Beitrag von starcow »

Danke für die interessanten Details, das ist schonmal sehr aufschlussreich!
UTF-8 ohne BOM scheint also definitiv die einzig vernünftige Entscheidung in dieser Hinsicht zu sein.
Finde auch die Argumentation für Tab-Characters - anstelle von Spaces - fürs Einrücken, sehr schlüssig. Dem werde ich mich gerne anschliessen.
Verstehe ich das jetzt richtig, dass CLan eine Art Empfehlung zu Formatierungsregeln abgibt?
Und sollte man denn nun eine reine Leerzeile ebenfalls Einrücken, wenn die Zeile ober- und unterhalb eingerückt ist?

Gruss starcow
Freelancer 3D- und 2D-Grafik
mischaschaub.com
Benutzeravatar
Schrompf
Moderator
Beiträge: 4838
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Code-Formatierung

Beitrag von Schrompf »

starcow hat geschrieben: 06.08.2021, 12:30 Und sollte man denn nun eine reine Leerzeile ebenfalls Einrücken, wenn die Zeile ober- und unterhalb eingerückt ist?
Die Frage ist herrlich :-) Als ob es den Compiler kümmern würde, ob in ner leeren Zeile noch ein paar Spaces stehen. Und Du als Mensch siehst es eh nicht, steht ja sonst nix drin.

CLang ist ein Compiler. Der ist entstanden, weil der GCC sich damals absurd protektorisch benommen hat. CLang hat im Gegenteil immer darauf geachtet, dass man die Teile auch alleinstehend als Funktionsbibliothek nutzen kann. Und das hat ein riesiges Feld an neuen Programmiersprachen, Tools und unterstützter Hardware geöffnet. Du hast nen komischen Chip zu Hause designt? Schreib nen Backend für CLang und Du kannst jede Programmiersprache dieser Welt darauf nutzen. Du hast ne neue Programmiersprache? Schreib eine Transformation in LLVM und Du kannst jeden Prozessor dieser Welt damit bespaßen. Und halt: Du willst Code-Strukturen in irgendner wirklich übel komplexen Sprache wie z.B. C++ analysieren? Also zum Beispiel plump die Einrückung jeder Zeile korrigieren? Dann nimm den CLang-Parserteil.

Und so ist auch z.B. Clang-Format entstanden: ein kleines Tool, um Code zu formatieren. Du gibst dem eine riesige Config-Datei, in der detailliert steht, wo die Zeile über Überlänge umgebrochen werden soll, wo ne Klammer von Leerzeichen begleitet wird oder nicht, und ob Du die Parameter einer Funktion auf jeweils ner eigenen Zeile mit der öffnenden Klammer ausgerichtet haben willst, falls die Gesamt-Zeilenlänge > 120 Chars ist. Du bestimmst also den Formatierungsstil, und das Tool zieht den Stil dann durch alle Files durch, die Du gestattest. Optional begrenzt auf geänderte Zeilen in alten Files, damit nicht jeder Detailfix in Legacy-Code das ganze File ändert.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Benutzeravatar
Tiles
Establishment
Beiträge: 1990
Registriert: 11.01.2003, 13:21
Kontaktdaten:

Re: Code-Formatierung

Beitrag von Tiles »

Dazu ergänzend: Den Compiler juckts nicht. Aber du kannst einen Commit damit relativ unleserlich machen. Das weiss ich aus eigener leidvoller Erfahrung. Denn die geänderten Leerzeilen werden bei einem Commit durchaus mit berücksichtigt. Auch wenn da nichts drin steht ausser die unsichtbaren Einrückungen. Deswegen am Besten vermeiden.

Leerzeichen ohne danach folgenden Inhalt auf der gleichen Zeile nennt man auch Whitespace. Das muss nicht in einer Leerzeile sein. Sondern zum Beispiel noch ein paar Tabs oder Leerzeichen hinter dem abschliessenden ; . Das produziert man echt leicht wenn man ein wenig im Code rumstochert. Es gibt für VS und VS Code Addons die dir automatisch den Whitespace beim speichern anzeigen oder gleich ganz begradigen. Das kann schon dazu führen dass die Files dann spürbar kleiner werden.

https://marketplace.visualstudio.com/it ... Visualizer
https://marketplace.visualstudio.com/it ... spaces2019
Free Gamegraphics, Freeware Games https://www.reinerstilesets.de
Die deutsche 3D Community: https://www.3d-ring.de
Benutzeravatar
starcow
Establishment
Beiträge: 523
Registriert: 23.04.2003, 17:42
Echter Name: Mischa Schaub
Kontaktdaten:

Re: Code-Formatierung

Beitrag von starcow »

Danke Schrompf, gut erklärt!

@Tiles
Danke für den Tipp, die Sache leuchtet ein.

Ich habe schon vermutet, dass es wohl nicht dramatisch falsch sein wird - wenn man es auf die eine - oder andere Weise handhaben würde.
Teilweise gibts dann aber auch einfach Konventionen - wie man es halt machen sollte (was dann ja auch meistens den einen oder anderen Grund hat).

Gruss starcow
Freelancer 3D- und 2D-Grafik
mischaschaub.com
Antworten