Die "richtige" Sourcecode Formatierung?

[Neutral General]

Zitat:

Zitat von Jumpy (Beitrag 1344550)

Ich dachte immer das end gehört zum begin (ausser beim try) und drum schreibe ich es auch auf eine Ebene.

Ein end gehört IMMER zu einem begin. Man kann es auch so sehen, dass nach einem then generell nur eine Anweisung stehen kann. Und begin/end ist eine Anweisung (die als Container für mehrere Anweisungen dient). begin-end kann auch komplett ohne if/for/while o.ä. im Code stehen. Sieht zwar seltsam aus, aber ist erlaubt und zeigt umso mehr, dass ein end immer zu einem begin gehört.

[nahpets]

Zitat:

Zitat von SProske (Beitrag 1344545)

Zitat:

Zitat von nahpets (Beitrag 1344530)

Delphi-Quellcode:

// Folgt auf ein If nur eine Anweisung, dann wird das ein Einzeiler, solange er nicht über ca. 80 Zeichen hinaus geht.
if ... then ...;

Und wenn du mal einen Haltepunkt auf die Anweisung setzen willst, ärgerst du dich über diese Anordnung und verteilst es wieder auf 2 Zeilen - richtig?

Das ich den Debugger benötige kommt so selten vor, dass ich damit leben kann. Und wenn, dann kommt der Haltepunkt auf die Zeile mit dem If, dann kann ich direkt sehen, was denn da so in den abzufragenden Variabeln der IF-Anweisung steht.

Den Debugger brauche ich fast nur, um bei einem Fehler, den ich nicht finde, die IDE beim Auftreten des Fehlers mir die Stelle zeigen zu lassen, an der der Fehler auftritt.

Keine Ahnung, was ich "falsch" mache, aber der Debugger ist bei mir das Teil, dass ich am wenigsten nutze ;-)

Eventuell liegt es auch daran, dass ich Programme immer mit Debuginfos und Map-Datei erstelle, die Fehlerbehandlung der Jedis nutze und von daher in der Fehlermeldung immer angezeigt bekomme, in welcher Unit und in welcher Quelltextzeile der Fehler aufgetreten ist. Daher brauche ich (kaum) mal den Debugger, um fündig zu werden.

Abgesehen davon sind die Kombination von If-Then-Befehl nur selten kürzer als ca. 80 Zeichen und ich schrieb ja, dass ich bei "langen" If-Anweisungen ein Begin-End folgen lasse und somit der Dreizeiler der Normalfall ist.

[-=ZGD=-]

Zitat:

Zitat von nahpets (Beitrag 1344552)

Abgesehen davon sind die Kombination von If-Then-Befehl nur selten kürzer als ca. 80 Zeichen und ich schrieb ja, dass ich bei "langen" If-Anweisungen ein Begin-End folgen lasse und somit der Dreizeiler der Normalfall ist.

:shock:

Case geht da nicht? :cry:

[Edit] Okay..Ich hab Zeilen gelesen..Sorry :)

[nahpets]

Zitat:

Zitat von Jumpy (Beitrag 1344550)

Ich habe so ein bißchen den Eindruck gewonnen, dass die Formatierung auch davon beeinflusst wird, in welchen Sprachen man noch so programmiert, sprich wie man in Java/C#/C++ die Klammern setzt, so setzt man begin/end in Delphi?

Da ist was dran, man hat mir mal (spasseshalber) vorgeworfen, ich würde in C++ Delphi-Code schreiben.

Oder sagen wir mal so: Ich schreibe Quelltext so wie ich Denke, der Quelltext bildet (meist) die Struktur meiner Gedankengänge (sofern ich denn mal welche habe ;-)) wieder.

Wer anders an eine Problemlösung herangeht, schreibt den Quelltext auch entsprechend. Und das finde ich absolut korrekt.
Es ist nicht hilfreich, wenn ich von anderen erwarte, dass sie ihren Quelltext so schreiben, dass er meiner Denkweise entspricht. Das wird (fast) immer schiefgehen, so wie ich Quelltexte nicht in der Denkstruktur anderer schreiben kann, da scheitere ich auch immer.

Pascal/Delphi ist die Sprache, in der es mir am Einfachsten fällt, logische Gedanken "zu Papier" zu bringen. Bei C++ /Java ... hab' ich immer den Eindruck, um das zu verstehen, muss ich rückwärts denken.

Kollegen, die eher und lieber in C++, Java ... programmieren, sagten mir mal, dass es ihnen bei Pascal/Delphi genauso geht.

Für mich ist bei der Quelltextformatierung wesentlich, dass sie mit der logischen Struktur des Programmierten "zusammenpasst". Der Rest ist eher "Beiwerk". In größeren Projekten und / oder Teams, sollten sich aber alle Beteiligten an eine einheitliche Form der Quelltextformatierung (aber auch der Vergabe von Variabel-, Funktions- ... und Sonstigesnamen) halten. Dadurch erscheint mir die Verständlichkeit von Quelltexten zu steigen.

[ChrisE]

[HUMOR]
Auf die ursprünglich Frage - Die "richtige" Sourcecocde Formatierung - kann es NUR eine Antwort geben -----> 42
[/HUMOR]

Greez, Chris

[Stevie]

Wenn man sich an Clean Code hält (was primär eigentlich nix mit der Formatierung des Codes zu tun hat), ergeben sich viele hier gezeigte Fälle erst gar nicht, weil Methoden nicht über zig if Bedingungen oder Verschachtelungen verfügen (z.B. Hallo Polymorphie und Strategie Pattern).

Auch so manch "cleveres" Code Konstrukt ließe sich weitaus einfacher schreiben, wenn man z.B. das Null Objekt Pattern anwenden würde.

Was die restliche Formatierung angeht, halte ich mich weitgehend an den Borland Guide und versuche so zu formatieren, dass ich den von der IDE generierten Code nicht noch ändern muss.

[p80286]

Zitat:

Zitat von Neutral General (Beitrag 1344551)

Ein end gehört IMMER zu einem begin. Man kann es auch so sehen, dass nach einem then generell nur eine Anweisung stehen kann. Und begin/end ist eine Anweisung (die als Container für mehrere Anweisungen dient). begin-end kann auch komplett ohne if/for/while o.ä. im Code stehen. Sieht zwar seltsam aus, aber ist erlaubt und zeigt umso mehr, dass ein end immer zu einem begin gehört.

Delphi-Quellcode:

case NeutralGeneral.isright of
  true : begin end;
  false :  NeutralGeneral.isright:=true;
end;

:zwinker:

Gruß
K-H

[-=ZGD=-]

Delphi-Quellcode:

case NeutralGeneral.isright of
  true: 
    begin 
     
    end;
  false: 
    begin
      NeutralGeneral.isright := true;
    end;
end;

wobei jeder Case bei mir ein ELSE haben muss :lol:

Delphi-Quellcode:

case NeutralGeneral.isright of  
  false: 
    begin
      NeutralGeneral.isright := true;
    end;
  else
    begin
    end;
end;

[Uwe Raabe]

Zitat:

Zitat von SProske (Beitrag 1344549)

Wieso sollte ich auf ein Exit keinen Haltepunkt setzen können/wollen?
Vielleicht interessiert es mich ja, ob das Exit während der Codeausführung überhaupt mal angesprungen wird (ohne bei jeder Prüfung anzuhalten).

Schon mal probiert?

[SProske]

Zitat:

Zitat von Uwe Raabe (Beitrag 1344564)

Schon mal probiert?

Klar - aber initial natürlich nur mit

Delphi-Quellcode:

if 1=1 then
  Exit;

Um jetzt festzustellen, dass es nicht mehr klappt, wenn da irgend etwas sinnvolles steht - cooles Feature ~.~

[Uwe Raabe]

Zitat:

Zitat von SProske (Beitrag 1344566)

Um jetzt festzustellen, dass es nicht mehr klappt, wenn da irgend etwas sinnvolles steht - cooles Feature ~.~

Der Compiler macht daraus einfach einen bedingten Sprung ans Ende der Methode. Es gibt also keinen Assembler-Befehl, wo dieses Exit wirklich ausgeführt wird und der Debugger davor anhalten könnte. Analog gilt das auch für Break und Continue.

[p80286]

Zitat:

Zitat von -=ZGD=- (Beitrag 1344563)

Delphi-Quellcode:

case NeutralGeneral.isright of
  true: 
    begin 
     
    end;
  false: 
    begin
      NeutralGeneral.isright := true;
    end;
end;

wobei jeder Case bei mir ein ELSE haben muss :lol:

Delphi-Quellcode:

case NeutralGeneral.isright of  
  false: 
    begin
      NeutralGeneral.isright := true;
    end;
  else
    begin
    end;
end;

Mmmm, Spaß bei Seite, das wiederum zeigt wie unterschiedlich man auch so eine simple Sache angehen kann, ohne etwas grundlegend falsch zu machen.
(könnte man uU auch bei der Formatierung so sehen; aber ein paar andere Sichtweisen können ja nicht schaden)


Gruß
K-H

[Mavarik]

Zitat:

Zitat von Lemmy (Beitrag 1344543)

um das Hirn bei der "Mustererkennung" zu entlasten

Das ist für mich der absolut wichtigste Punkt...

Eine Code-Zeile wir i.d.R.

1x geschrieben
10x gelesen

Also ist ganz klar, ich muss mich entlasten...
Das geht natürlich über die Formatierung hinaus... Dafür braucht es Regeln (Ganz alleine für mich)

Argumente haben ein A-davor...

Also

Delphi-Quellcode:

Procedure (Const AValue : String);
begin
end;

Setter haben immer eine AValue egal von welchen typen.
Array Getter und Setter haben immer INDEX <- auch in Capslock geschrieben damit es auffällt.

Type immer ein T
Interfaces immer ein I
Lokale Variablen immer ein L... (Außer unsere geliebte For-Schleifen-Variable (i) )
Früher hatten Records immer ein Typ dahinter Datum : DatumsTyp; Zeit : ZeitTyp; (Aus UCSD-Pascal Zeiten)

Bei einer Zeile

Wert := Werte;

Was ist da Werte?

Wert := Werte(); // Klar
Wert := IWerte; // Klar;
Wert := AValue; // Auch klar

Generische Parameter heißen Arg1 Arg2 Arg3
Generische Record Bestandteile heißen Item1, Item2, Item3
Generische Typen heißen <T> oder es wird die Funktionalität bezeichnet <TResult>, <TArg>, <TSource>, <TDestination>

usw...

vor und nach einem " := " kommt eine Leertaste
Das letzte end; <- hat auch ein ";" auch wenn es nicht gebraucht wird.

Von Oliver übernommen

"( Parameter : Integer )" vor und nach den () von Parametern eine Leertaste.
"{}" Als Augenpunkt: Hier geht es weiter und damit der Autoformatter die Zeile nicht ändert.


Dann noch die praktischen Sachen..

Delphi-Quellcode:

Uses
  System.SysUtils
  ,Unit1
  ,Unit2
  ;

Einfacher um mal eben eine Unit mit // aus zu schalten...

Ich könnte noch ewig so weiter machen - stelle ich gerade fest...

Mavarik :coder:

[-=ZGD=-]

Zitat:

Zitat von p80286 (Beitrag 1344582)

Zitat:

Zitat von -=ZGD=- (Beitrag 1344563)

Delphi-Quellcode:

case NeutralGeneral.isright of
  true: 
    begin 
     
    end;
  false: 
    begin
      NeutralGeneral.isright := true;
    end;
end;

wobei jeder Case bei mir ein ELSE haben muss :lol:

Delphi-Quellcode:

case NeutralGeneral.isright of  
  false: 
    begin
      NeutralGeneral.isright := true;
    end;
  else
    begin
    end;
end;

Mmmm, Spaß bei Seite, das wiederum zeigt wie unterschiedlich man auch so eine simple Sache angehen kann, ohne etwas grundlegend falsch zu machen.
(könnte man uU auch bei der Formatierung so sehen; aber ein paar andere Sichtweisen können ja nicht schaden)


Gruß
K-H

Definitiv gibt es zig verschiedene Arten.
Das mit dem ELSE war kein Spaß.

[p80286]

Spaß bezog sich auch eher auf NeutralGeneral.IsRight


Gruß
K-H

[Lemmy]

Zitat:

Zitat von -=ZGD=- (Beitrag 1344563)

[DELPHI]
wobei jeder Case bei mir ein ELSE haben muss :lol:

Delphi-Quellcode:

case NeutralGeneral.isright of  
  false: 
    begin
      NeutralGeneral.isright := true;
    end;
  else
    begin
    end;
end;

ähm... du meinst hoffentlich eher:

Delphi-Quellcode:

case NeutralGeneral.isright of  
  false: 
    begin
      NeutralGeneral.isright := true;
    end;
  true: 
    begin
    end
  else
    begin
      raise Exception.Create();
    end;
end;

so schnell wird Spaß zum Ernst des Lebens ;-)

Zitat:

Zitat von Mavarik (Beitrag 1344585)

Zitat:

Zitat von Lemmy (Beitrag 1344543)

um das Hirn bei der "Mustererkennung" zu entlasten

Das ist für mich der absolut wichtigste Punkt...

Eine Code-Zeile wir i.d.R.

1x geschrieben
10x gelesen

eben, und mind. 5x von anderen. Sprich: Ich schreibe / formatiere Code weniger für mich und schon gar nicht für den Compiler, sondern für andere. Und je besser die mit meiner Lösung klar kommen, desto eher besteht die Chance, dass Fehler gefunden werden bzw. sie meinen Code weiter nutzen und damit steigt die Chance dass am Ende Geld gespart wird....

[Stevie]

Zitat:

Zitat von Mavarik (Beitrag 1344585)

Bei einer Zeile

Wert := Werte;

Was ist da Werte?

Wert := Werte(); // Klar
Wert := IWerte; // Klar;
Wert := AValue; // Auch klar

Bei dieser Argumentation, die ich schon oft gesehen habe, frage ich mich immer:
Welche Information bringt es mir, zu sehen, von welcher Art der rechte Ausdruck ist - imo ist diese Information unnötig und in der Regel nicht notwendig.
Da man normalerweise seine Elemente vernünftig benennt (und ich meine nicht mit nem Prefix, obs ein Parameter, lokale Variable oder sonst was ist, sondern das, was dieses Element an Daten enthält), ergibt sich die Frage, ob ich eine Funktion aufrufe oder aus einer lokalen Variable oder einem Parameter den Wert hole, beim Lesen nicht.

Zitat:

Zitat von Mavarik (Beitrag 1344585)

Dann noch die praktischen Sachen..

Delphi-Quellcode:

Uses
  System.SysUtils
  ,Unit1
  ,Unit2
  ;

Einfacher um mal eben eine Unit mit // aus zu schalten...

Bei dieser Formatierung frage ich mich immer, was daran nun einfacher auszuschalten ist, als bei:

Delphi-Quellcode:

uses
  System.SysUtils,
  Unit1,
  Unit2;

Bei deiner kannst du SysUtils nicht einfach rausnehmen, da dann das Komma vor Unit1 stört, bei meiner nicht Unit2, da dann das Semikolon fehlt. In beiden Fällen gibt es eine Zeile, die nicht funktioniert. Und in beiden Fällen kann man die Units ein einer solchen Reihenfolge schreiben, dass die problematische Zeile eine ist, die man in den meisten Fällen nicht auskommentieren möchte (ok, wenn nun in Unit1 oder Unit2 Symbole aus SysUtils verdeckt werden, dann hat man bei einer Umordnung natürlich gelitten, aber wer macht sowas schon :roll:).

[Mavarik]

Zitat:

Zitat von Stevie (Beitrag 1344592)

Bei dieser Argumentation, die ich schon oft gesehen habe, frage ich mich immer:
Welche Information bringt es mir, zu sehen, von welcher Art der rechte Ausdruck ist - imo ist diese Information unnötig und in der Regel nicht notwendig.

Ganz einfach...

1. Ich weiß sofort worum es geht ohne zu scrollen...
2. Wenn ich einen Funktionsaufruf sehe... Ist es eben keine einfache Zuweisung... Bedeutet bei einem Refactoring nach:

Delphi-Quellcode:

begin
  TTask.Run(Procedure
    begin
      Wert := Werte(); // Zugriff auf VCL???
    end;
end;

Muss ich nachsehen, ob darin nicht etwas steht wie:

Delphi-Quellcode:

Function Werte : Integer;
begin
  Caption := 'Wert geholt';
  Result := 42;
end;

Zitat:

Zitat von Stevie (Beitrag 1344592)

Bei deiner kannst du SysUtils nicht einfach rausnehmen, da dann das Komma vor Unit1 stört, bei meiner nicht Unit2, da dann das Semikolon fehlt. In beiden Fällen gibt es eine Zeile, die nicht funktioniert. Und in beiden Fällen kann man die Units ein einer solchen Reihenfolge schreiben, dass die problematische Zeile eine ist, die man in den meisten Fällen nicht auskommentieren möchte

Na warum soll ich auch Sysutils raus nehmen... Das steht doch mit Sicherheit da, weil es gebraucht wird..
Wenn ich also eine Liste habe kann ich einfach "meine" Units raus nehmen...

Delphi-Quellcode:

Uses
  System.SysUtils
//  ,Unit1
  ,Unit2
  ;

Delphi-Quellcode:

Uses
  System.SysUtils
  ,Unit1
//  ,Unit2
  ;

Delphi-Quellcode:

Uses
  System.SysUtils
//  ,Unit1
//  ,Unit2
  ;

Klasse oder?

Mavarik :coder:

[Stevie]

Zitat:

Zitat von Mavarik (Beitrag 1344594)

1. Ich weiß sofort worum es geht ohne zu scrollen...
2. Wenn ich einen Funktionsaufruf sehe... Ist es eben keine einfache Zuweisung... Bedeutet bei einem Refactoring nach:

Nonsense Code gewinnt imo keinen Punkt bei dieser Argumentation, weil:
1. unpassender Name, der nämlich genau dazu führt, dass ich nachschauen muss, was sie macht -> sowieso schlecht
2. Funktion macht mehr als eine Sache (was wiederum dazu verleitet ihr einen prägnanten/unaussagekräftigen Namen zu geben)

Zitat:

Zitat von Mavarik (Beitrag 1344594)

Klasse oder?

Wie erwähnt, dann stell ich bei mir eine Unit nach unten, die ich aller Wahrscheinlichkeit nach nicht herausnehme, und habe dasselbe erreicht.

[p80286]

Das mit den Units, mache ich genauso wie Mavarik, wobei man bei der ersten Unit natürlich gekniffen ist.
Man kann halt nicht alles haben.

Zitat:

Zitat von Stevie (Beitrag 1344599)

1. unpassender Name, der nämlich genau dazu führt, dass ich nachschauen muss, was sie macht -> sowieso schlecht

Dann gehörst du aber zu sehr glücklichen Menschen, die gleich bei der ersten Eingabe direkt wissen, was der treffende Name ist. Ich brache immer 2 ode drei Überarbeitungen, bis alles so ist, daß ich auch in einem Jahr noch verstehe wie der Code funktioniert.

Gruß
K-H

[Stevie]

Zitat:

Zitat von p80286 (Beitrag 1344602)

Dann gehörst du aber zu sehr glücklichen Menschen, die gleich bei der ersten Eingabe direkt wissen, was der treffende Name ist. Ich brache immer 2 ode drei Überarbeitungen, bis alles so ist, daß ich auch in einem Jahr noch verstehe wie der Code funktioniert.

Nö, bestimmt nicht, ich verbringe einen großen Teil meiner Zeit damit, meinen eigenen (gestern natürlich noch von mir selbst fälschlicherweise als perfekt bewerteten :roll:) oder fremden Code zu refactorn :)

