Allgemeine Delphisyntax

[Marphy]

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. :-D

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. :mrgreen:

Gruß, Marco

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

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;

[MathiasSimmack]

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.

[jim_raynor]

Genau. Und diese findest du hier in deutscher Sprache:

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

[Marphy]

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

Gruß, Marco

[Robert_G]

Zitat:

Zitat von jim_raynor

Genau. Und diese findest du hier in deutscher Sprache:

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

Zitat:

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. :roll: Keine Ahnung wer auf diese dämliche Idee kam... Wofür zum Geier sind Tabs da, wenn nicht zum einrücken? :roll:

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

Zum Beispiel find ich das hier...

Delphi-Quellcode:

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

lesbarer als das:

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. :shock:
Als Pascalisti sollten es 2 oder 4 sein. ;)

[mirage228]

Hi Robert,

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

[MathiasSimmack]

Zitat:

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:

Code:

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

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

Delphi-Quellcode:

if(IrgendeineSimpleBedingung) then
begin
end;

Aber trotz all dem finde ich solche leeren Klammern

Delphi-Quellcode:

function Miep(): boolean;

irgendwie immer noch unpassend für Delphi. :stupid:

[Robert_G]

Zitat:

Zitat von MathiasSimmack

Delphi-Quellcode:

function Miep(): boolean;

irgendwie immer noch unpassend für Delphi. :stupid:

Ich glaube das Miep hat mcih überführt. :mrgreen:
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:

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? :zwinker:

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

[mirage228]

Zitat:

Zitat von Robert_G

Zitat:

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? :zwinker:

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

[Marphy]

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ß. :dancer:
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.) :pale:

So, nun zu meinen :wall: 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:

Delphi-Quellcode:

KORREKT
  FMyString: string;

INKORREKT
  lpstrMyString: string;

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

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

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:

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:

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! :evil: 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

[mirage228]

Hi,

in vielen Punkten gebe ich Dir recht, jedoch mache ich einige Dinge anders.

Unter anderem rücke ich immer mit zwei Zeichen (bzw. je nach tiefe mit 4, 6, ...) ein. Habe das in der Schule so gelernt. Echte Tabs sind für mich zu viel Leerraum.

Ich schreibe reservierte Wörter grundsätzlich klein, dazu gehört für mich auch string (Habe das zuerst in der Schule mit TurboPascal so gelernt).

Delphi-Quellcode:

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

Das halte ich auch viel übersichtlicher, wobei ich auch mal die andere Schreibweise verwende.

Delphi-Quellcode:

// FALSCH 
  if A < B then DoSomething; 

  // RICHTIG 
  if A < B then 
    DoSomething;

Ich verwende hier aus Gewohnheit die zweite Variante. IMHO übersieht man es leichter, wenn man es nur in eine Zeile schreibt.

Bei der Sache mit den IF-THEN-ELSE Blöcken halte ich auch die "richtige" Variante mit 3 Zeilen für zu lang und überflüssig, andererseits finde ich die erste Variante auch nicht so gut. Ich mache das so:

Delphi-Quellcode:

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

mfG
mirage228

[Neutral General]

Also ich mach immer ein Mittelding von den beiden :

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;

// So mach ichs ^^
if A < B then begin
    DoSomething;
    DoSomethingElse;
  end  // manchmal das else auch schon hier hinter
  else
  begin
    DoThis;
    DoThat;
  end;

:mrgreen:

Das mit den for Schleifen mache ich auch "falsch" :

Delphi-Quellcode:

  // FALSCH ... So mach ichs aber
  for i := 0 to 10 do begin
    DoSomething;
    DoSomethingElse;
  end;

Meine "begin"s sind immer direkt in der gleichen Zeile wie das "then" oder das "do" usw... hab ich mir so angewöhnt und find ich übersichtlicher..

[Christian Seehase]

Moin Zusammen,

also ich denke mal "den" Styleguide gibt es nicht.
Solange man alleine arbeitet sollte man es so machen, wie es der eigenen Übersicht dienlich ist. Diesen Stil sollte man dann aber auch durchhalten, wobei natürlich nichts dagegen spricht den eigenen Stil weiterzuentwickeln, wenn man merkt dass es noch besser geht.
Sobald man allerdings im Team arbeitet, wird man nicht umhinkommen einen einheitlichen Stil zu verwenden. Ob der jetzt vorgegeben wird, oder gemeinsam entwickelt werden kann ist dann wieder eine zweite Sache.

Eine Zeitlang habe ich, z.B., mit Parameter mit p_ eingeleitet. Es hat sich allerdings herausgestellt, dass diese Schreibweise dann doch nicht so ideal war, und ich habe das auf A geändert.

@Marco:
Warum nun integer kein reserviertes Wort ist kann ich Dir auch nicht sagen, aber es die Auswirkung, dass Du den Bezeichner auch anders verwenden kannst:

Delphi-Quellcode:

// Zulässig
procedure integer;
begin
end;

// Nicht zulässig
procedure string;
begin
end;

Ob das jetzt Sinn macht sei einmal dahingestellt.

[SirThornberry]

Bei größeren Projekten würde ich empfehlen die Proceduren und funktionen Alphabetich zu ordnen. Anfangs hab ich immer Get und Set Methode über einander geschrieben aber irgendwann verliert man da die Übersicht.

Delphi-Quellcode:

private
  function FGetAbc: Integer;
  function FGetDef: Integer;
  function FGetGhi: Integer;
  procedure FSetAbc(AValue: Integer);
  procedure FSetDef(AValue: Integer);
  procedure FSetGhi(AValue: Integer);

setweiteren würde ich empfehlen für private, protected, global, local, Übergabeparameter verschiedene Buchstaben voranzustellen um beim überliegen des Quelltextes sofort zu wissen ob es sich bei einer Variablen um eine lokale, globale etc. handelt. Eigentlich gibt es da bei Delphi nur das vorrangstellte F bei private-Variablen. Inzwischen hab ich mir jedoch angewöhnt private-Variablen mit einem kleinen "f" zu beginnen und Proceduren mit einem großen "F". Somit weiß ich wenn ich im Quelltexte

Delphi-Quellcode:

  lTmpInt := FMainID;

lese sofort das "FMainID" eine funktion ist und keine Variable da eine Variable bei mir mit einen kleinen "f" beginnt. Bei Lokalen Variablen/Funktionen verhält es sich genau so. Ist zwar alles kein Standard aber selbst die Kollegen bei Gemeinschaftsprojekten wissen es zu schäzen weil sie sofort wissen worum es sich beim überfliegen vom Quelltext handelt.





folgende Variante halte ich für völlig unübersichtlich

Zitat:

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

Wenn ich im Quelltext irgendwo ein if sehe ist es für mich auf den ersten Blick eine Einzelanweisung die folgt wenn nicht direkt unter dem "if" das "begin" steht denn eine einzelanweisung wird genau so eingerückt. Außerdem würde man bei der Variante die Befehle in dem Begin-End Block 4 zeischen einrücken müssen (wäre ich viel zu faul).

Die Variante

Delphi-Quellcode:

  [...]
end
else
begin
  [...]

finde ich persönlich auch nicht sehr ansehnlich aber man sieht auf den ersten blick ob es sich um ein "else if" handelt oder nur um eine "end" oder eben um ein "end else". würde alles auf einer Zeile stehen müsste man erst in die Zeile reinlesen und es würde nicht ausreichen nur den Zeilenanfang anzusehen. Im großen und ganzen finde ich die Standards schon recht sinnvoll auch wenn ich davon ab und zu abweische. Dies liegt allerdings daran das ich meist zu faul bin 3 mal enter zu tippen etc..

[Robert_G]

Zitat:

Zitat von mirage228

Unter anderem rücke ich immer mit zwei Zeichen (bzw. je nach tiefe mit 4, 6, ...) ein. Habe das in der Schule so gelernt. Echte Tabs sind für mich zu viel Leerraum.

Euch ist schon klar, dass Tabs die Möglichkeit geben, die Breite der Einrückung selbst zu bestimmen OHNE dass es beim nächsten zu Übelkeit führt? Der stellt sich nämlich seine Breite so ein wie er es will. ;)
Und wenn wir schonmal beim Rundumschlag sind.... :mrgreen:
hungarian Notation und Unterstriche sollten verboten werden :P
Ich verwende Unterstriche nur in diesen Pseudo templates. Warum? Weil's so hässlich aussieht, dass diese Platzhalter niemals mit richtigen Bezeichnern kollidieren könnten. ;)
Und diese Präfixe. Die erinnern mich irgendwie immer an die Bezeichner in einer DB, angelegt von jemanden, der nicht mit der DB arbeiten muss.
Ihr wisst schon, solch kryptischer Käse wie: Emp_FK_XYZ_tblFünfte_dirLinks_procErste. :?
Jupp ist klar, verständliche lesbare Namen wären ja zu einfach. :mrgreen:

