Hallo zusammen,
mir ist bisher noch kein Delphibuch bzw. kein Tutorial über den Weg gelaufen, dass eine allgemein gültige, anerkannte und übersichtliche Delphisyntax verwendet und diese einem nahe bringt.
Nun, ich will aber eine solche verwenden... Und hier sollt ihr mir weiterhelfen.

Wer also denkt, er verwende eine Syntax, die obig genannte Bedingungen erfüllt, bitte ich hier zu posten...

Danke für euer Verständnis für eine so exotische Frage - und natürlich eure Antworten.

Gruß, Marco

P.S.: Ich mach mal den Anfang...

zusammenfalten · markieren

Delphi-Quellcode:

unit SyntaxExample;

// USES
uses
  Windows, SysUtils; // ...

// PROTOTYPEN
procedure MyPublicProc();

type
  // TYPENDEKLARATION (RECORDS)
  TMyRecord = record
    Membr1, // Member-Reihenfolge:
    Membr2: Integer; // siehe "Globale Variablendeklarartion"
    Membr3: String;
  end;

  // TYPENDEKLARATION (KLASSEN)
  TMyClass = class
    private
      FMyProp: Integer;
      FSomewhat: Cardinal;

      procedure MyProcedure(AParam1, AParam2: String; AInt: Integer);
      function MyFunc(): Integer;

      function GetMyProp(): Integer;
      procedure SetMyProp(AValue: Integer);
    protected
      // ...
    public
      property MyProp: Integer read GetMyProp write SetMyProp;
      property Somewhat: Cardinal read FSomewhat write FSomewhat;
    published
      // ...
  end;

// GLOBALE VARIABLENDEKLARATION
var
  Obj1: TBitmap; // 1. Objekte
  Obj2: TStringList;
  hHandle: THandle; // 2. Handles
  pPtr: Pointer; // 3. Pointer
  Int: Integer; // 4. Ganzzahl-Variablen
  Dbl: Double; // 5. Gleitpunkt-Variablen
  Str: String; // 6. Strings

implementation

// IMPLEMENTATION

procedure MyPublicProc();
// Private Variablendeklaration
var
  Obj: TBitmap; // 1. Objekte
  hHandle2: THandle; // 2. Handles
  pPtr: Pointer; // 3. Pointer
  Int2: Integer; // 4. Ganzzahl-Variablen
  Dbl2: Double; // 5. Gleitpunkt-Variablen
  Str2: String; // 6. Strings
begin
end;

procedure MyPrivateProc();
begin
end;

// Parameter
procedure TMyClass.MyProcedure(AParam1, AParam2: String; AInt: Integer);
begin

function TMyClass.MyFunc(): Integer;
begin
  Result := 100;
end;

function TMyClass.GetMyProp(): Integer;
begin
  // ...
  Result := FMyProp;
end;

procedure TMyClass.SetMyProp(AValue: Integer);
  // ...
  FMyProp := AValue;
end;

Ich habe noch nie gesehen, dass bei Pascal/Delphi parameterlose Prozeduren mit leeren Klammern benutzt werden. Das kenne ich von JavaScript, C, usw. Aber nicht von Delphi.

Ansonsten gibt´s doch IMHO eine gültige, vorgeschriebene Syntax, an die man sich halten sollte.

Genau. Und diese findest du hier in deutscher Sprache:

http://www.dsdt.info/grundlagen/styleguide/

Hallo,
danke, habe mir den Guide runtergeladen... Das war's eigentlich, was ich gesucht habe.

Gruß, Marco

Zitat von jim_raynor:

Genau. Und diese findest du hier in deutscher Sprache:

http://www.dsdt.info/grundlagen/styleguide/

Zitat von DSDT Guide:

Sie sollten alle Einrückungsebenen immer zwei Leerzeichen einrücken. In anderen Worten: Die erste Einrückungsebene ist zwei Zeichen, die zweite Ebene vier Zeichen, die dritte sechs Zeichen eingerückt usw. Verwenden Sie niemals den Tabulator.

So ein Blödsinn. Keine Ahnung wer auf diese dämliche Idee kam... Wofür zum Geier sind Tabs da, wenn nicht zum einrücken?

Bis auf Spaces und ein paar anderen Kleinigkeiten halte ich mich auch an den Pascal guide.

