guter stil????

[Mr. Pink]

hallo,
auch wenn ich noch vor ein paar stunden eine frage zu diesem programm gestellt habe, hab ich doch jetzt eine ganz andere:
Ich möchte mal hören, ob mein schreibstil in delphi gut oder schlecht ist. ich kam drauf, indem ich mir mal andere sources angeschaut habe, die irgendwie ganz anders aufgebaut sind als meine codes!

Ich würd mich freuen wenn sich mal jemand den code angucken und sagen könnte was ich besser/anders machen sollte.

danke an alle die sich die mühe machen!!!
btw, das ganze ist zur primfaktorzerlegung gedacht.

Delphi-Quellcode:

unit Unit1;

interface

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

type
  TForm1 = class(TForm)
    Label1: TLabel;
    Edit1: TEdit;
    Button1: TButton;
    Label2: TLabel;
    procedure Button1Click(Sender: TObject);
  private
    { Private declarations }
  public
    { Public declarations }
  end;

var m:int64;
  Form1: TForm1;

implementation

{$R *.dfm}

function pruefen(n:int64):boolean;
var x:int64;
    p:boolean;
begin
 p:=true;
 x:=round(n/2);
 if n>=2 then
 begin
  while x>1 do
  begin
   if (n mod x) = 0 then
   begin
    p:=false;
    break;
   end;
   x:=x-1;
  end;
 end
 else p:=false;
 if p=true then pruefen:=true
 else pruefen:=false;
end;

procedure zerlegen(n:int64);
var x:int64;
begin
 x:=2;
 while (n mod x<>0) do x:=x+1;
 if length(form1.Label2.Caption)>0 then form1.Label2.Caption:=form1.Label2.Caption+'*';
 form1.Label2.Caption:=form1.Label2.Caption+inttostr(x);
 if pruefen(n div x)=false then zerlegen(n div x);
 m:=m*x;
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
 m:=1;
 label2.Caption:='';
 if pruefen(strtoint(edit1.Text))=true then label2.Caption:=edit1.Text+' ist eine Primzahl!'
 else
 begin
  zerlegen(strtoint(edit1.Text));
  label2.Caption:=label2.Caption+'*'+inttostr(strtoint(edit1.Text)div m);
 end;
end;

end.

[GLaforge]

Hi,
was mir gleich auffällt sind fehlende Kommentare, sind für dich und uns schon meist von nutzen. Desweiteren würde ich eine Einrückung bei den if Konstrukten vornehmen. Ich schreibe immer das else unter das then etc. Ausserdem würde ich nach dem 1. Begin die fortlaufenden Zeilen auch um ein bis zwei Leerzeichen einrücken.
Jedoch muss man auch sagen, dass es so keine wirklichen Festlegungen gibt. Es sollte aber immer dein Ziel sein, dass du und jeder andere sich im QT zurechtfindet, eben indem man Schleifen etc. gesondert einrückt.

[Matze]

Nur ein Wort zur Formatierung, die ist so ja schrecklich.
Inhaltlich leicht verändert (wichtig!) und wenn du so Wert auf Ordentlichkeit legst, solltest du den Code auch entsprechend formatieren. Ich würde ihn in deinem Fall so formatieren:

Delphi-Quellcode:

unit Unit1;

interface

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

type
  TForm1 = class(TForm)
    Label1: TLabel;
    Edit1: TEdit;
    Button1: TButton;
    Label2: TLabel;
    procedure Button1Click(Sender: TObject);
  private
    { Private declarations }
  public
    { Public declarations }
  end;

var 
  m: Int64;
  Form1: TForm1;

implementation

{$R *.dfm}

function pruefen(n: Int64): Boolean;
var 
  x: Int64;
  p: Boolean;
begin
  p := true;
  x := round(n / 2);
  if n >= 2 then
  begin
    while x > 1 do
    begin
      if (n mod x) = 0 then
      begin
        p := false;
        break;
      end;
      x := x - 1;
    end;
  end else 
    p := false;

  if p then               // überprüfe niemals auf "= true" !! 
    pruefen := true else  // Willst du die Gründe wissen -> Suchfunktion.   
      pruefen := false;   // 'p := pruefen' müsste hier auch gehen                                  
end;

procedure zerlegen(n: Int64);
var 
  x: Int64;
begin
  x := 2;
  while (n mod x <> 0) do 
    x := x + 1;

  if Length(Form1.Label2.Caption) > 0 then
    Form1.Label2.Caption := Form1.Label2.Caption + '*';
  Form1.Label2.Caption := Form1.Label2.Caption + IntToStr(x);

  if pruefen(n div x) = false then
    zerlegen(n div x);

  m := m * x;
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
  m := 1;
  Label2.Caption := '';

  if pruefen(StrToInt(Edit1.Text)) then   // kein "= true"!
  begin
    Label2.Caption := Edit1.Text + ' ist eine Primzahl!' else
    begin
      zerlegen(StrToInt(Edit1.Text));
      Label2.Caption := Label2.Caption + '*' + 
        IntToStr(StrToInt(Edit1.Text) div m);
    end;
  end;
end;

end.

Bei Gelegenheit kannst du dir auch einmal den Borland-Styleguide durchlesen.

[3_of_8]

Mir fallen auf die Schnelle zwei Sachen auf:

1. Einrückungen. Manchmal vorhanden, manchmal nicht. Nimm nen Sourceformatter, google mal nach Delforex.
2. if aboolean=true then... ist nicht korrekt. if aboolean then... muss es heißen. Denn ersteres vergleicht den Wert von aboolean mit dem Wert der Konstante True. Zweiteres schaut nach, ob aboolean wahr ist oder nicht. Das macht vor allem dann einen Unterschied, wenn du mit LongBool oder ähnlichem arbeitest.

[Ultimator]

Delphi-Quellcode:

function pruefen(n: int64):boolean; 
var x: int64;  
begin 
  result := true; 
  x := round(n/2); 
  if n >= 2 then 
    begin 
      while x > 1 do 
        begin 
          if (n mod x) = 0 then 
            begin 
              result := false; 
              break; 
            end; 
         dec(x); 
       end; 
     end 
   else 
     result := false; 
end; 

procedure zerlegen(n:int64); 
var x: int64; 
begin 
  x := 2; 
  while (n mod x <> 0) do
    x := x+1; 
  if length(Form1.Label2.Caption) > 0 then
    Form1.Label2.Caption := Form1.Label2.Caption + '*'; 
  Form1.Label2.Caption := Form1.Label2.Caption + inttostr(x); 
  if not pruefen(n div x) then 
    zerlegen(n div x); 
  m := m*x; 
end; 

procedure TForm1.Button1Click(Sender: TObject); 
begin 
  m := 1; 
  Label2.Caption := ''; 
  if pruefen(strtoint(edit1.Text)) then 
    Label2.Caption := Edit1.Text + ' ist eine Primzahl!' 
  else 
    begin 
      zerlegen(strtoint(edit1.Text)); 
      Label2.Caption := Label2.Caption + '*' + inttostr(strtoint(edit1.Text) div m); 
    end; 
end;

So würd ichs machen.
Ich hab mir den Algo an sich nicht angeschaut, wie effektiv und richtig der ist ;)
Was hab ich gemacht: Oben in der zerlegen-Funktion hab ich die Variable p rausgenommen und gleich result verwendet. Dann hab ich alle Einrückungsebenen konsequent durchgezogen, Alle Anfangsbuchstaben von Objekten groß geschrieben, Leerzeichen vor und hinter jedes ":=" gesetzt und auch vor und hinter jedes "+" in den Stringzusammensetzungen.

//edit1: Zusätzlich noch hinter jedem ":" in den Variablendeklarationen und den Parameterangaben ein Leerzeichen eingefügt.
//edit2: Leerzeichen rund um die <, >, <=, >= und <>-Vergleiche eingefügt.

[Matze]

Zitat:

Zitat von Ultimator

So würd ichs machen.

Da fand ich seines ja fast übersichtlicher. :stupid:

Ich persönlich vorde vor begin nie einrücken. Aber darüber kann man sich natürlich streiten.

[xaromz]

Hallo,

ein paar Anmerkungen:
- mehr einrücken
- ab und zu mit Lehrzeilen logische Schritte trennen
- Kommentare
- vor und nach Operatoren ein Leerzeichen
- Zwischenergebnisse nicht mehrfach ausrechnen, sondern speichern
- statt "if a = False" lieber "if not a"
- bei Funktionen/Schlüsselwörtern Groß-/Kleinschreibung beachten
- Variablennamen evtl. aussagekräftiger

Beispiel:

Delphi-Quellcode:

procedure zerlegen(n:int64); 
var x:int64; 
begin 
x:=2; 
while (n mod x<>0) do x:=x+1; 
if length(form1.Label2.Caption)>0 then form1.Label2.Caption:=form1.Label2.Caption+'*'; 
form1.Label2.Caption:=form1.Label2.Caption+inttostr(x); 
if pruefen(n div x)=false then zerlegen(n div x); 
m:=m*x; 
end;

Besser:

Delphi-Quellcode:

procedure Zerlegen(n: Int64); 
var 
  x: Int64; 
  Zwischen: Int64;
begin 
  x := 2; 
  while (n mod x <> 0) do 
    Inc(x);

  if Length(Form1.Label2.Caption) > 0 then
    Form1.Label2.Caption := form1.Label2.Caption + '*'; 
  Form1.Label2.Caption := Form1.Label2.Caption + IntToStr(x);

  Zwischen := n div x;
  if not Pruefen(Zwischen) then 
    Zerlegen(Zwischen); 
  m := m * x; 
end;

Ansonsten schon nicht so schlecht. Insbeondere bei der Einrückung sehe ich Potential, auch wenn das bei Dir teilweise noch schwer lesbar ist.

Gruß
xaromz
//Edit: Wie viele Rechtschreibfehler man so produzieren kann...

[Ultimator]

Zitat:

Zitat von Matze

Zitat:

Zitat von Ultimator

So würd ichs machen.

Da fand ich seines ja fast übersichtlicher. :stupid:

Ich persönlich vorde vor begin nie einrücken. Aber darüber kann man sich natürlich streiten.

Hm, ich hab mir das so angewöhnt und finds auch gut zu lesen *g*

[Rastaman]

Also ich häts so gemacht (von der Formatierung, vom Inhalt weiß ich nicht)

Delphi-Quellcode:

unit Unit1;

interface

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

type
  TForm1 = class(TForm)
    Label1: TLabel;
    Edit1: TEdit;
    Button1: TButton;
    Label2: TLabel;
    procedure Button1Click(Sender: TObject);
  private
    { Private declarations }
  public
    { Public declarations }
  end;

var m:int64;
  Form1: TForm1;

implementation

{$R *.dfm}

function pruefen(n: int64): boolean;
var
  x: int64;
  p: boolean;
begin
  p := true;
  x := round(n / 2);
  if n >= 2 then
  begin
    while x > 1 do
    begin
      if (n mod x) = 0 then
      begin
        p := false;
        break;
      end;
      x := x-1;
    end;
  end else
    p := false;

  if p = true then
    pruefen := true
  else
    pruefen := false;
end;

procedure zerlegen(n: int64);
var
  x:int64;
begin
  x:=2;
  while (n mod x <> 0) do
    x := x + 1;

  if Length(form1.Label2.Caption) > 0 then
    Form1.Label2.Caption := Form1.Label2.Caption + '*';

  Form1.Label2.Caption := Form1.Label2.Caption + IntTosSr(x);
  if pruefen(n div x) = false
    then zerlegen(n div x);

  m := m * x;
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
  m := 1;
  Label2.Caption := '';
  if pruefen(StrToInt(Edit1.Text)) = True then
    Label2.Caption := Edit1.Text + ' ist eine Primzahl!'
  else begin
    zerlegen(StrToInt(Edit1.Text));
    Label2.Caption := Label2.Caption + '*' + IntToStr(StrToInt(Edit1.Text) div m);
  end;
end;

end.

[xaromz]

Ach ja,
in der Routine "Pruefen":

Delphi-Quellcode:

  if p = true then 
    pruefen := true 
  else 
    pruefen := false;

Wie wäre es hier mit

Delphi-Quellcode:

Result := p;

Gruß
xaromz

[Ultimator]

Zitat:

Zitat von xaromz

Ach ja,
in der Routine "Pruefen":

Delphi-Quellcode:

  if p = true then 
    pruefen := true 
  else 
    pruefen := false;

Wie wäre es hier mit

Delphi-Quellcode:

Result := p;

Gruß
xaromz

Wie gesagt, die Variable p kann man komplett rausoptimieren ;)

[c113plpbr]

Zitat:

Zitat von xaromz

Ach ja,
in der Routine "Pruefen":

Delphi-Quellcode:

  if p = true then 
    pruefen := true 
  else 
    pruefen := false;

Wie wäre es hier mit

Delphi-Quellcode:

Result := p;

Gruß
xaromz

Wie wäre es ganz ohne p? das is nämlich vollkommen überflüssig ...

mein vorschlag:

Delphi-Quellcode:

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls;

type
  TForm1 = class(TForm)
    Button1: TButton;
    Edit1: TEdit;
    Label1: TLabel;
    Label2: TLabel;
    procedure Button1Click(Sender: TObject);
  private
    { Private declarations }
  public
    { Public declarations }
    function pruefen(n: int64): boolean;
    procedure zerlegen(n: Int64);
  end;

var
  m: int64;
  Form1: TForm1;

implementation

{$R *.dfm}

function TForm1.pruefen(n: int64): boolean;
var
  x: Int64;
begin
  Result := True;
  x := Round(n / 2);
  if(n >= 2)then
  begin
    while(x > 1)do
    begin
      if((n mod x) = 0)then
      begin
        Result := False;
        Break;
      end;
      Dec(x);
    end;
  end
  else
    Result := False;
end;

procedure TForm1.zerlegen(n: Int64);
var
  x: int64;
begin
  x := 2;
  while((n mod x) <> 0)do
    Inc(x);

  if(Length(Label2.Caption) > 0)then
    Label2.Caption := Label2.Caption + '*';

  Label2.Caption := Label2.Caption + IntToStr(x);

  if not(pruefen(n div x))then
    zerlegen(n div x);

  m := m * x;
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
  m := 1;
  Label2.Caption := '';

  if(pruefen(StrToInt(Edit1.Text)))then
    Label2.Caption := Edit1.Text + ' ist eine Primzahl!'
  else
  begin
    zerlegen(StrToInt(Edit1.Text));
    Label2.Caption := Label2.Caption + '*' + IntToStr(StrToInt(Edit1.Text) div m);
  end;
end;

end.

Allerdings gefällt mir an diesem Code grundsätzlich gesehen die globale variable "m" nicht ...

ciao, Philipp

[Rastaman]

Zitat:

Zitat von xaromz

Ach ja,
in der Routine "Pruefen":

Delphi-Quellcode:

  if p = true then 
    pruefen := true 
  else 
    pruefen := false;

Wie wäre es hier mit

Delphi-Quellcode:

Result := p;

Gruß
xaromz

Delphi-Quellcode:

pruefen := true; 
// ist das Gleiche wie
Result := true;
// einfacher wäre jedoch 
pruefen := p;
//oder halt P ganz wegzulassen

[tn249]

Zwei Sachen hab ich neben der Formatierung noch;

- Die Variablennamen sollten aussagekräftiger sein. ( Was zum Beispiel ist Label1 ? )

- Deine beiden selbstgeschriebenen Funktionen würde ich als Methoden deklarieren. Wenn du nicht weißt was ich damit meine, such mal unter Objectorientierter Programmierung (OOP) bzw dem Stichwort "class" nach.

Gruß
Thomas

[xaromz]

Hallo,

Zitat:

Zitat von Ultimator

Wie gesagt, die Variable p kann man komplett rausoptimieren ;)

An der Prozedur könnte man noch einiges optimieren ;). Aber darum ging es hier ja nicht.

Gruß
xaromz

[Christian Seehase]

Moin Zusammen,

dann möchte ich noch einmal meine Formatierung von if-then-else einwerfen.

Delphi-Quellcode:

// Wenn ich garantiert nur einen Ausdruck benötige, und kein else:
if <Bedingung> then <Ausdruck>;

// Wenn mehrere Ausdrücke benötigt werden, und kein else
if <Bedingung> then begin
  <Ausdruck1>;
  <Ausdruck2>;
  <...>;
end;

// Wenn else benötigt wird, unabhängig von der Anzahl der Ausdrücke (also auch bei nur einem)
if <Bedingung> then begin
  <Ausdruck1>;
end else begin 
  <Ausdruck1>;
end;

Das entspricht zwar nicht dem Borland Style-Guide, aber ich finde dieses Auftürmen von Zeilen

Delphi-Quellcode:

end
else
begin

ausgesprochen schlecht lesbar. Vor allem wird dadurch auch die jeweilige Routine in der Anzahl der Zeilen sehr aufgebläht, und dadurch, u.U., unübersichtlich (wenn ich da nur an geschachtelte if-then-else-Konstruktionen denke...).

[Thanatos81]

Hmm, mein Vorschlag für if..then..else-Konstrukte:

Delphi-Quellcode:

if a then
  begin
    //Anweisung1
    //Anweisung2
  end
else messageDlg('bla', mtError, [mbOK], 0);

bzw.

Delphi-Quellcode:

if a then
  begin
    //Anweisung1
    //Anweisung2
  end
else 
  begin
    //Anweisung1
    //Amweisung2
  end;

bzw.

Delphi-Quellcode:

if a
  then //Anweisung1
  else //Anweisung2

Hab zwar bisher nich niemand anders gesehen, der so einrückt, aber beschwert hat sich von den Kollegen auch noch keiner ;-)

//edit
Wiederholte Satzzeichen wie "????" oder "!!!!" sind für mich auch nicht gerade guter Stil. Google mal nach "Terry Pratchett" und Ausrufezeichen ;-)

[negaH]

Delphi-Quellcode:

function TForm1.pruefen(n: int64): boolean; 
var 
  x: Int64; 
begin 
  Result := True; 
  x := Round(n / 2); 
  if(n >= 2)then 
  begin 
    while(x > 1)do 
    begin 
      if((n mod x) = 0)then 
      begin 
        Result := False; 
        Break; 
      end; 
      Dec(x); 
    end; 
  end 
  else 
    Result := False; 
end;

so würde ich es machen, denn bevor man an der Formatierung arbeitet sollte man den Algorithmus richtig machen.

Delphi-Quellcode:

function TForm1.Pruefen(const N: Int64): Boolean; 
var 
  Root,Candidate: Int64; 
begin 
  Result := Odd(N) and (N > 2)
  if Result then
  begin
    Root := Trunc(Sqrt(N));
    Candidate := 3;
    while Result and (Candidate <= Root) do
    begin
      Result := N mod Candidate <> 0;
      Candidate := Candidate +2;
    end;   
  end else Result := N = 2;   
end;

Man muß für den einfachen Test einer Zahl auf Primzahl nur alle Zahlen kleiner Wurzel(N) die ungerade sind per Trialdivision testen. Desweiteren ist es sinnvoll bei der Trialdivision mit den kleinsten Zahlen beginnend zu testen da es von der Häufigkeitsverteilung der Primzahlfaktoren eher die kleinen Primzahlen sind die am meisten vorkommen. Die meisten zusammengesetzten Zahlen sind also zusammengesetzt aus kleinen Primzahlfaktoren. Die Laufzeit des Algorithmus ist also, wenn man die Trialdivision von unten nach oben laufen lässt, wesentlich besser.

Und wenn es sich vermeiden lässt dann Break/Continue/Exit auch vermeiden.
Desweiteren sollte der Pfad den man einen Source liest bei den Programverzweigungen den am meisten durchlaufenden Pfad folgen. Dh. im obigen Beispiel, das man zuerst im Source den Pfad hat der nun nicht auf 2 als einzigste gerade Primzahl testet.


Gruß Hagen

PS: sowas

Delphi-Quellcode:

  if x then begin
  end;

also das begin OHNE Zeilenumbruch empfinde ich als die übelste Mode die sich in den letzten 10 Jahren eingebürgert hat ! Das entspricht dem Stil eines C Programmieres der versucht 7 verschachtelte Schleife mit 10 Abfragen und Schleifenzählern in eine einzigste Zeile zu pressen.

[tigerman33]

Hi,

also ich empfinde das begin ohne Einrücken ganz im Gegenteil sogar als besser (schließlich mach ich's auch so :mrgreen: ). Die Zugehörigkeit des entsprechenden Blocks zur Schleife/if-Abfrage o.ä. wird durch die Einrückung bereits deutlich. Denn auf solche Konstruktionen wie dies

Delphi-Quellcode:

end
else
begin

kann ich genau wie Christian Seehase gerne verzichten. Auch den viel gepredigten begin-end Block um einzeilige then/else-Zweige oder Schleifen finde ich überflüssig. Das müllt mir bloß den Code zu.

Delphi-Quellcode:

while x > 0 do
  if x < 5 then
    inc(x) else
    dec(x);

halte ich denn doch für deutlich übersichtlicher als

Delphi-Quellcode:

while x > 0 do 
begin
  if x < 5 then
  begin
    inc(x);
  end
  else
  begin
    dec(x);
  end;
end;

Aber da das nur meine persönlichen 2 ct sind und Delphi zum Glück noch keinen zu seinem Glück zwingt kann's ja jeder so machen wie er selbst will.

Gruß
Christian

[Luckie]

Zitat:

Zitat von tigerman33

Auch den viel gepredigten begin-end Block um einzeilige then/else-Zweige oder Schleifen finde ich überflüssig.

Und wie schnell hat man vergessen ihn nachträglich einzufügen, wenn man den nicht vorhandenen Block erweitert. Und dann wundert man sich, warum das Programm aufeinmal nicht das macht, was es soll.

[tigerman33]

Ist erstens relativ offensichtlich, der Fehler, und mir persönlich auch noch nicht passiert.

[sECuRE]

Hi,

Zitat:

Zitat von tigerman33

kann ich genau wie Christian Seehase gerne verzichten. Auch den viel gepredigten begin-end Block um einzeilige then/else-Zweige oder Schleifen finde ich überflüssig. Das müllt mir bloß den Code zu.

Da stimme ich zu. Allerdings hab' ich noch etwas anzumerken:

Zitat:

Zitat von tigerman33

Delphi-Quellcode:

while x > 0 do
  if x < 5 then
    inc(x) else
    dec(x);

Das else würde ich an den Zeilenanfang setzen, denn wenn man schnell über Code liest, und einen der ausgeführte Text der if-Bedingung nicht interessiert, liest man die Zeile für gewöhnlich nicht zu Ende - und übersieht eventuell das else.

Letztendlich würde ich es so machen:

Delphi-Quellcode:

// 1) const sorgt eventuell für schnellere Parameterweitergabe, sicher aber dafür,
// dass man sich nicht einfach Variablen überschreibt
// 2) ein normaler Integer langt und ist auf 32bit-CPUs schneller berechnet
// - StrToInt liefert auch nur einen Integer und keinen int64
// 3) Funktionsname:
// Man prüft bei der Verwendung von functions *generell* - Was wird also geprüft?
function IstPrim(const n:integer):boolean;
var x:integer;
begin
  // Sonderfall 1 beachten
  if (n = 1) then begin
    result:=false;
    exit;
  end;

  // Deine Primzahlprüfung hab' ich nicht ganz verstanden. Warum prüfst du nur die Teiler
  // bis Round(N / 2)? Normalerweise prüft man doch von 2 bis Sqrt(N)!
  result:=true;
  for x:=2 to Trunc(Sqrt(N)) do
    if ((n mod x) = 0) then begin
      result:=false;
      exit;
    end;
end;


// integer: siehe oben
procedure Zerlegen(var OutputLabel:TLabel; const n:integer); 
var x:integer; 
begin 
  x:=2; 
  while ((n mod x) <> 0) do 
    Inc(c);

  // Die Bedingung vorher war Schwachsinn (*sorry*) 
  OutputLabel.Caption:=OutputLabel.Caption+'*'+IntToStr(x); 

  if (not IstPrim(n div x)) then 
    Zerlegen(n div x); 

  m:=m*x; 
end; 

procedure TForm1.Button1Click(Sender: TObject); 
begin 
  m:=1; 
  label2.Caption:=''; 
  if (IstPrim(strtoint(edit1.Text))) then 
    Label2.Caption:=edit1.Text+' ist eine Primzahl!' 
  else begin 
    Zerlegen(Label2, StrToInt(Edit1.Text)); 
    Label2.Caption:=Label2.Caption+'*'+IntToStr(StrToInt(Edit1.Text) div m); 
  end; 
end;

Die globale Variable m hab' ich erst mal dringelassen, ich hab' ja schon genug anderes kritisiert ;).

cu

[negaH]

@Secure:

sorry aber

Delphi-Quellcode:

function IstPrim(const n:integer):boolean; 
var x:integer; 
begin 
  // Sonderfall 1 beachten 
  if (n = 1) then begin 
    result:=false; 
    exit; 
  end; 

  // Deine Primzahlprüfung hab' ich nicht ganz verstanden. Warum prüfst du nur die Teiler 
  // bis Round(N / 2)? Normalerweise prüft man doch von 2 bis Sqrt(N)! 
  result:=true; 
  for x:=2 to Trunc(Sqrt(N)) do 
    if ((n mod x) = 0) then begin 
      result:=false; 
      exit; 
    end; 
end;

halte ich fr ziemlich übel.

1.) Du vereinfachst durch eigene Annahmen die gewünschte Funktionsweise des Programmieres, indem du enifach mal davon ausgehst das man eh nur Zahlen bis 2^31 testen möchte, statt eben wie im Original mit Int64 zu rechnen. Das ist wohl sehr schlechter Stil. Die Aufgabe des programmieres ist es die Forderungen EXAKT umzusetzen.

2.) dein Source ist fehlerhaft. Was ist mit 0, oder -1 oder allen Zahlen bis -(2^31-1). Übergibt man deiner Funktion einen Integer im Wertebereich der Integer von -2^31 bis 2^31 dann macht sie defacto exakt 50% Fehlerhafte Ausagen.

3.) dein Schreibstil, hm naja. Das Besondere in PASCAL ist es das man Gorß/Klein Schreibung als Mittel zu besseren Lesbarkeit einsetzen kann. Du verzichtest darauf indem du alles klein schreibst. Damit verzichtest du auf Übersichtlickeit.

4.) N. Wirth hat mit Absicht die "Gültigkeit eines Source Blocks" visuell grafisch auch als eingerückter Block mit einem senkrecht untereinander stehendem BEGIN und END eingeführt. Es ist also essentiell das BEGIN und END auf gleicher Einrückungsebene zu schreiben.

5.) was nun ? IstPrim() oder IsPrime() ? aber nicht IsPrim() das ist denglish.

6.) in der Mathemtik ist es üblich N als Synonym für eine Natürlich Zahl zu betrachten, so wie R für rationelle Zahlen etc.pp.

7.) Sonderfall 1 ist zu wenig und berücksicht eben nicht negative Zahlen

8.) die Berechnung in for X := 0 to Trunc(Sqrt(n)) ist zwar auf Grund des Delphi Compilers möglich sollte aber aus Sicht eines Standard PASCAL Codes vermieden werden. Unter Umständen, bei erweiterte PASCAL Dialekten mit einer for i to x step y Syntax ist nämlich x als Schleifenendebedingung dynamisch veränderbar.

9.) wenn es geht sollte man immer auf unnötige Sprachkonstruke verzichten und statt dessen mit "mathematischen" Zuweisungen arbeiten.

10.) wenn es geht exit/goto/continue vermeinden

11.) man muß nur mit ungeraden Zahlen die Trialdivision durchführen. Da es aber in Delphi keine for i tox step y Schleife gibt müsste man sich behelfen mit for x := 2 to Trunc(Sqrt(N)) div 2 do und mit if N mod (i*2+1) = 0 arrbeiten, um eben den offensichtlichen mathematischen Erfordernissen gerecht zu werden. Es geht hier um Exaktheit in der Programmier Arbeit die man leistet. Allerdings ist eine solche Zähleschleife wesentlich schlechter zu verstehen als eine while Schleife. In deinem Falle testet deine Funktion die Zahl N doppelt so häufig als es nötig wäre, ergo Effizienzeinbußen.

Delphi-Quellcode:

function IsPrime(const N: Int64): Boolean;
var
  Root,Candidate: Int64;
begin
  Result := Odd(N) and (N > 2);  // Eine Primzahl ist ungerade und größer 1, ausser der 2
  if Result then
  begin
     // da wir N als Int64 vorgegeben haben können wir NICHT per Zählschleifen arbeiten, Delphi unterstützt
     // keine Int64 als Schleifenzähler, ergo while schleife
     Root := Trunc(Sqrt(N));
     Candidate := 3;
     while Result and (Candidate < Root) do
     begin
       Result := N mod Candidate <> 0;  // statt IF THEN eine mathematische, boolsche Zuweisung
       Candidate := Candidate + 2;
     end;      
  end else 
    Result := N = 2; // den einzigsten Fall einer geraden Primzahl berücksichtigen
                     // statt IF THEN eine boolsche Zuweisung 
end;

[Khabarakh]

Es muss

Delphi-Quellcode:

while Result and (Candidate <= Root) do

statt

Delphi-Quellcode:

while Result and (Candidate < Root) do

heißen, da ja schon mit Trunc abgerundet wurde.

[edit]In deiner ersten Funktion ist es noch richtig, da fehlt dafür ein Semikolon :zwinker: . [/edit]

[negaH]

Delphi-Quellcode:

while x > 0 do 
  if x < 5 then 
    inc(x) else 
    dec(x);

sowas ist ebenfalls schlecht, das es nicht mehr grafisch von link nach rechts erfassbar ist. Man muß also immer ganz genau lesen damit man weis was passiert.

Delphi-Quellcode:

while x > 0 do  
begin
  if x < 5 then
  begin
    Inc(x);
  end 
  else
  begin
    Dec(X);
  end; 
end;

das wäre Standard konform, ist aber ziemlich aufgebläht, also hat man auch im Standard Vereinfachungen der Schreibweise berücksichtigt. ABER das dann grafisch konform mit "virtuellen" Einrückungen a 2 Zeichen.

Delphi-Quellcode:

while x > 0 do
  if x < 5 then
  begin
    Inc(x);
  end 
  else
  begin
    Dec(x);
  end;

Man hat also das begin end aus dem while Sourceblock entfernt, aber ALLES nach dem while ist weiterhin 2 Zeichen grafisch eingerückt. Jeder PASCAL Bezeichner ist steht dabei am Anfang dieser Einrückung, nicht irgendwo.

Nun entfernen wie die unnötigen begin end blöcke

Delphi-Quellcode:

while x > 0 do
  if x < 5 then
    Inc(x);
  else
    Dec(x);

Das sieht schonmal sehr gut aus. Alles ist noch in 2'er Einrückungen Anweisung für Anweisung an ihrer grafischen Position links stehend.

Abfragen wie IF THEN ELSE wurden weiter vereinfacht indem die Regel hinzukam das man deren Anweisungen auf gleiche Zeile hochziehen kann. Die betrifft auch das else. Dabei ist aber zu beachten das man alles hochzieht.

Delphi-Quellcode:

while x > 0 do
  if x < 5 then Inc(x)
    else Dec(x);

Der else Zweig sollte nun ebenfalls 2 Zeichen eingerück werden da er defakto ja ein eigener Sourceblock darstellt und ohne die Einrückung der if then Sourceblock damit grafisch verschmelzen würde.

Wichtig ist einfach:
- man liest von Link nach Rechts
- eine 2 Zeichen Einrückung markiert grafisch einen Sourceblock, sprich einen lokalen Gültigkeitsbereich, oder eine Programmverzweigungsblock.
- am Anfang dieser Einrückungen steht der PASCAL Sprachbezeichner und danach das was passiern soll, also immer LINKS->RECHTS.

Delphi-Quellcode:

// Links      Rechts

while         -> x > 0
  if          -> x < 5  -> inc(x)
    else                -> dec(x)

Man sieht sehr deutlich die sich grafisch ergebende Hierarchie der Abarbeitung im Programmfluß.

Gruß Hagen

[negaH]

Das Auseinanderreißen von Sparchkostrukten ist ebenfalls schlechter Stil, also sowas:

Delphi-Quellcode:

if x > 0
  then

while x > 0 
  do

repeat
until 
  x > 0;

Bei all diesen Konstrukten gehört alles in eine Zeile, also so

Delphi-Quellcode:

while Bedingung do

if Bedingung then

repeat
until Bedingung;

Das ist ganz einfach begründet, denn die EINFACHSTE Programmverzweigung, nämlich keine, wird durch ein BEGIN markiert.

Delphi-Quellcode:

function XYZ(): Result;
begin                     // <-
   
  begin                   // <- separater Programblock
    ABC;
  end;

end;

Die bedingten Programmverzweigungen ersetzen nun einfach dieses begin

Delphi-Quellcode:

function XYZ(): Result;
begin                     // <-

// be-         -gin
  if Bedingung then                 // <- separater Programblock
    ABC;

  
// be-         -gin
  while Bedinung do
    ABC


  repeat
    ABC;
  until Bedingung;       // logisch betrachtet einfach mal umdrehen und so betrachten

  until Bedingung   
    ABC;
  repeat
     
end;

Gruß Hagen

[sECuRE]

Hi Hagen,

Zitat:

Zitat von negaH

@Secure:

sorry aber [...] halte ich fr ziemlich übel.

1.) Du vereinfachst durch eigene Annahmen die gewünschte Funktionsweise des Programmieres, indem du enifach mal davon ausgehst das man eh nur Zahlen bis 2^31 testen möchte, statt eben wie im Original mit Int64 zu rechnen. Das ist wohl sehr schlechter Stil. Die Aufgabe des programmieres ist es die Forderungen EXAKT umzusetzen.

Was war denn die Forderung? Ich habe nur gelesen, dass es sich um ein Programm zum Primfaktorzerlegung handelt und gesehen, dass der Autor die Zahlen über ein Edit via StrToInt einliest. Folgedem ist ein integer ideal, da er - im Gegensatz zu einem int64 - schneller berechnet wird und alle Werte, die StrToInt zurückliefern kann, aufnehmen kann. Die Aufgabe, die ich mir beim Programmieren setze, ist, optimal zu Programmieren, in erster Linie in Hinblick auf Geschwindigkeit, im zweiten Hinblick auf Ästhetik.

Zitat:

Zitat von negaH

2.) dein Source ist fehlerhaft. Was ist mit 0, oder -1 oder allen Zahlen bis -(2^31-1). Übergibt man deiner Funktion einen Integer im Wertebereich der Integer von -2^31 bis 2^31 dann macht sie defacto exakt 50% Fehlerhafte Ausagen.

OK, habe ich verbessert.

Zitat:

Zitat von negaH

3.) dein Schreibstil, hm naja. Das Besondere in PASCAL ist es das man Gorß/Klein Schreibung als Mittel zu besseren Lesbarkeit einsetzen kann. Du verzichtest darauf indem du alles klein schreibst. Damit verzichtest du auf Übersichtlickeit.

Großschreiben wird allgemein als Schreien angesehen, und ich schreie meinen Compiler/Computer/wasauchimmer nicht an ;). Außerdem verwende ich sehr wohl Groß-/Kleinschreibung, allerdings hauptsächlich bei Variablen- und Funktionsnamen, dort, wo es eben sinnvoll ist.

Zitat:

Zitat von negaH

4.) N. Wirth hat mit Absicht die "Gültigkeit eines Source Blocks" visuell grafisch auch als eingerückter Block mit einem senkrecht untereinander stehendem BEGIN und END eingeführt. Es ist also essentiell das BEGIN und END auf gleicher Einrückungsebene zu schreiben.

Ich finde, dass sich der Quelltext dadurch nur um eine weitere Zeile aufbläht. Logisch ist die genaue Einteilung mit begin/end ohnehin für Menschen nicht (IMO): Schließlich ist es ja egal, wie viele Anweisungen danach folgen (nach einer if-Bedingung zB), es muss nur dem Compiler genau gesagt werden.

Zitat:

Zitat von negaH

5.) was nun ? IstPrim() oder IsPrime() ? aber nicht IsPrim() das ist denglish.

Wenn du genau hinschaust, wirst du feststellen, dass ich IstPrim geschrieben habe.

Zitat:

Zitat von negaH

6.) in der Mathemtik ist es üblich N als Synonym für eine Natürlich Zahl zu betrachten, so wie R für rationelle Zahlen etc.pp.

Ich bin Programmierer und kein Mathematiker.

Zitat:

Zitat von negaH

7.) Sonderfall 1 ist zu wenig und berücksicht eben nicht negative Zahlen

Hast du mir doch in 2.) schon gesagt?

Zitat:

Zitat von negaH

8.) die Berechnung in for X := 0 to Trunc(Sqrt(n)) ist zwar auf Grund des Delphi Compilers möglich sollte aber aus Sicht eines Standard PASCAL Codes vermieden werden. Unter Umständen, bei erweiterte PASCAL Dialekten mit einer for i to x step y Syntax ist nämlich x als Schleifenendebedingung dynamisch veränderbar.

Ich programmiere Delphi, kein Pascal.

Zitat:

Zitat von negaH

9.) wenn es geht sollte man immer auf unnötige Sprachkonstruke verzichten und statt dessen mit "mathematischen" Zuweisungen arbeiten.

Hast du dafür ein konkretes Beispiel?

Zitat:

Zitat von negaH

10.) wenn es geht exit/goto/continue vermeinden

Warum? Es ist doch die effizienteste Methode, hier aus der Schleife zu springen, oder sehe ich das falsch?

Zitat:

Zitat von negaH

11.) man muß nur mit ungeraden Zahlen die Trialdivision durchführen. Da es aber in Delphi keine for i tox step y Schleife gibt müsste man sich behelfen mit for x := 2 to Trunc(Sqrt(N)) div 2 do und mit if N mod (i*2+1) = 0 arrbeiten, um eben den offensichtlichen mathematischen Erfordernissen gerecht zu werden. Es geht hier um Exaktheit in der Programmier Arbeit die man leistet. Allerdings ist eine solche Zähleschleife wesentlich schlechter zu verstehen als eine while Schleife. In deinem Falle testet deine Funktion die Zahl N doppelt so häufig als es nötig wäre, ergo Effizienzeinbußen.

Hmm, da kann' ich so spontan nicht zustimmen. Was ist zum Beispiel mit 8? Die Wurzel von 8 ist 2, das dann nochmal geteilt durch 2 ist 1 und deine Schleife würde gar nicht ausgeführt!

Ich hab' meinen Source verbessert (war übrigens auf Grund von zwei Tippfehlern vorher nicht lauffähig):

Delphi-Quellcode:

function IstPrim(const n:integer):boolean;
var x:integer;
begin
  // Sonderfälle beachten
  if (n <= 1) then begin
    result:=false;
    exit;
  end;

  result:=true;
  for x:=2 to Trunc(Sqrt(N)) do
    if ((n mod x) = 0) then begin
      result:=false;
      exit;
    end;
end;

// eine meiner Lieblingsfunktionen ;)
// bildet das (<condition>?<true>:<false>)-Konstrukt aus C/PHP nach
function iif(const Condition:boolean; const IfTrue,IfFalse:string):string;
begin
  if (Condition) then
    result:=IfTrue
  else result:=IfFalse;
end;

// integer: siehe oben
procedure Zerlegen(var OutputLabel:TLabel; const n:integer);
var x:integer;
begin
  x:=2;
  while ((n mod x) <> 0) do
    Inc(x);

  // Korrektur: OK, so schwachsinnig war sie doch nicht. Hab' mich verlesen.
  OutputLabel.Caption:=OutputLabel.Caption+iif(length(OutputLabel.Caption) > 0,'*','')+IntToStr(x);

  if (not IstPrim(n div x)) then
    Zerlegen(OutputLabel,n div x);

  m:=m*x;
end;


procedure TForm1.Button1Click(Sender: TObject);
begin
  m:=1;
  label2.Caption:='';
  if (IstPrim(strtoint(edit1.Text))) then
    Label2.Caption:=edit1.Text+' ist eine Primzahl!'
  else begin
    Zerlegen(Label2, StrToInt(Edit1.Text));
    Label2.Caption:=Label2.Caption+'*'+IntToStr(StrToInt(Edit1.Text) div m);
  end;
end;

cu

[himitsu]

Zuviel rede ich eh nicht mit, da ich ja sowieso meinen eigenen "guten" Programierstil hab :roll:

Aber zu dem ELSE, meiner Meinung nach hat das die selbe Wertigkeit wie das IF und wird demnach nicht eingerückt.

Delphi-Quellcode:

If ... Then ...
Else ...;

// bei kurzen Blöcken auch mal 
If ... Then ... Else ...;

If ... Then Begin
  ...;
End Else ...;

If ... Then Begin
  ...;
End Else Begin
  ...;
End;

If ... Then Begin
  ...;
End Else If ... Then Begin
  ...;
End Else Begin
  ...;
End;

Das BEGIN ziehe ich mit auf die Zeile mit der Bedingung/Schleife ... daß die nachfolgenden Codezeilen zu der Bedingung/Schleife gehöen sehe ich ja an der Einrückung ^^

Delphi-Quellcode:

If ... Then Begin
  ...;
  ...;
  ...;
End;

If ... Then
  ...;
...;
...;

If ... Then ...;
...;
...;

Und irgendwie finde ich meine Version übersichtlicher, als eure ._.

Delphi-Quellcode:

// MEINE
If ... Then Begin
  ...;
End Else If ... Then Begin
  ...;
End Else Begin
  ...;
End;

// das Andere
If ... Then
Begin
  ...;
End
Else
  If ... Then
  Begin
    ...;
  End
  Else
    Begin
      ...;
    End;

Und ja, ich mache manchmal immernoch mehrere Befehle in eine Zeile, wenn es logisch zusammengehört und so auch noch übersichtlicher ist :tongue:



[add]
zu der einen Funktion ... wie siht das für dich aus?

Delphi-Quellcode:

function IstPrim(const n: integer): boolean; 
var i: integer; 
begin 
  result := false; 
  if n <= 1 then exit;          // Sonderfälle beachten 
  for i := 2 to Trunc(Sqrt(N)) do 
    if n mod i = 0 then exit; 
  result := true; 
end;

[turboPASCAL]

Delphi-Quellcode:

// A) IF - Kurtzschreibweise
if ... then  ...;

// B) IF - Kurtzschreibweise mit Elsezweig
if ... then ... else ...;

// C) IF - Kurtzschreibweise mit Elsezweig in neuer Zeile
if .......... then ........
  else .......... ;

// D) IF - Schreibweise mit Elsezweig 
if ....................
  then ....................;
  else ....................

// D) IF - BlockSchreibweise
if .................... then
begin
  ....................;
  ....................
end;

// E) IF - BlockSchreibweise und Else-Zweig
if .................... then
begin
  ....................;
  ....................
end else
begin
  ....................;
  ....................
end;

// oder:
if .................... then
begin
  ....................;
  ....................
end
else
begin
  ....................;
  ....................
end;

// auch ne Art, kann aber in der VCL lang wedern ;-)
if ...... then ...... else
  if ...... then ...... else
    if ...... then ...... else .....;

// kann ich nich leiden ;-)

// 1.
if .................... then begin
  ....................;
  ....................
end
else begin
  ....................;
  ....................
end;


// 2. ( unübersichtlich )
if ... then ...
else ...

:stupid:

[tigerman33]

Also, ich denke solange sich der Programmierer bei seinen Einrückungen was gedacht hat und vor allem den Stil konsistent durchzieht (!!) macht es nicht so den großen Unterschied ob er jetzt

Delphi-Quellcode:

if ... then begin
end else begin
end;

oder

Delphi-Quellcode:

if ... then 
begin
end 
else 
begin
end;

oder noch irgendwas anderes schreibt. Ist auch zu einem gut Teil Geschmackssache. Nur durcheinander würfeln sollte man das nicht.

[Der_Unwissende]

HI,
ich möchte hier nur der Vollständigkeit halber mal erwähnen, dass wohl eh jeder ein wenig seinen eigenen Stil hat. Das ist auch ganz gut so, sonst wäre die Vielfalt, die wie wir an Programmen haben wahrscheinlich sehr viel geringer.

Aber wichtig ist es überhaupt einen zu haben und den auch konsequent durchzusetzen. Es gibt dabei kein perfekt oder richtig, aber es gibt eine Menge falsch. So gehört (einhellige Meinung vieler Menschen die sich damit beschäftigt haben) zu einem guten Stil, dass man überflüssige Fehler einfach schon durch den Stil vermeidet. Dazu gehören insbesondere Kommentare und natürlich begin und end um Blöcke.
Genauso sollte es keine leeren except Abschnitte geben, wenn dann doch mal ein Fehler auftaucht...

Es gibt nette Bücher die sich mit dem Thema beschäftigen und auch wenn es nicht direkt Delphi ist, kann ich da "The Elements of Java Style" nur wärmstens empfehlen, die bringen in 108 Punkten eine Menge Erfahrung unter.

Das Wichtigste ist und bleibt aber, dass es nur Guides sind, es sind keine Vorschriften. Man profitiert davon sich an ihnen zu orientieren und in vielen Punkten lernt man sicherlich was dazu, aber man muss eben nicht alles übernehmen. Gerade für eine Firma ist es einfach wichtig, dass Code verstanden wird, egal von wem (also jetzt in der zuständigen Abteilung!). Hier ist es also wirklich wichtig, dass eben nicht jeder seinen Stil verfolgt, sondern einfach besser einen Stil fest zu schreiben, den dann aber jeder gleich lesen und verstehen kann. Über die einzelnen Punkte kann man dann immer noch streiten ;-)

Gruß Der Unwissende

[negaH]

Zitat:

Zitat:

Zitat von negaH

4.) N. Wirth hat mit Absicht die "Gültigkeit eines Source Blocks" visuell grafisch auch als eingerückter Block mit einem senkrecht untereinander stehendem BEGIN und END eingeführt. Es ist also essentiell das BEGIN und END auf gleicher Einrückungsebene zu schreiben.

Ich finde, dass sich der Quelltext dadurch nur um eine weitere Zeile aufbläht. Logisch ist die genaue Einteilung mit begin/end ohnehin für Menschen nicht (IMO): Schließlich ist es ja egal, wie viele Anweisungen danach folgen (nach einer if-Bedingung zB), es muss nur dem Compiler genau gesagt werden.

Und genau das ist die falsche Sichtweise. Du versuchst die Anzahl an Zeilen zu optimieren statt sich darauf zu konzentrieren so viele Zeilen an Source zu schreiben wie es notwendig ist ein Problem auch deutlich und einfach verstehbar zu umschreiben. Deine Zielsetzung konzentiert sich auf ein Detail statt auf das gesammte Problem.

Zitat:

Zitat:

Zitat von negaH

5.) was nun ? IstPrim() oder IsPrime() ? aber nicht IsPrim() das ist denglish.

Wenn du genau hinschaust, wirst du feststellen, dass ich IstPrim geschrieben habe.

Hä, hast du das editiert ? Ich kann mich erinnern das dort noch IsPrim() stand. Falls nicht, sorry, ändert aber nichts an der Aussage ansich ;) Es bezieht sich ja nicht persönlich auf dich sondern gilt eher allgemein.

Zitat:

Zitat:

Zitat von negaH

6.) in der Mathemtik ist es üblich N als Synonym für eine Natürlich Zahl zu betrachten, so wie R für rationelle Zahlen etc.pp.

Ich bin Programmierer und kein Mathematiker.

Doch bist du, sind wir alle.
Die Hardware basiert auf der Boolschen Algebra, und in der Programmierung ist es immer von Vorteil auch ein bischen Mathematik zu beherrschen.

Davon abgesehen versucht, bei unserem speziellen Problem, ein Programmierer ein rein mathematisches Problem in eine Software umzusetzen. Es ist aber fatal eine Sichtweise an den Tag zu legen die im Grunde ignorant ist. Denn deine Aussage heist für mich persönlich das du eine mathemtische Aufgabe nicht deshalb mathematisch korrekt angehen möchtest weil du sagt "na und, ich bin Programmierer und kein Mathematiker". Das ist ignorant und meiner Meinung nach eben auch ein "schlechter Programmierstil". Programmierstil bedeutet nicht wie der Souce aussieht, nein das ist nur eine Wirkung der Ursache. Und die Ursache für einen guten Programmierstil ist die Frage WIE der Programmierer ein Problem lösst. Und handelt es sich um ein Problem der Mathematik dann sollte er es auch so angehen. An Hand des Sources kann man also durchaus erkennen ob ein Programmierer sachlich fundiert und sauber ein Problem angegangen ist. Ist dies der Fall dann ist der Source sauber formatiert, folgt einer Logik, ist nachvollziehbar und umschreibt das zu lösende Problem auch für Andere verständlich. Ein Source ist dann nicht nur ein Source sondern quasi ein Lehrbuch das mit eigener Sprache ein Problem erklärt.

Zitat:

Zitat:

Zitat von negaH

7.) Sonderfall 1 ist zu wenig und berücksicht eben nicht negative Zahlen

Hast du mir doch in 2.) schon gesagt?

Nicht nur. Ich meinte das man bei dieser schnellen "Eingangsüberprüfung" gleich nebenbei abprüfen kann

1.) ist Zahl ungerade ?
2.) ist Zahl größer 2 ?

Man schließt damit also implizit Zahlen aus die

1.) negativ sind
2.) gleich Null sind
3.) gleich Eins sind
4.) gleich dem Spezialfall der einzigsten gerade Primzahl 2 sind
5.) gerade Zahlen sind

Diese 5 Bedingungen werden mit

Result := Odd(N) and (N > 2);

abgefragt.

Zitat:

Zitat:

Zitat von negaH

8.) die Berechnung in for X := 0 to Trunc(Sqrt(n)) ist zwar auf Grund des Delphi Compilers möglich sollte aber aus Sicht eines Standard PASCAL Codes vermieden werden. Unter Umständen, bei erweiterte PASCAL Dialekten mit einer for i to x step y Syntax ist nämlich x als Schleifenendebedingung dynamisch veränderbar.

Ich programmiere Delphi, kein Pascal.

Und wieder eine Form der Ignoranz. (ich würde sogar sagen Trotzigkeit).
Es sollte im Bestreben jedes Programmieres sein nicht mit Scheuklappen rumzurennen, sondern auch andere Programmiersprachen und deren Konzepte zu erlernen und zu beherrschen.

Zitat:

Zitat:

Zitat von negaH

9.) wenn es geht sollte man immer auf unnötige Sprachkonstruke verzichten und statt dessen mit "mathematischen" Zuweisungen arbeiten.

Hast du dafür ein konkretes Beispiel?

Ja, das obige. Es enthält sogar 3 solcher Fälle:

Delphi-Quellcode:

 Result := Odd(N) and (N > 2); 
 Result := N mod Candidate <> 0;
 Result := N = 2;

statt

Delphi-Quellcode:

if Odd(N) then
  if N > 2 then Result := True
    else Result := False
  else Result := False;

if N mod Candidate = 0 then
begin
  Result := False;
  Exit;
end;

Das eine ist eine mathematische Sichtweise, Denkweise als Formel. Das andere ist eine rein Algortihmische, ja fast schon Maschinen-denkweise.

Denn wie du siehst, benutzt man quasi eine mathematische Formel für die Umschreibung eines Sachverhaltes so ergibt sich auch automatisch der Fall das man eben nicht mit Exit; arbeiten muß, sondern stattdessen eine Result Variable zuweist und diese sauber als Bedingung in der while do Schleife als Abbruchbedingung abfragt.

Zitat:

Zitat:

Zitat von negaH

10.) wenn es geht exit/goto/continue vermeinden

Warum? Es ist doch die effizienteste Methode, hier aus der Schleife zu springen, oder sehe ich das falsch?

weil durch diese Anweisungen der aktuelle Programmblock irregulär verlassen oder weitergeführt wird.
Ein Exit zb. springt direkt aus dem aktuellen und hierarisch geschachtelten Programmblock und verlässt die komplette Funktion/Procedure. Exit zerstört also den grafisch hierarischen Source Aufbau, somit den Lesefluß eines anderen Programmieres und finally damit auch die Verständlichkeit.

Allerdings sehe ich diesen Punkt nicht allzu dramatisch, denn es gibt durchaus Fälle in denen ein goto/exit durchaus eine enorme Steigerung der Effizienz im erzeugten Code zur Folge hat.
Dies ist aber in unserem Beispiel eben nicht der Fall, ergo gibt es keine logische Begründung Exit noch zu verwenden.

Eines kann ich dir aber mit Sicherheit garantieren:
der Vorteil deines Exits ist so gering das es den Peformancevorteil meiner Funktion auf Grund der algorithmischen Verbesserungen unmeßbar gering ausfällt.

Zitat:

Zitat:

Zitat von negaH

11.) man muß nur mit ungeraden Zahlen die Trialdivision durchführen. Da es aber in Delphi keine for i tox step y Schleife gibt müsste man sich behelfen mit for x := 2 to Trunc(Sqrt(N)) div 2 do und mit if N mod (i*2+1) = 0 arrbeiten, um eben den offensichtlichen mathematischen Erfordernissen gerecht zu werden. Es geht hier um Exaktheit in der Programmier Arbeit die man leistet. Allerdings ist eine solche Zähleschleife wesentlich schlechter zu verstehen als eine while Schleife. In deinem Falle testet deine Funktion die Zahl N doppelt so häufig als es nötig wäre, ergo Effizienzeinbußen.

Hmm, da kann' ich so spontan nicht zustimmen. Was ist zum Beispiel mit 8? Die Wurzel von 8 ist 2, das dann nochmal geteilt durch 2 ist 1 und deine Schleife würde gar nicht ausgeführt!

Siehst du: ein guter Programmierstil fördert die Verständlichkeit beim Lesen durch Andere.
Anscheinend habe ich da aber vollständig versagt ;) sonst hättest du meine Source auch verstanden und erkannt das der Fall 8 = gerade Zahl garnicht, nein niemals garnicht never, in der while Schleife auftreten kann.

Wenn ich eine Funktion haben möchte die abfragt ob N eine Primzahl ist dann kann ich von vornherein mit Odd(N) 50% aller Zahlen sehr sehr effizient ausschließen, nämlich alle geraden Zahlen wie auch die 8.

Bei der eigentlichen Trialdivision werden also nur ungerade Zahlen überprüft. Auch da wiederum müssen wir nicht modulo jeder Zahl testen denn das minimal Set der Zahlen mit denen man Modulo testen muß sind alle Primzhalen bis Wurzel(N). Der Einfachheit halber nehmen wir alle ungeraden Zahlen, was 50% weniger ist als in deinem Falle, aber immer noch weit mehr als notwendig.

Gruß Hagen

[sECuRE]

Hi Hagen,

Zitat:

Zitat von negaH

Und genau das ist die falsche Sichtweise. Du versuchst die Anzahl an Zeilen zu optimieren statt sich darauf zu konzentrieren so viele Zeilen an Source zu schreiben wie es notwendig ist ein Problem auch deutlich und einfach verstehbar zu umschreiben. Deine Zielsetzung konzentiert sich auf ein Detail statt auf das gesammte Problem.

Mit der schwindenen Anzahl an Zeilen erhöht sich die Anzahl selbiger, die auf meinen Bildschirm passen und somit auch meine Effizienz beim Arbeiten ;). Ich versuche nicht krampfhaft Zeilen zu optimieren, sondern dort, wo es für mich sinnvoll ist.

Zitat:

Zitat von negaH

Hä, hast du das editiert ? Ich kann mich erinnern das dort noch IsPrim() stand. Falls nicht, sorry, ändert aber nichts an der Aussage ansich ;) Es bezieht sich ja nicht persönlich auf dich sondern gilt eher allgemein.

Nein, hab' ich nicht editiert. Vielleicht kannst du aus dem Link meiner Signatur entnehmen, dass ich mich für die deutsche Sprache interessiere und daher auch vor Anglizismen erstmal zurückschrecke; mich erstmal frage, ob sich das nicht auch auf Deutsch genauso verständlich ausdrücken lässt.

Zitat:

Zitat von negaH

Doch bist du, sind wir alle.
Die Hardware basiert auf der Boolschen Algebra, und in der Programmierung ist es immer von Vorteil auch ein bischen Mathematik zu beherrschen.

Nein, da muss ich dir widersprechen. Mathematiker sind nicht gleich Programmierer (ich sage nicht Informatiker!) und auch nicht umgekehrt, da die einzelnen Gebiete doch sehr unterschiedlich sind, gerade wenn es um komplexe Fälle geht. Ich sehe mich jedenfalls definitiv nicht als Mathematiker, davon hab' ich viel zu wenig Ahnung.

Zitat:

Zitat von negaH

Davon abgesehen versucht, bei unserem speziellen Problem, ein Programmierer ein rein mathematisches Problem in eine Software umzusetzen. Es ist aber fatal eine Sichtweise an den Tag zu legen die im Grunde ignorant ist. Denn deine Aussage heist für mich persönlich das du eine mathemtische Aufgabe nicht deshalb mathematisch korrekt angehen möchtest weil du sagt "na und, ich bin Programmierer und kein Mathematiker". Das ist ignorant und meiner Meinung nach eben auch ein "schlechter Programmierstil". Programmierstil bedeutet nicht wie der Souce aussieht, nein das ist nur eine Wirkung der Ursache. Und die Ursache für einen guten Programmierstil ist die Frage WIE der Programmierer ein Problem lösst. Und handelt es sich um ein Problem der Mathematik dann sollte er es auch so angehen. An Hand des Sources kann man also durchaus erkennen ob ein Programmierer sachlich fundiert und sauber ein Problem angegangen ist. Ist dies der Fall dann ist der Source sauber formatiert, folgt einer Logik, ist nachvollziehbar und umschreibt das zu lösende Problem auch für Andere verständlich. Ein Source ist dann nicht nur ein Source sondern quasi ein Lehrbuch das mit eigener Sprache ein Problem erklärt.

Nun, ich möchte sie schon mathematisch korrekt angehen, ich sagte ja nicht, dass ich, weil ich kein Mathematiker bin, mir erlaube, einfach gewissenslos Fehler zu machen. Allerdings ist die Wahl der Variablennamen schon fast Geschmackssache und sollte meiner Meinung nach nicht unbedingt mathematischen Gepflogenheiten angepasst sein.

Zitat:

Zitat von negaH

Nicht nur. Ich meinte das man bei dieser schnellen "Eingangsüberprüfung" gleich nebenbei abprüfen kann

1.) ist Zahl ungerade ?
2.) ist Zahl größer 2 ?

Man schließt damit also implizit Zahlen aus die

1.) negativ sind
2.) gleich Null sind
3.) gleich Eins sind
4.) gleich dem Spezialfall der einzigsten gerade Primzahl 2 sind
5.) gerade Zahlen sind

Diese 5 Bedingungen werden mit

Result := Odd(N) and (N > 2);

abgefragt.

OK, das wurde mir aus deinem Post vorher nicht klar.

Zitat:

Zitat von negaH

Und wieder eine Form der Ignoranz. (ich würde sogar sagen Trotzigkeit).
Es sollte im Bestreben jedes Programmieres sein nicht mit Scheuklappen rumzurennen, sondern auch andere Programmiersprachen und deren Konzepte zu erlernen und zu beherrschen.

Ja, diesmal ist es Trotzigkeit. Ich muss mich in der Schule teilweise mit Turbopascal herumärgern und meine das wörtlich; was da alles fehlt, ist unglaublich, wenn man sich einmal an Delphi gewöhnt hat (dynamische Arrays, bequeme Klassen, Dateinamen größer 8.3 Zeichen (gut, das hat mehr mit der IDE zu tun und den damals üblichen Beschränkungen)). Als Ersatz für Turbopascal bin ich nun auf Freepascal umgestiegen und komme damit ziemlich gut klar, für mich fällt das auch unter Delphi Language, was man damit kompilieren kann. Daher sage ich, dass ich kein Pascal schreibe, da mein Quelltext ja meist nicht abwärtskompatibel ist.

Zitat:

Zitat von negaH

Ja, das obige. Es enthält sogar 3 solcher Fälle:

Delphi-Quellcode:

 Result := Odd(N) and (N > 2); 
 Result := N mod Candidate <> 0;
 Result := N = 2;

statt

Delphi-Quellcode:

if Odd(N) then
  if N > 2 then Result := True
    else Result := False
  else Result := False;

if N mod Candidate = 0 then
begin
  Result := False;
  Exit;
end;

Das eine ist eine mathematische Sichtweise, Denkweise als Formel. Das andere ist eine rein Algortihmische, ja fast schon Maschinen-denkweise.

OK, das macht klar, was du meinst. Ich behaupte allerdings, dass ich das nicht so extrem gemacht habe in meinem Beispiel. Bei mehreren Result:=true/false-Zuweisungen hintereinander schrecke ich meist auf und denke mir: Das könnte doch auch in einer Zeile mit einer geschickten Bedingung erledigt werden ;).

Zitat:

Zitat von negaH

weil durch diese Anweisungen der aktuelle Programmblock irregulär verlassen oder weitergeführt wird.
Ein Exit zb. springt direkt aus dem aktuellen und hierarisch geschachtelten Programmblock und verlässt die komplette Funktion/Procedure. Exit zerstört also den grafisch hierarischen Source Aufbau, somit den Lesefluß eines anderen Programmieres und finally damit auch die Verständlichkeit.

Genau das bezwecke ich doch. Meinetwegen könnte man das exit ja in rot markieren, wenn es denn so deutlich werden muss, dass hier aus der Funktion ausgestiegen wird ;). Jedoch halte ich Prüfungen nach der Schleife, ob man dann ab hier noch weiterarbeiten soll, sehr unsauber. In C gibt es break 2; beispielweise, damit steigt man aus der jetztigen und der übergeordneten Schleife aus. Sowas gibt es in Delphi meines Wissens nach nicht, wodurch sich exit für mich legitimiert.

Zitat:

Zitat von negaH

Siehst du: ein guter Programmierstil fördert die Verständlichkeit beim Lesen durch Andere.
Anscheinend habe ich da aber vollständig versagt ;) sonst hättest du meine Source auch verstanden und erkannt das der Fall 8 = gerade Zahl garnicht, nein niemals garnicht never, in der while Schleife auftreten kann.

Ja, das habe ich tatsächlich übersehen beziehungsweise unabhängig von deinem Punkt 8.) (war es doch, oder?) gesehen.

Ich sehe, dass man am Algorithmus selbst wohl noch ein bisschen 'was ändern kann, das auch der Performance ganz gut tut. Allerdings könnte sich der Threadersteller ja auch mal hier melden und bescheid sagen, ob er die ganzen Verbesserungen überhaupt benutzt oder ob er an so optimierten Funktionen interessiert ist.

cu

[negaH]

Zitat:

Mit der schwindenen Anzahl an Zeilen erhöht sich die Anzahl selbiger, die auf meinen Bildschirm passen und somit auch meine Effizienz beim Arbeiten . Ich versuche nicht krampfhaft Zeilen zu optimieren, sondern dort, wo es für mich sinnvoll ist.

Siehst du und da haben wir beide komplett gegensätzliche Ansichten.

Du kaufst dir einen 100 Zoll Monitor und quetscht deinen Source so eng wie möglich damit du soviel Source wie möglich auf einen Blick überblicken kannst.
Ich prophezeie dir jetzt das du irgendwan auf so komplexe Probleme stoßen wirst das selbst ein 1000 Zoll Monitor und die Schriftart Arial 6 nicht mehr helfen wird dein komplexes Problem zu überblicken !!
Das Schlimme an dieser Arbeitsweise ist das du eine Spirale damit in Gang gesetzt hast die ins Unendliche wächst und immer weniger effektiv die geforderten Ziele an dich erfüllen lässt.

Richtig wäre es das Problem dialektisch zu betrachten und Stück für Stück auf kleine Probleme zu reduzieren. Je mehr du auf diese Art&Weise das Gesamtproblem zerlegst desto größer und ausführlicher kann der Source für jedes der Teilprobleme werden. Also direkt umgekehrt proportional.

Dh. man baut seinen Source so auf das jedes Modul ein abgeschlossenes Teiulproblem lösst und man somit jedes Teilproblem unabhängig von den anderen separat verstehen und auch testen kann. Dann kombiniert man in einer hierarisch übergeordneten Source alle diese Module um dann das Gesamtproblem zu lösen.

Dies gilt bis hinab zum Aufbau jeder einzelnen Quelltextzeile, also auch die Frage ob das begin auf gleicher Zeile wie if then steht oder ob man versucht hat über die Syntax eines begin end; eine grafische Struktur per Einrückungen in den Source zu bekommen. Die gilt also auch dafür ob man formal Result := Odd(N) and (N > 2) schreibt oder das mit if then Abfragen mechanisch lösst.

Somit benötigt man garnicht mehr den Überblick über alle Source auf einmal. Denn man hat ja Top-Down oder Bottom-Up jedes abgeschlossene Teilstück der Source verstanden, verifiziert und getestet. In dem Moment ist gesichert das die IsPrime() Funktion zb. wirklch korrekt funktioniert und kann so deren Internas vergessen. Es reicht dann einfach IsPrime() in die Lösung des Gesamtproblemes zu integrieren. Quasi "Aus den Augen aus dem Sinn", es interessiert nicht mehr wie IsPrime() intern funktioniert.

Diese Arbeitsweise ist gewichtet hierarisch und benötigt nicht den Zwang alles auf einmal überblicken zu müssen/wollen, und ergo auch nicht den Zwang den Source wenn möglich in eine Zeile zu quetschen. Es ist die Grundlage dafür das man in einem Team arbeiten kann in dem man sich als Einzelner auch nur auf Teilprobleme konzentieren wird.

Und denoch, halte ich dein Argument für irrelevant, denn zähle doch mal die Anzahl an Zeilen deines Sources und meines Sources. Da exitiert kein Unterschied und denoch gibt es gravierende Unterschiede in den Punkten: algorithmische Effizienz, Performance als Program, Struktur im Source, logische Fehlerhaftigkeit.

Programmstil ist die Frage WIE wir programmieren, und da wir das mit unserem Hirn machen, also eine Frage des Denkens. Man kann also eben nicht einen bestimmten Schreibstil in einem Delphi/PASCAL Source lösslösen von der Frage ob derjenige Programmierer in der Lage ist ein Problem gedanklich zu durchdringen.

Trennt man dies so gibt es mehrere Möglichkeiten:

1.) der Programmierer durchdringt ein Problem logisch korekt kann es aber nicht in Source transportieren, weil er einen schlchten Stil hat
2.) der Programmierer hat einen schlechten, unübersichtlichen Stil und kann so ein Problem nicht von unten durchdringen.

Ergo: ein sauberer und gut struktuirerter Source ist gleichmaßen ein Indiz dafür das der Programmierer auch sein Denken logisch strukturieren kann, und finally ein Problemlöser ist.


Nochwas zur Dokumentation der Sourcen per Remarks, etc.pp:

Grundsätzlich widerspricht eine zusätzliche Beschreibung zu einem Source dem Sinn einer höheren Programmiersprache. Der Source sollte absolut selbsterklärend sein. Soweit das ideale Ziel einer idealen Programmiersprache. Aus Erfahrung kann ich aber bestätigen das gute Sources mit deutlich weniger Bemerkungen auskommmen, als schlechte Sourcen.

Es ist also ein Indiz für einen guten Programierstil wenn man mit weniger Remarks auskommt, oder gar mit keinen !
Es gibt kein Indiz dafür das man mit Remarks seinen Programmirstil tatsächlich verbessern würde.

Gruß Hagen

[Hansa]

Gutes Thema. Das ist echt wichtig und wirklich keine Ironie !! :mrgreen: Habe nicht alles gelesen, aber einige Anmerkungen sind wohl erlaubt : als allererstes gilt es die Einrückungen tatsächlich zu machen. 2 Zeichen sind dazu IMHO optimal. Der Borland Style Guide beschreibt eigentlich alles recht gut. Bis auf eine Ausnahme : es wird vorgeschlagen, das begin eines Blocks in eigene Zeile zu setzen (wohlgemerkt in richtiger Einrückungstiefe !). Da bin ich anderer Meinung. Das zum end; irgendwo ein begin hingehört, das ist ja wohl klar. Nur gehört das zu einem if, else, while oder wozu jetzt :?: Ich schreibe deshalb das begin in dieselbe Zeile, in der sie eingeleitet wird. Also in dieselbe, wo der Block beginnt.

Das nächste ist die Bezeichnung der Bezeichner, also Label93 + Co. 8) Dazu gibt es Hilfsmittel, z.B. GExperts. Dort kann man für jeden Typ den Prefix vorschlagen und braucht ihn nur zu ergänzen. Dazu wird man automatisch gezwungen, sofern er hinterlegt ist und kann die richtige Benennung nicht einfach vergessen !

Nächster Punkt : Exit, Break und auch Result. Ohje, goto taucht auch noch auf. :shock: Nur in Ausnahmefällen tatsächlich benutzen ! Es geht auch ohne.

Tja, soweit mein Senf. Allerdings fehlt da noch Inc und Dec. Wenn das bei heutigen Compilern überhaupt einen Vorteil bringt, dann ist es zumindest unleserlicher (i := i+1; ist wohl jedem klar) und wird wohl nur bei Programmen gebraucht, die zu 99,9 % nur am Hauptspeicher rumwerkeln.

[alcaeus]

Zitat:

Zitat von Hansa

als allererstes gilt es die Einrückungen tatsächlich zu machen. 2 Zeichen sind dazu IMHO optimal.

Deiner Meinung nach schon, der Meinung manch anderes Programmierers nicht. Deshalb verwendet man normalerweise auch Tabs und setzt die Tabweite auf einen angenehmen Wert. ;)
IMO ist das ein ziemlich grober Fehler im Styleguide ;)

Greetz
alcaeus

[Hansa]

Alcaeus, es geht darum, überhaupt Einrückungen zu machen ! Schon mal Prozedur gehabt von 500 Zeilen ? Dann muß die Verschachtelungstiefe definitiv geklärt sein, denn sie wird automatisch sehr tief sein. Bei so was kann ich auch kein extra BEGIN in eigener Zeile gebrauchen, sonst sind es schnell 550 Zeilen usw. Deshalb mein einziger Einwand am Styleguide. Kommt eine Verschachtelungstiefe von 10 zustande, dann wäre das bei einer Lochkarten-Tab-Einstellung bereits 80 Einrückungsspaltem sprich 1 Sete weiter rechts gehts weiter. Somit käme mitetlfristig auch der Einsatz eines 1000 Spalten Monitors a la Hagen in Betracht. :lol: Lese mal einen Source, wo die Blöcke mit Tab=4 eingerückt sind : viel zu weit auseinandergezogen. Schlecht zu lesen. Es ist allerdings schwer nachzuvollziehen, wenn keinerlei Einrückungen gemacht werden. Selbst ein Blinder mit Krückstock merkt den Unterschied.

[Elvis]

Oh Mann, Hansa... du bist ja soo ein Held :roll:
Der Vorteil von Tabs ist, dass jeder sie so breit einstellen kann wie er will. Aber das dürfte den Horizont von Mr 500-Zeilen-Methode schon überschritten haben...

[Hansa]

Elvis lebt also immer noch ? Schön. :lol: Rest ist uninteressant und zudem OT.

[negaH]

Hey hey, keep cool Elvis. Du wirst unsachlich und persönlich.

Ich sehe es teils anders als Hansa:

strikt BEGIN auf eigener Zeile, BEGIN ist ein grafischer Anhaltspunkt so wie das IF THEN, WHILE DO, REPEAT usw. Sie gehören alle in eine eigene Zeile. Man liest doch mit den Augen, oder ? Ein BEGIN ist wie ein neuer Absatz in einem Brief. Man entfernt doch auch nicht die Absätze in einem Buch oder ? Und das vorherige IF THEN vor einem BEGIN Block ist doch nur die Überschrift für das neue Kapitel im Buch.

Die Länge oder Breite des Sources an Zeilen darf niemals dazu führen das wir einen Source auf Kosten der Verständlichkeit einschmelzen. Defakto gibt es keine Funktion oder Problem oder Aufgabenstellung die/das nicht kürzbar ist oder zerlegbar in weitere Unterfunktionen. Das gibt es einfach nicht.

Eine 500 zeilen Funktion ist ein ziemliches Monster und ich könnte mich nicht daran errinnern das ich in 15 Jahren Entwicklung so eine rießige Funktion jemals geschrieben habe. Sowas ist garnicht mehr durch einen Menchen überschaubau und durch-denk-bar. Ergo: 500 zeile für eine Funktion ist ein eindeutiges Indiz dafür das der Programmierer einen schlechten Stil hat. Er kann nämlich ein Problem nicht in Teilprobleme zerlegen, und das ist ja wohl die wichtigste Arbeit beim Programmieren.

Tabstops als Einrückungen: Ich hasse sie und ziehe 2 Leerzeichen wirklich vor. Das heist nicht das ich generell was gegen Tabstops hätte, sie wären eine gute Idee. Aber meine Erfahrungen haben mich gelehrt das ein Tabstop-Sourcecode leider sehr sehr oft eben eine Mixtur aus Leerzeichen-Einrückungen und Tabstops ist. Eine Verstellung eines 4 Zeichen Tabstopsources auf 2 Zeichen führte dann immer wieder dazu das denoch 4 Zeichen Leerzeichen Einrückungen im Source waren. Desweiteren verhalten sich Tabstops sehr sehr unterschiedlich je nachdem welchen Editor man benutzt. D.h. die Arbeistweise mit Tabstops hängt enorm auch vom Editor ab.

Wenn das alles wirklich einheitlich wäre, dann wären Tabstops auch eine sinnvolle Sache.
Und ich rede hier jetzt mal ganz allgemein von ganz verschiedenen Sprachen, sei es C, Assembler, Delphi/PASCAL (und Delphi ist immer noch PASCAL auch wenn Marketingstrategen anderer Meinung sind). Denn Einrückungen sind quasi fast in jeder Hochsprache ein grundlegendes Mittel zu besseren Strukturierung eines Sources.
Man wird mit den Einrückungen beim Delphi wesentlich weniger Probleme heutzutage haben also zb. beim einem WinWVR C Source Code. Und das liegt eben daran das Delphi Sourcen im Delphi-Editor geschrieben werden und dieser standardmäßig mit Leerzeichen statt Tabstops arbeitet. Ich ärgere mich immer wieder wenn ich einen fremden WinAVR C Source in die Hnde bekomme der Tabstops benutzt. Dort ist es nämlich durchaus üblich die erste Einrückung in einer Funktion mit 3 oder 4 Zeichen zu beginnen und jede weitere Einrück mit 2 oder 4 fortzusetzen. Man hat also je nach TabStop-Programmierer ständig anders formatierte Sourcen.

Gruß Hagen