[Neutral General]

Zitat:

Zitat von p80286 (Beitrag 1344602)

Das mit den Units, mache ich genauso wie Mavarik, wobei man bei der ersten Unit natürlich gekniffen ist.

Wenns bei einer Unit eh nicht funktioniert, dann kann man in meinen Augen auch so machen wie Stevie.
Das sieht visuell zumindest ordentlicher aus in meinen Augen. So ein Komma als Anfang der Zeile vor einem Wort sieht komisch aus.

[p80286]

Zitat:

Zitat von Neutral General (Beitrag 1344605)

Wenns bei einer Unit eh nicht funktioniert, dann kann man in meinen Augen auch so machen wie Stevie.
Das sieht visuell zumindest ordentlicher aus in meinen Augen. So ein Komma als Anfang der Zeile vor einem Wort sieht komisch aus.

Ungewohnt, aber ich mach es bei selects genauso, und da ist es meiner Meinung nach sehr hilfreich um fehlende Kommata zu finden

SQL-Code:

select feld1
      ,feld2
      ,feld3 as Umsatz
      ,feld5 as Rabatt
from tabelle1.....

und nach der Syntax gehört das Komma zur zweiten Unit.

Gruß
K-H

[madas]

Zitat:

Zitat von jaenicke (Beitrag 1344535)

Für mich sind bei der Formatierung wichtig:

• Zwingend per Codeformatter machbar (nur manuell formatieren können ist Blödsinn, das dauert viel zu lange, wenn ich fremden Quelltext einpflegen muss usw.)
• Weite Verbreitung der Formatierung, keine Sonderlocken
• Natürliches Schreiben: keine tausend unnötige Leerzeichen oder ähnliches
• Ein Befehl pro Zeile (damit man nicht erst die ganze Zeile durchlesen muss um weiterzulesen)
• Pro logischer Ebene eine Einrückung um zwei Zeichen nach rechts
• Kein Plenken

Das macht die Standardformatierung bereits, deshalb gibt es für mich keinen Grund eine andere zu benutzen. Zumal dies die häufigste Formatierung ist, wenn man so Open Source usw. anschaut. Alles andere ist eher selten bis exotisch zu finden.

Wegen des begin in einer Zeile:
Ich empfinde es als unsauber, wenn mehrere Befehle in eine Zeile gequetscht werden. Da läuft man nur in Gefahr etwas zu überlesen.

Sehe ich auch so.

Delphi-Quellcode:

if (Bedingung) then
  Anweisung;

if (Bedingung) then
begin
  Anweisung;
end;

if (Bedingung) then
begin
  Anweisung1;
end else
begin
  Anweisung2;
end;

if (Bedingung1) then
begin
  Anweisung1;
end else
if (Bedingung2) then
begin
  Anweisung2;
end;

Delphi-Quellcode:

procedure NamenSindGanzWichtig;
begin
  Anweisung;
end;

procedure NamenSindGanzWichtig;
var
  blaBla: String;
begin
  Anweisung;
end;

usw. usw.

[bernau]

Mal ne andere Sache.

Seit in Delphi vermehrt Unit-Scopenames verwendet werden, wird die Units-Deklaration immer größer.

Früher sah es so aus:

Delphi-Quellcode:

uses
  Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
  StdCtrls, Dateedit, Buttons, ExtCtrls;

Jetzt sieht es so aus:

Delphi-Quellcode:

uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, Vcl.Graphics, Vcl.Forms, Vcl.Dialogs,
  Vcl.StdCtrls, Vcl.Controls, Vcl.Buttons, Vcl.ExtCtrls, System.Classes,

Vorher schon unübersichtlich. Jetzt ganz unübersichtlich.

Stelle jetzt meine Units auf folgende Schreibweise um.

Delphi-Quellcode:

uses
  Winapi.Windows, 
  Winapi.Messages, 
  System.SysUtils, 
  System.Classes,
  Vcl.Graphics, 
  Vcl.Forms, 
  Vcl.Dialogs,
  Vcl.StdCtrls, 
  Vcl.Controls, 
  Vcl.Buttons, 
  Vcl.ExtCtrls;

Sinnvoll oder nicht?

Wie handhabt Ihr das?

[uligerhardt]

Zitat:

Zitat von bernau (Beitrag 1344700)

Stelle jetzt meine Units auf folgende Schreibweise um.