Zum Beispiel find ich das hier...

markieren

Delphi-Quellcode:

type
   TMiep = class
   private
      fSomeField :TSomeType;
   public
      DoSomething(aSomeParameter :TSomeType);
   end;

lesbarer als das:

markieren

Delphi-Quellcode:

type
   TMiep = class
   private
      FSomeField :TSomeType;
   public
      DoSomething(ASomeParameter :TSomeType);
   end;

Gegen das große T kann man wohl nichts machen, aber ich sehe absolut keinen rationalen Grund, warum ich den Lesefluss durch A und F kaputtmachen sollte.
Der erste große Buchstabe springt nunmal ins Auge, da ist es einfach nur ärgerlich wenn einem ein großes A oder F reinpfuschen.
Nach einer Weile mit C# habe ich es mir auch angewohnt parameterlose Funktionen mit () zu verwenden.
Das unterscheidet sie sofort von Properties.

Mag sein, dass ich da ein wenig strenge Vorstellungen habe, ich hasse es einfach, wenn ich fremden Code nicht so schnell überfliegen kann, wie es möglich wäre...
Aber das sind nur meine 2 cents..

btw: Sollte man hier dringend die Tab size einstellen.
Im Quellcode sind es 3 Zeichen und im Beitragseditor sind's 8.
Als Pascalisti sollten es 2 oder 4 sein.

Hi Robert,

markieren

Delphi-Quellcode:

type
   TMiep = class
   private
      FSomeField :TSomeType;
   public
      DoSomething(ASomeParameter :TSomeType);
   end;

Ich finde, dass die großen Buchstaben schon ok sind. Dadurch kann man direkt sehen "ah "F", das ist ein Feld". Genauso bei Parametern. Ich kann den Namen dahinter noch genauso gut lesen. Das ist auch wohl der Grund wieso ich diese Schreibweise bevorzuge und auch verwende - wobei ich manchmal das "A" vor den Argumenten weglasse.

mfG
mirage228

Zitat von Robert_G:

Nach einer Weile mit C# habe ich es mir auch angewohnt parameterlose Funktionen mit () zu verwenden.
Das unterscheidet sie sofort von Properties.

Nach einer Weile mit C# habe ich mir lange, aussagekräftige Variablennamen angewöhnt. Neuerdings mache ich sogar ein Leerzeichen nach einem Komma:

markieren

Code:

MessageBox.Show("Huhu", "Hihi");

und seit JavaScript und PHP klammere ich auch in Delphi wie ein Bekloppter.

markieren

Delphi-Quellcode:

if(IrgendeineSimpleBedingung) then
begin
end;

Aber trotz all dem finde ich solche leeren Klammern
function Miep(): boolean; irgendwie immer noch unpassend für Delphi.

Zitat von MathiasSimmack:

function Miep(): boolean; irgendwie immer noch unpassend für Delphi.

Ich glaube das Miep hat mcih überführt.
Jupp sowas rutscht mir oft reflexartig raus. In der Deklaration it es natürlich total Bohne, schließlich steht ja method/function/procedure davor.

Zitat von mrirage228:

wobei ich manchmal das "A" vor den Argumenten weglasse.

Und genau da fängt es an...
Was wenn sich der Leser an deinen Stil gewöhnt und sich dann ärgert wenn die vermeintliche Property ein Parameter ist?

[edit=alcaeus]Doppelpost geloescht. Mfg, alcaeus[/edit]

Zitat von Robert_G:

Zitat von mrirage228:

wobei ich manchmal das "A" vor den Argumenten weglasse.

Und genau da fängt es an...
Was wenn sich der Leser an deinen Stil gewöhnt und sich dann ärgert wenn die vermeintliche Property ein Parameter ist?

Prinzipiell hast Du natürlich recht, wobei sich das in Zeiten von Code- und HelpInsight relativiert haben dürfte. Wenn ich mir nicht sicher bin, lasse ich den Mauszeiger rübergleiten und Delphi zeigt mir dann halt an, ob es eine Methode oder Property ist

mfG
mirage228

Hallo zusammen,

Zitat:

So ein Blödsinn. Keine Ahnung wer auf diese dämliche Idee kam... Wofür zum Geier sind Tabs da, wenn nicht zum einrücken?

Also ich nutze grundsätzlich die Tab-Taste, jedeoch keine echten Tabs (#9)....

Zitat:

Gegen das große T kann man wohl nichts machen, aber ich sehe absolut keinen rationalen Grund, warum ich den Lesefluss durch A und F kaputtmachen sollte.
Der erste große Buchstabe springt nunmal ins Auge, da ist es einfach nur ärgerlich wenn einem ein großes A oder F reinpfuschen.

Da bin ich der Meinung von Mirage, das A und F gehört groß.
Was ich allerdings auf gut Deutsch gesagt eine Schweinerei finde, ist, dass selbst der Style Guide und auch viele Delphi-Programmierer das Parameter-A nicht oder nur mal und mal nicht benutzen... Ich jedenfalls setzte vor jeden Parameter ein A.

Zitat:

Nach einer Weile mit C# habe ich es mir auch angewohnt parameterlose Funktionen mit () zu verwenden.
Das unterscheidet sie sofort von Properties.

Der Meinung bin ich auch. Und nicht nur die Unterscheidung von Properties wird einfacher sondern auch von det Dingens namens Variablen... (s.u.)

So, nun zu meinen beim Lesen des Style Guides:

Zitat:

Verwenden Sie keine reine Großschreibung für Konstantennamen, außer an den Stellen, wo Header-Übersetzungen es verlangen.

Ich würde Konstanten immer komplett groß schreiben (und tue dies gewöhnlich auch): MyConst ist für mich eine Variable, MY_CONST oder MYCONST eine Konstante.

Zitat:

Delphi stammt aus Kalifornien, weshalb wir von der Ungarischen Notation abraten, außer wo Header-Übersetzungen es erfordern:

markieren

Delphi-Quellcode:

KORREKT
  FMyString: string;

INKORREKT
  lpstrMyString: string;

Das ist für mich der größte Quatsch im ganzen Dokument...

markieren

Delphi-Quellcode:

var
  oForm: TForm;
  hForm: THandle
  pData: Pointer;
  aData: array of Byte;

ist doch tausend mal besser (und im Code schneller zu erkennen) als

markieren

Delphi-Quellcode:

var
  Form: TForm;
  FormHandle: THandle;
  DataPtr: Pointer;
  Data: array of Byte;

Zitat:

Reservierte Wörter und Direktiven sollten komplett in Kleinbuchstaben sein. Das kann manchmal etwas verwirrend sein. Typen wie Integer zum Beispiel sind einfach Bezeichner und beginnen mit einem Großbuchstaben. Strings werden dagegen mit dem reservierten Wort string deklariert, welches in Kleinbuchstaben stehen sollte.

Warum ist der Datentyp String ein reserviertes Wort, und Integer nicht?! Ich nehme es mir heraus, String genau so wie Integer und alle anderen Typen am Anfang GROSS zu schreiben.

Zitat:

if-Anweisungen sollten immer mindestens in zwei Zeilen stehen.
Beispiel:

markieren

Delphi-Quellcode:

 // FALSCH
  if A < B then DoSomething;

  // RICHTIG
  if A < B then
    DoSomething;

Ich finde Ersteres nicht unübersichtlicher, im Gegenteil...

Zitat:

Setzen Sie in zusammengesetzten if-Anweisungen jedes Element, das Anweisungen voneinander trennt in eine neue Zeile:

zusammenfalten · markieren

Delphi-Quellcode:

  // FALSCH
  if A < B then begin
    DoSomething;
    DoSomethingElse;
  end else begin
    DoThis;
    DoThat;
  end;

  // RICHTIG
  if A < B then
  begin
    DoSomething;
    DoSomethingElse;
  end
  else
  begin
    DoThis;
    DoThat;
  end;

Ich bekomm gleich einen Schreikrampf! Man betrachte die als 'RICHTIG' eingestufte Variante mit end else begin in drei (!) Zeilen!! Außerdem finde ich es viel übersichtlicher, das begin jeweils noch mit in die selbe Zeile (z.B. der if-Bedingung) zu schreiben. Davon werde ich auch in Zukunft nicht abweichen.

Soweit meine Meinung(en).

Was meint ihr dazu?

Gruß, Marco