Aber eigentlich kann's mir ziemlich egal sein, was ihr wie tippt.
Hässlichen Code schaue ich mir eigentlich nur an, wenn ich besonders gute Laune habe. Ob ich danach immer noch die Lust verspüre eine Antwort zu schreiben ist wieder eine ganz andere Frage. ;) Fließt einfach zuviel böses Blut wenn man ständig wegen hässlichem Code rumheult. ;)

Aber einer der Vorteile von Pascal ist, dass "Pascalies" zu einem hohen Anteil ziemlich nah nach an einem Standard bleiben.
Wenn ich mir manchen C# Code ansehe wo private Felder mit einem Unterstrich begonnen werden, öffentliche proeprties mit einem kleinen Buchstaben beginnnen oder was weiß ich für kranke Sachen...
Ich glaube da wäre es mir lieber den hässlichsten Delphi code durchzulesen, den ich mir vorstellen kann. ;)

[Marphy]

Hallo zusammen!

Zitat:

Unter anderem rücke ich immer mit zwei Zeichen (bzw. je nach tiefe mit 4, 6, ...) ein. Habe das in der Schule so gelernt. Echte Tabs sind für mich zu viel Leerraum.

Mach ich auch so... Allerdings drücke ich nicht 2x die Leertaste, sondern meistens 1x die TAB-Taste...

Delphi-Quellcode:

Ich schreibe reservierte Wörter grundsätzlich klein, dazu gehört für mich auch string (Habe das zuerst in der Schule mit TurboPascal so gelernt).

:warn: Ich finde das irgendwie eine Art "Stilbruch" (obwohl es ja genau genommen gerade das Gegenteil ist :nerd: ): Wenn ich alle Datentypen zu Beginn groß schreibe, dann tu ich das auch mit String, da kann es ein reserviertes Wort oder auch irgendwas anderes sein (aber eben trotzdem ein Datentyp).

Zitat:

Das halte ich auch viel übersichtlicher, wobei ich auch mal die andere Schreibweise verwende.

Und genau sowas kann ich nicht leiden. :firejump: Man kann doch nicht mal hWindow und mal WindowHandle schreiben (Nich bös gemeint :wink:).
Und wann ist es angebracht, des Dingens mal so und mal anders zu schreiben?

Zitat:

Delphi-Quellcode:

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

Die begin-Blöcke und deren Inhalt jeweils um zwei Leerzeichen einrücken? Dann doch lieber

Delphi-Quellcode:

end
else
begin

:mrgreen:

----

Zitat:

Diesen Stil sollte man dann aber auch durchhalten

Exakt korrekt! :mrgreen: :???:

Zitat:

Warum nun integer kein reserviertes Wort ist kann ich Dir auch nicht sagen

Hmm, sollte man mal Borland fragen... Danke übrigens für die weitere Erklärung.

----

Zitat:

finde ich persönlich auch nicht sehr ansehnlich aber man sieht auf den ersten blick ob es sich um ein "else if" handelt oder nur um eine "end" oder eben um ein "end else". würde alles auf einer Zeile stehen müsste man erst in die Zeile reinlesen und es würde nicht ausreichen nur den Zeilenanfang anzusehen.

Find ich nich :stupid:

Zitat:

hungarian Notation und Unterstriche sollten verboten werden

:shock: :pale: :firejump:

Zitat:

Wenn ich mir manchen C# Code ansehe wo private Felder mit einem Unterstrich begonnen werden, öffentliche proeprties mit einem kleinen Buchstaben beginnnen oder was weiß ich für kranke Sachen...

Das ist wirklich krank... :wink:

Gruß, Marco

[mirage228]

Zitat:

Zitat von Marphy

Zitat:

Delphi-Quellcode:

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

Die begin-Blöcke und deren Inhalt jeweils um zwei Leerzeichen einrücken? Dann doch lieber

Delphi-Quellcode:

end
else
begin

:mrgreen:

Hi,

oh, so mache ich das natürlich nicht :mrgreen:

Delphi-Quellcode:

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

So ists besser ;)

Zitat:

Und genau sowas kann ich nicht leiden. Man kann doch nicht mal hWindow und mal WindowHandle schreiben (Nich bös gemeint ).
Und wann ist es angebracht, des Dingens mal so und mal anders zu schreiben?

Oh, da habe ich mich wieder vertan. Ich dachte Du meintest die Art, wie man die Deklaration macht. Also alle Doppelpunkte untereinander etc. Auf die Variablennamen habe ich gar nicht geachtet :oops: - Das habe ich aber nun einheitlich in meinen Apps, außer bei nur Win32-API ("nonVCL") Programmen, da passt es ja zum allgemeinen Stil imho.

mfG
mirage228

[BenBE]

[Senf]

Zitat:

Zitat von Robert_G

Zitat:

Zitat von jim_raynor

Genau. Und diese findest du hier in deutscher Sprache:

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

Zitat:

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. :roll: Keine Ahnung wer auf diese dämliche Idee kam... Wofür zum Geier sind Tabs da, wenn nicht zum einrücken? :roll:

Weil Tabs die nette Eigenschaft haben, wtitzige Effekte bei Verwendung einer anderen Einstellung zu erzeugen ... Spätestens, wenn man in nem Teamprojekt arbeitet, wo jede ne andere Einstellung hat, sieht das dann recht komisch aus ;-)

Nene, für solche Dinge sind Source-Formatter da ^^

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

[Robert_G]

Zitat:

Zitat von BenBe

Weil Tabs die nette Eigenschaft haben, wtitzige Effekte bei Verwendung einer anderen Einstellung zu erzeugen ... Spätestens, wenn man in nem Teamprojekt arbeitet, wo jede ne andere Einstellung hat, sieht das dann recht komisch aus ;)

Kann es sein, dass du das überlesen hast? :gruebel:

Ich habe folgendes geschrieben

Euch ist schon klar, dass Tabs die Möglichkeit geben, die Breite der Einrückung selbst zu bestimmen OHNE dass es beim nächsten zu Übelkeit führt? Der stellt sich nämlich seine Breite so ein wie er es will. ;)

Interessanterweise kommt dieses Argument immer wieder von diesen "Tab-Tipper-aber-Space-Einfüger", man _könnte_ also argumentieren, dass diese Spezies nicht sehr weit denkt. Ohne eine unabhängig durchgeführte Studie dazu würde ich mich da aber offiziell nicht festlegen wollen... :mrgreen:

[xotox]

Zitat:

Zitat von Robert_G

...
Und wenn wir schonmal beim Rundumschlag sind.... :mrgreen:
hungarian Notation und Unterstriche sollten verboten werden :P
...

Die ungarische Notation ist eine der besten Sachen überhaupt!!!
Natürlich nur wenn man das System dahinter richtig versteht.
Leider tun das die wenigsten.

[alcaeus]

Ich kann Robert da nur zustimmen. Spaces fuer Einrueckungen zu verwenden ist wirklich schlimm.

Ein Beispiel: bei meinem ehemaligen Arbeitgeber war alles vorhanden: 8 Zeichen Einrueckung, 4 Zeichen, 3 Zeichen 2 Zeichen. Natuerlich wurden die Codes ins CVS eingecheckt, und der naechste der was bearbeiten durfte hatte dann seine Probleme am Hals. Ich finde es ausserdem schon mal eine dumme Idee die Einrueckungsweite in einen Styleguide aufzunehmen. Sorry, aber es wird wohl meine Sache sein, wie weit ich es einruecke? Vor allem wenn ich dafuer Tabs verwende, dass der Leser den Code so sieht, wie er ihn geschrieben haette. Ich seh 2 Zeichen, der andere 4 Zeichen. Gespeichert wird ein Zeichen, also sparst du dir bei einigen Grossprojekten Unmengen an Speicherplatz (ich denke da an das 600000-Zeilen-Projekt das mit 4 Spaces eingerueckt war :roll:)

Greetz
alcaeus

[BenBE]

Übrigens wegen den Tabs: Ich red da aus Erfahrung, da ich selber mal eine Zeit lang heftig davon gebrauch gemacht habe.

Aufgehört hat es dann damit, dass besagte Sourcen aufm CVS gelandet sind.

Probleme gabt es nur eben immer dann, wenn dort aus Versehen Tabs in ASM-Bölöcken (ja, ich bin so lebensmüde und programmier Teile unter Delphi IMMERNOCH mit ASM) auf anderen Breiten angezeigt wurden.

Beispiel (Tabs durch Punkte ersetzt):
Tab=4

Delphi-Quellcode:

    MOV     EAX, $00000001
    PUSH    EAX
    CALL    Sleep

Gleicher Source mit Tab=8

Delphi-Quellcode:

        MOV             EAX, $00000001
        PUSH    EAX
        CALL    Sleep

HTH ...

Zur Lösung dieses Problems ist bei Projekt Omorphia daher ein SourceFormatter vorgeschrieben und im CVS die Breite für Einrückungen (auf 4 Leerzeichen) festgelegt.