Delphi-Quellcode:

uses
  Winapi.Windows, 
  Winapi.Messages, 
  System.SysUtils, 
  System.Classes,
  Vcl.Graphics, 
  Vcl.Forms, 
  Vcl.Dialogs,
  Vcl.StdCtrls, 
  Vcl.Controls, 
  Vcl.Buttons, 
  Vcl.ExtCtrls;

Sinnvoll oder nicht?

Wie handhabt Ihr das?

Hab ich schon immer so gemacht. :mrgreen:

[Stevie]

Bei Forms und allem, wo mir die IDE Units reinkleistert, lass ich es so, in reinen Sourcecode Units untereinander.

[Benedikt Magnus]

Ich sortiere sie ein wenig, um es übersichtlicher zu gestalten:

Delphi-Quellcode:

uses
  { Standard }
    System.SysUtils, System.Types, System.UITypes, System.Classes, System.Variants,
    FMX.Types, FMX.Graphics, FMX.Controls, FMX.Forms, FMX.Dialogs, FMX.StdCtrls,
  { Indy }
    IdIOHandler, IdIOHandlerSocket, IdBaseComponent, IdComponent,
    IdTCPConnection, IdTCPClient, IdHTTP,
    IdCookieManager
  { Indy SSL }
    IdIOHandlerStack, IdSSL, IdSSLOpenSSL,
  { Eigen }
    Unit_HTTP, Unit_HTTPS, Unit_Modulverarbeitung
  {};

Edit: Wie die Sortierung/Gruppierung letztlich aussieht, hängt immer vom Projekt ab. Häufig teile ich Standard noch in System/GUI/Sonstiges oder Eigen ab einer gewissen Unitzahl in Spezifischeres auf.

[mjustin]

Woher kommt eigentlich dieses lästige und überflüssige A am Anfang von Parametern (z.B. "AValue")?

Im Delphi Style Guide ( http://edn.embarcadero.com/article/10280) ist es nicht zu finden.

Im Delphi Sourcecode - z.B. http://docwiki.embarcadero.com/Libra...ysUtils.Format - wird es nicht verwendet.

Handelt es sich um eine Modeerscheinung? ;)

[Stevie]

Im Delphi Source findet man das durchweg an vielen Stellen - wird aber nicht konsequent durchgezogen, aber schau mal in Classes.pas z.B.
Da Delphi nunmal nicht case sensitiv ist, bietet es sich an, Parameter zu prefixen, damit es keine potenziellen Namenskollisionen gibt.

[jaenicke]

Zitat:

Zitat von Benedikt Magnus (Beitrag 1344711)

Ich sortiere sie ein wenig, um es übersichtlicher zu gestalten:

Delphi-Quellcode:

uses
  { Standard }
    System.SysUtils, System.Types, System.UITypes, System.Classes, System.Variants,
[...]
  { Eigen }
    Unit_HTTP, Unit_HTTPS, Unit_Modulverarbeitung
  {};

Das mache ich auch so. Meistens als Delphi, 3rd-Party, Common (das sind unsere gemeinsamen Units für alle Projekte) und Project unterteilt. Wir benutzen auch Common als Namespace für diese gemeinsamen Units und einen projektspezifischen für die Units im Projekt. So kann dann eine Unit zum Beispiel heißen Common.Utils.StringTools.pas. Diese liegt dann im Verzeichnis common/utils im Repository. Und darin befindet sich eine gleichnamige Klasse TStringTools.
Interfaces liegen in einem Unterordner Interfaces und heißen dann z.B. Common.Interfaces.Utils.StringTools.pas.

So findet man zu Klassen und Interfaces schnell den Unitnamen und auch das Verzeichnis, in dem die Unit liegt.

Das finde ich sehr viel sinnvoller als ein Unit_ oder ähnliches voranzustellen. Denn dass es eine Unit ist, weiß ich auch so. Durch den Namespace Common weiß ich, dass es eine gemeinsame Unit ist, die nicht in das Projekt eingebunden sein muss um benutzt zu werden. (Die werden bei uns separat kompiliert.)
Ich habe also eine Mehrinformation, was bei Unit_ nicht der Fall ist. (Es sei denn du machst das genauso, nur mit Unit_ und Project_, was dann aber erst recht für Namespaces spräche.)

Vom Untereinanderschreiben halte ich wenig. Entweder sind es so wenige Units, dass man sie eh überblickt, oder es sind (z.B. in einem Datasnap oder FireDAC Datenmodul) so viele, dass sie untereinander geschrieben auch nicht leichter überschaubarer sind.

Dazu kommt, dass Error Insight ja anzeigt, wenn eine Unit fehlt. Leider kommt dazu ein Störrauschen von falschen Meldungen, aber wenn man sich dran gewöhnt hat, lassen sich diese recht gut von echten Meldungen unterscheiden. Wenn es zu viele falsche sind, bringt es natürlich nichts mehr.

Zitat:

Zitat von mjustin (Beitrag 1344719)

Woher kommt eigentlich dieses lästige und überflüssige A am Anfang von Parametern (z.B. "AValue")?
[...]
Im Delphi Sourcecode - z.B. http://docwiki.embarcadero.com/Libra...ysUtils.Format - wird es nicht verwendet.

Das wird im Quelltext der RTL und VCL durchaus häufig verwendet wie Stevie schon sagte, prominentestes Beispiel ist der Konstruktor einer Komponente:
http://docwiki.embarcadero.com/Libra...mponent.Create

Ich benutze das A auch, weil Parameter einer Methode so eindeutige Namen bekommen. Denn Test als Name des Paramaters würde zwar funktionieren, wäre aber sehr unsauber, weil die Property auch so heißt:

Delphi-Quellcode:

type
  TExample = class
  private
    FTest: Integer;
  public
    constructor Create(const ATest: Integer);
    property Test: Integer read FTest write FTest;
  end;

constructor TTest.Create(const ATest: Integer);
begin
  FTest := ATest;
end;

Und daher finde ich es sehr sinnvoll durchweg das A als Prefix zu verwenden.

[Sherlock]

Zitat:

Zitat von mjustin (Beitrag 1344719)

Woher kommt eigentlich dieses lästige und überflüssige A am Anfang von Parametern (z.B. "AValue")?

Im Delphi Style Guide ( http://edn.embarcadero.com/article/10280) ist es nicht zu finden.

Im Delphi Sourcecode - z.B. http://docwiki.embarcadero.com/Libra...ysUtils.Format - wird es nicht verwendet.

Handelt es sich um eine Modeerscheinung? ;)

Vermutlich kommt das daher, um unsaubere Kapselung und reichlich globale Variablen weiter führen zu können (nicht das Verfechter dieser Notation sowas tun würden, schon gar nicht unsere werten Mitforisten, ich denke aus dieser Not heraus wurde diese Notation geboren, das ist alles). Genauso gibt es ja noch die "kleines L" vor lokale Variablen Fraktion - ummm... li, anyone?. Ich halte es mit einem gesunden Mittelmaß: das "a" für Argument nehme ich gerne mit, das ist auch in den "offiziellen" Delphi Units so. Das "l" verkneif ich mir genauso wie den Typ der Variablen (egal ob infix oder postfix, sonst müsste ich mir bei ii jedesmal Gedanken machen, was nun Name und was Typ ist), Felder von Klassen bekommen wiederum ein "f" vorangestellt, dann weiß ich woran ich bin. Meiner Meinung nach muss ein Bezeichner lesbar sein, dann erübrigt sich auch ihm mitzugeben, daß er lokal ist und welchen Typ er hat. Letzteres erledigt die IDE ja ohnehin schon im Mouseover. Ersteres ergibt sich aus der Kürze der Methode.

Sherlock

[Benedikt Magnus]

Zitat:

Zitat von jaenicke

Das finde ich sehr viel sinnvoller als ein Unit_ oder ähnliches voranzustellen. Denn dass es eine Unit ist, weiß ich auch so. Durch den Namespace Common weiß ich, dass es eine gemeinsame Unit ist, die nicht in das Projekt eingebunden sein muss um benutzt zu werden. (Die werden bei uns separat kompiliert.)
Ich habe also eine Mehrinformation, was bei Unit_ nicht der Fall ist. (Es sei denn du machst das genauso, nur mit Unit_ und Project_, was dann aber erst recht für Namespaces spräche.)

Es hat in etwa den gleichen Zweck wie dein Namespace Common.
Diese Art der Bezeichnung stammt noch aus meiner ganz frühen Lernphase, und da erschien mir das als Abgrenzung zu den Standardunits (damals unter Delphi 5/7) vernünftig, denn bei all den Komponenten habe ich das ja auch so gemacht :-D (Form_Anmeldung, Button_Ablehnen...). Da ich aber noch nie so viele eigene Units in einem Projekt verwendet habe, dass ich Untergruppen bräuchte, bin ich seitdem auch nie auf Namespaces umgestiegen. Irgendwann, wenn ich mal ein wirklich großes Projekt habe, mache ich das vielleicht (ich habe es überlegt, als ich mir damals XE5 zugelegt hatte).

[p80286]

Zitat:

Zitat von Sherlock (Beitrag 1344735)

Vermutlich kommt das daher, um unsaubere Kapselung und reichlich globale Variablen weiter führen zu können (nicht das Verfechter dieser Notation sowas tun würden, schon gar nicht unsere werten Mitforisten, ich denke aus dieser Not heraus wurde diese Notation geboren, das ist alles).

Interessante Erklärung, es ist immer gut eine sachliche Begründung zu haben.

Zitat:

Zitat von jaenicke (Beitrag 1344732)

Durch den Namespace Common weiß ich, dass es eine gemeinsame Unit ist, die nicht in das Projekt eingebunden sein muss um benutzt zu werden.

Gute Anregung. Mir ist das uses oft zu unübersichtlich, das könnte helfen. Es muß ja nicht "common", "Herzstück" reicht auch.


Gruß
K-H

[jaenicke]

Zitat:

Zitat von Sherlock (Beitrag 1344735)

Vermutlich kommt das daher, um unsaubere Kapselung und reichlich globale Variablen weiter führen zu können

Das bezweifle ich. Ich habe ja das AOwner als Beispiel genannt. Da gibt es in der Klasse gleichzeitig noch Owner als Property. Und wenn man sich mal anschaut wo das noch auftauchte in älteren Quelltexten findest du noch weitere solche Fälle.

Einen Fall wie den von dir genannten sehe ich hingegen nirgends. Worauf beziehst du dich denn da? Im RTL oder VCL Quelltext meine ich.

Zitat:

Zitat von p80286 (Beitrag 1344754)

Gute Anregung. Mir ist das uses oft zu unübersichtlich, das könnte helfen. Es muß ja nicht "common", "Herzstück" reicht auch.

Das heißt bei uns Common.Core.XYZ bzw. Frontend.Core.XYZ usw. ;-)
Das macht auch mehr Sinn als ein deutscher Bezeichner... :kotz:

[Sherlock]

Zitat:

Zitat von jaenicke (Beitrag 1344763)

Zitat:

Zitat von Sherlock (Beitrag 1344735)

Vermutlich kommt das daher, um unsaubere Kapselung und reichlich globale Variablen weiter führen zu können

Das bezweifle ich. Ich habe ja das AOwner als Beispiel genannt. Da gibt es in der Klasse gleichzeitig noch Owner als Property. Und wenn man sich mal anschaut wo das noch auftauchte in älteren Quelltexten findest du noch weitere solche Fälle.

Einen Fall wie den von dir genannten sehe ich hingegen nirgends. Worauf beziehst du dich denn da? Im RTL oder VCL Quelltext meine ich.

Oh, ich habe das durchaus historisch gemeint. Nicht bezogen auf aktuell in der freien Wildbahn zu findende Quellen. Welchen Grund mag es sonst geben für einen Präfix, der ein Argument kennzeichnet? Heutzutage: keinen, außer "ham wir schon immer so gemacht". Vorausgesetzt natürlich, man hat ansonsten saubern Code (kurze Parameterlisten, kurze Methoden etc.)


Sherlock

[Mavarik]

Zitat:

Zitat von jaenicke (Beitrag 1344763)

Das macht auch mehr Sinn als ein deutscher Bezeichner... :kotz:

Wenn man nur Code für den deutschen Sprachraum schreibt mögen deutsche Bezeichner funktionieren.

Delphi-Quellcode:

begin
  HöreAufDemEinAusgangsKanal(10230);
end;

[jaenicke]

Zitat:

Zitat von Sherlock (Beitrag 1344769)

Welchen Grund mag es sonst geben für einen Präfix, der ein Argument kennzeichnet? Heutzutage: keinen, außer "ham wir schon immer so gemacht". Vorausgesetzt natürlich, man hat ansonsten saubern Code (kurze Parameterlisten, kurze Methoden etc.)

Wie sieht denn deine Alternative für mein Beispiel aus?

// EDIT:

Zitat:

Zitat von Mavarik (Beitrag 1344772)

Wenn man nur Code für den deutschen Sprachraum schreibt mögen deutsche Bezeichner funktionieren.

Das bezweifle ich auch nicht, aber da die delphieigenen Bezeichner zwangsläufig englisch sind, läuft es immer auf ein Mischmasch aus Deutsch und Englisch hinaus...
Das macht den Code nicht übersichtlicher...

Beispiel aus freier Wildbahn:

Delphi-Quellcode:

if SchnellstartHaken.Checked or ZwangsstartAktiviert then
begin
  StartenKnopf.Click;
  Exit;
end;

:pale:

[bra]

Zitat:

Zitat von jaenicke (Beitrag 1344779)

Wie sieht denn deine Alternative für mein Beispiel aus?

Eventuell so (nicht getestet):

Delphi-Quellcode:

type
  TExample = class
  private
    FTest: Integer;
  public
    constructor Create(const FTest: Integer);
    property Test: Integer read FTest write FTest;
  end;

constructor TTest.Create(const FTest: Integer);
begin
  Self.FTest := FTest;
end;

Selbst wenn das funktioniert wäre das aber Programmier-Selbstmord, da sind die Fehler vorprogrammiert. ;)

[Mavarik]

Dann doch lieber "neutral":

Delphi-Quellcode:

type
  TExample = class
  private
    FTest: Integer;
  public
    constructor Create(const (A)Value : Integer);
    property Test: Integer read FTest write FTest;
  end;

constructor TTest.Create(const (A)Value: Integer);
begin
  FTest := (A)Value;
end;