AW: XEx in die Quellcodeformatierung "eingreifen"?
Zitat:
|
AW: XEx in die Quellcodeformatierung "eingreifen"?
Zitat:
Delphi-Quellcode:
gesucht werden muss. Der Formatierer müsste also eine Art Look-Ahead implementieren. Das macht aber soweit ich weiß keiner (zumindest nicht in dem Umfang).
else
|
AW: XEx in die Quellcodeformatierung "eingreifen"?
Zitat:
|
AW: XEx in die Quellcodeformatierung "eingreifen"?
Ich bin immer noch für
Delphi-Quellcode:
geht mit dem (eingebauten) Codeformatter, wenn
if
IsSomething or ( SomeValue < 0 ) then begin foo; end else begin bar; end;
Delphi-Quellcode:
:stupid:
if // ein Kommentar
Zitat:
|
AW: XEx in die Quellcodeformatierung "eingreifen"?
Zitat:
Mittlerweile ist es mir vollkommen wurscht, wie jemand formatiert. Wenn es mir nicht gefällt, dann formatiere ich es um. Rein persönlich formatiere ich so, das ich nicht allzuviele Zeilen vergeude, speziell einzelne 'then' und 'begin' finde ich überflüssig, weil sie noch ne Zeile hinzufügen. Wenn ich Scrollradproduzent wäre, oder Mittelfingerorthopäde, dann würde ich das toll finden, aber bin ich nicht. Es ist nicht weniger lesbar, wenn so ein 'then begin' am Ende einer Zeile steht. Eigentlich ist das 'then' ja überflüssig, also ein Füllwort. Also kann das auch ans Ende der Zeile. Na ja, und so ein 'begin'... klar, kann man isoliert auf eine einzelne Zeile packen, aber wozu? Bringt doch auch kein Mehr an Lesbarkeit. Ohne Indentierung würde ich natürlich anders denken, aber da die folgenden Zeilen alle eingerückt sind und max 5 Zeilen später eh das 'end' steht, ist das doch wurscht, ob das begin nun irgendwo sichtbar ist. Was ich ganz grauslich finde, ist das Ausrichten von Zuweisungen, also z.B.:
Delphi-Quellcode:
Da bekommt der Lesefluss sofort einen Schluckauf. Hab ich aber alles früher auch gemacht. Mittlerweile finde ich das vergeudete Zeit und sehr schlecht lesbar ist es auch. Parameterlistenausrichtung ist ähnlich behämmert, außer, für Leute, die nach Stunden bezahlt werden. Ich verwende meine Zeit lieber dafür, den Code durch Refaktorisierung und Befolgen der einschlägigen Regeln selbstdokumentierend zu machen und überlege mir lieber 2x, wie ich einen Bezeichner nenne, damit mein Partner ihn versteht, als mir zu überlegen, ob das 'begin' auf ne neue Zeile kommt oder nicht. Gut, dafür gibbet ja Formatier-O-Maten, insofern ist das Erdbeereis vs. Schoko (also Geschmackssache).
a.... := 123; // Punkt duch Leerzeichen ersetzen
b1234 := 45; Das einzige, was hier zählt, ist doch, das sich alle im Team einig sind und man ein Formatierungstool hat, was sich so einstellen lässt. Wer heute noch per Hand Code hin und herschubst, der hat echt zu viel Zeit. Aber am aller aller Schlimmsten finde ich mittlerweile die Verwendung von Präfixen, um den Datentyp von Bezeichnern zu kodieren ('bFlag', 'iCounter' usw). Wozu das gut sein soll, in Zeiten einer modernen IDE, frage ich mich wirklich. Zu 99% ergibt sich der Datentyp aus dem Kontext und die restlichen 1% sind fast immer schlechter Code bzw. ein falscher Bezeichner. |
AW: XEx in die Quellcodeformatierung "eingreifen"?
Zitat:
Wenn du Probleme hast auf einen Blick den Else-Teil zu erfassen, dann liegt das einfach daran dass du zuviel Code im Then-Teil hast. Oder wenn die If-Bedingung nicht in maximal 2 Zeilen passt dann macht man etwas falsch. Hier mal ein kleines Beispiel:
Delphi-Quellcode:
Diese If-Abfrage ist mit einer Zeile noch überschaubar, aber man braucht einen Kommentar um zu verstehen was das Ganze eigentlich soll.
begin
// prüfe ob Land in franz. Überseegebiet liegt if country='GP' or country='MQ' or country='RE' or country='GF' or country='PM' then begin ... Und hier die verbesserte Variante:
Delphi-Quellcode:
Insgesamt ist es mehr Code aber man braucht keinen Kommentar mehr um zu verstehen was da passiert.
function IsFrenchOversea(const country:string): boolean;
const ll : array[0..4] of string = ( 'GP', // Guadelupe 'MQ', // Martinique 'RE', // Réunion 'GF', // French Guyana 'PM' // Saint Pierre & Miquelion ); begin Result := StrIsOneOf(country, ll); end; begin if IsFrenchOversea(country) then begin ... Eigentlich wollte ich ein Beispiel bringen mit über 20 Teilbedingungen aber das war mir zu viel Schreibarbeit. Also wenn eine If-Bedingung zu komplex oder zu lang wird dann packt man sie in eine Unterfunktion! Das Gleiche gilt auch für den Then-Teil oder den Else-Teil. Wenn es zuviele Zeilen werden dann ist das ein Zeichen dass hier etwas faul ist ("der Code stinkt"). Dann heisst es die vielen Codezeilen in Unterfunktion auszulagern. Zitat:
Ich kann nur empfehlen die Ursache abzustellen, dann braucht du auch keinen Codeformatierer. |
AW: XEx in die Quellcodeformatierung "eingreifen"?
Ich dachte grade eine vollkommen selbst definierbare Code-Formatierung sei so ziemlich das Highlight von gexperts?
|
AW: XEx in die Quellcodeformatierung "eingreifen"?
Zitat:
|
AW: XEx in die Quellcodeformatierung "eingreifen"?
Zitat:
|
AW: XEx in die Quellcodeformatierung "eingreifen"?
Zitat:
Oder so:
Delphi-Quellcode:
uses System.StrUtils; ... // prüfe ob Land in franz. Überseegebiet liegt if MatchStr(country, ['GP', 'MQ', 'RE', 'GF', 'PM']) then ... |
Alle Zeitangaben in WEZ +1. Es ist jetzt 06:23 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz