Logik der Quelltextvervollständigung

[Codehunter]

Hallo!

Nach welcher Logik klemmt die Quelltextvervollständigung (STRG+SHIFT+C) eigentlich die Klassenmethoden in den Implementation-Teil? Ich hab die gern alphabetisch sortiert, sowohl im Interface-Teil als auch unten. Nur bisher konnte ich keine Logik erkennen, anhand derer die IDE neue Klassenmethoden platziert. Die erscheinen augenscheinlich völlig willkürlich. Kann man das irgendwo konfigurieren?

Grüße
Cody

[himitsu]

Im Interface (Typ-Deklaration) werden sie unten angehängt (wenn man erst die Implementation schreibt und es in den Typ einfügen lässt)
und in der Implementation sind sie "theoretisch" alphabetisch sortiert. (ist es da unten aber schon unsortiert, dann wird die erste scheinbar passende Position genommen)


Ich persönlich hätte es unten so sortiert, wie es oben ist.
Und in der Deklaration habe ich es gern logisch sortiert. (nach Funktion)

[Uwe Raabe]

Zitat von himitsu:

Ich persönlich hätte es unten so sortiert, wie es oben ist.

Da könnte der MMX Code Explorer helfen.

Zitat von himitsu:

Und in der Deklaration habe ich es gern logisch sortiert. (nach Funktion)

Das muss dann aber wohl händisch passieren. Allerdings bietet der MMX Code Explorer auch da eine Rearrange Code Funktionalität, die auch den ersten Punkt mit berücksichtigt.

[Codehunter]

Zitat von Uwe Raabe:

Zitat von himitsu:

Ich persönlich hätte es unten so sortiert, wie es oben ist.

Da könnte der MMX Code Explorer helfen.

Ähem jaaaa Wenn denn die Umbrüche im Interface-Teil abschaltbar wären

Zitat von Uwe Raabe:

Das muss dann aber wohl händisch passieren. Allerdings bietet der MMX Code Explorer auch da eine Rearrange Code Funktionalität, die auch den ersten Punkt mit berücksichtigt.

Meinst du Rearrange Members unter Sorting? Das mag bei mir nicht und steigt mit einer Fehlermeldung aus: Cannot sort/rearrange class containing nested types.

[Uwe Raabe]

Zitat von Codehunter:

Cannot sort/rearrange class containing nested types.

Besserer Support für Nested Classes steht noch bei mir auf der ToDo-Liste - leider noch mit einer ganzen Reihe an anderen Dingen.

[himitsu]

Joar, das Erste was ich mache, ist in der IDE die Breite einzustellen (120 bzw. 150 Zeichen mindestens kann eine Codezeile schon lang sein, um noch auf den Bildschirm zu passen).
Delphi selbsr bricht sonst auch sinnlos kurz alles um.

Delphi-Quellcode:

TMyGridComponent = class
private
  ...
protected
  ...
public
  Spaltenverwaltung...

protected
  ...
public
  Filterfunktionen...

protected
  ...
public
  Suchfunktionen...

end;

Wenn es nur ein paar Funktionen sind, dann direkt drin, bei "viel" auch schonmal als Subkomponente.
Ab und an auch eine Leerzeile, zur optischen Trennung und bei internen oder selten verwendeten Funktionen eine $REGION drumrum.

Und dann die Funktionen halt in logischen Gruppen und Reihenfolgen:
Create, Machwas..., Free
Open, Edit..., Close


Tja, wenn so Verwaltungstools der deutschen Sprache mächtig wären und auch syntaktisch alles verstehen und sortieren würden ....

[Codehunter]

Zitat von himitsu:

Joar, das Erste was ich mache, ist in der IDE die Breite einzustellen (120 bzw. 150 Zeichen mindestens kann eine Codezeile schon lang sein, um noch auf den Bildschirm zu passen).
Delphi selbsr bricht sonst auch sinnlos kurz alles um.

Die Diskussion hatte ich mit Kollegen auch schon. Wobei ich eher die klassischen 80 Zeichen bevorzuge. Dadurch ergibt sich die Notwendigkeit von Unterprozeduren von alleine wenn die Verschachtelungstiefe der Indents zu weit nach rechts geht. Das ist aber weitgehend Geschmackssache.

Zitat von himitsu:

Wenn es nur ein paar Funktionen sind, dann direkt drin, bei "viel" auch schonmal als Subkomponente.
Ab und an auch eine Leerzeile, zur optischen Trennung und bei internen oder selten verwendeten Funktionen eine $REGION drumrum.

Und dann die Funktionen halt in logischen Gruppen und Reihenfolgen:
Create, Machwas..., Free
Open, Edit..., Close

Das sehe ich genauso.