Wie lang sind eure Delphi Quellen?

[mquadrat]

:pale:

[Assarbad]

Zitat:

Zitat von himitsu (Beitrag 1083506)

und wenn man dagegen C# mal einrückt, dann sieht das gleich ganz anders aus :tongue:

Danke. Auch wenn ich meine Kritikpunkte zu Delphi habe, den Vergleich von implementation fand ich auch etwas ... nunja :zwinker:

Zitat:

Zitat von himitsu (Beitrag 1083506)

Abgesehn davon, daß ich diese casesensitive Namensbehandlung nicht wirklich als gut leserlich empfinde.

Hier bin ich nun wieder anderer Meinung. Schon weil dort wo Delphi endet (bspw. API-Importe) theoretisch schon die Groß-/Kleinschreibung wichtig sein könnte. Mir rollen sich bspw. jedesmal die Zehennägel auf wenn wiedermal ein Delphianer kunstvoll eine API-Funktion nach Gusto groß oder klein schreibt - also bspw. statt GetModuleHandle einfach mal getModuleHandle und andere Grausamkeiten ...

Wichtig ist die Groß-/Kleinschreibung hier doch nur, weil es sich um Syntax handelt. Ansonsten steht es dir doch frei mit Großbuchstaben herumzuwerfen wie du möchtest :tongue:

[himitsu]

In PHP fand ich das nervig.

Da hat man eine Variable X befüllt und später ruft man eine Variable x ab und wundert sich, warum diese plötzlich leer ist.

[Florian Hämmerle]

Zitat:

Zitat von himitsu (Beitrag 1083555)

In PHP fand ich das nervig.

Da hat man eine Variable X befüllt und später ruft man eine Variable x ab und wundert sich, warum diese plötzlich leer ist.

Naja, aber es gibt ja doch gewisse Styleguides an die sich die meisten (Delphi-)Entwickler halten. oder schreibst du statt begin BeGiN oder BEGIN? reservierte Worte schreibt man meist klein. Deshalb heißt es bei mir auch string, aber Integer

CamelCase oder nicht. Wenn, dann sollte man sich auch durchgehend daran halten... egal ob der Compiler das jetzt verlangt oder nicht

mfg Florian

[mquadrat]

Zitat:

Zitat von Assarbad (Beitrag 1083549)

Zitat:

Zitat von himitsu (Beitrag 1083506)

und wenn man dagegen C# mal einrückt, dann sieht das gleich ganz anders aus :tongue:

Danke. Auch wenn ich meine Kritikpunkte zu Delphi habe, den Vergleich von mquadrat fand ich auch etwas ... nunja :zwinker:

Huch, ich war das doch gar nicht :-) Ich hab nur geschrieben, dass Delphi nicht die kompakteste Sprache ist.

[BUG]

Zitat:

Zitat von Assarbad (Beitrag 1083549)

Zitat:

Zitat von himitsu (Beitrag 1083506)

Abgesehn davon, daß ich diese casesensitive Namensbehandlung nicht wirklich als gut leserlich empfinde.

... also bspw. statt GetModuleHandle einfach mal getModuleHandle und andere Grausamkeiten ...

Es wäre schön wenn man beide Einschränkungen haben könnte:

• keine Bezeichner mit (case-insensitiv) gleichem Namen
• keine (case-sensitiv) falsch geschriebenen Bezeichner

Habe ich bis jetzt aber in keiner Sprache gesehen.

[Assarbad]

Zitat:

Zitat von mquadrat (Beitrag 1083559)

Huch, ich war das doch gar nicht :-) Ich hab nur geschrieben, dass Delphi nicht die kompakteste Sprache ist.

Danke. Ist behoben (siehe oben).

Zitat:

Zitat von BUG (Beitrag 1083565)

Es wäre schön wenn man beide Einschränkungen haben könnte:

• keine Bezeichner mit (case-insensitiv) gleichem Namen
• keine (case-sensitiv) falsch geschriebenen Bezeichner

Habe ich bis jetzt aber in keiner Sprache gesehen.

Hättest du ein sinnvolles Anwendungsbeispiel parat?

[Namenloser]

Zitat:

Zitat von Assarbad (Beitrag 1083583)

Zitat:

Zitat von BUG (Beitrag 1083565)

Es wäre schön wenn man beide Einschränkungen haben könnte:

• keine Bezeichner mit (case-insensitiv) gleichem Namen
• keine (case-sensitiv) falsch geschriebenen Bezeichner

Habe ich bis jetzt aber in keiner Sprache gesehen.

Hättest du ein sinnvolles Anwendungsbeispiel parat?

Wieso ein Anwendungsbeispiel? Das verhindert einfach schwer zu findende (Tipp-)Fehler und sorgt für eine einheitliche Schreibweise. Ich fänd’s auch ein sinnvolles Feature.

[Assarbad]

Zitat:

Zitat von NamenLozer (Beitrag 1083591)

Wieso ein Anwendungsbeispiel? Das verhindert einfach schwer zu findende (Tipp-)Fehler und sorgt für eine einheitliche Schreibweise. Ich fänd’s auch ein sinnvolles Feature.

Dann verstehe ich den Vorschlag, denke ich, noch nicht so ganz.

Es geht dir also darum, daß Symbole die sich nur durch Groß-/Kleinschreibung unterscheiden angeprangert werden? Innerhalb der üblichen Namensraumregeln oder wie?

Also ich persönlich sehe da potentielle Konflikte und würde das wenn schon denn schon als Compiler-Warnungen, aber nicht als Restriktion nehmen.

[Namenloser]

Erlaubt:

Delphi-Quellcode:

var 
  FooBar: integer;
begin
  FooBar := 42;

Nicht erlaubt:

Delphi-Quellcode:

var 
  FooBar: integer;
begin
  fOObAR := 42;

Auch nicht erlaubt:

Delphi-Quellcode:

var 
  foobar: integer;
  Foobar: integer;
begin
  foobar := 42;
  Foobar := 3;

[BUG]

Zitat:

Zitat von Assarbad (Beitrag 1083595)

Es geht dir also darum, daß Symbole die sich nur durch Groß-/Kleinschreibung unterscheiden angeprangert werden? Innerhalb der üblichen Namensraumregeln oder wie?

Nur im entsprechenden Namensraum.

Zitat:

Zitat von Assarbad (Beitrag 1083595)

Also ich persönlich sehe da potentielle Konflikte und würde das wenn schon denn schon als Compiler-Warnungen, aber nicht als Restriktion nehmen.

Warnung wäre ganz gut, zumindest bei bestehenden Sprachen.

Aber theoretische sollte es (abgesehen jetzt von Properties und den entsprechenden privaten Variablen) keine großen Probleme geben. In einer case-sensitiven Sprache foobar und im gleichen Namespace nochmal fooBar zu benutzen sollte der Lesbarkeit eines Programms eh den Rest geben.

[Assarbad]

Zitat:

Zitat von BUG (Beitrag 1083599)

In einer case-sensitiven Sprache foobar und im gleichen Namespace nochmal fooBar zu benutzen sollte der Lesbarkeit eines Programms eh den Rest geben.

Ich mag diese positive Grundeinstellung :mrgreen:

:zwinker:

@NamenLozer: danke für die Klarstellung.

[Hansa]

Zitat:

Zitat von mquadrat (Beitrag 1083260)

Delphi ist nun mal nicht die kompakteste Sprache.

Man muss auch mal beachten, wo was herkommt. Delphi bzw. Pascal wurden entwickelt, um Programmieren zu lernen. D.h.: besser mehr Kommentare, als weniger. 8-) Für C-Sprachen (viel älter !) heisst das aber : Lochkartenplatz einsparen. Wegen eines dämlichen Kommentars noch 5 Lochkarten von Hand in den Rechner füttern? :mrgreen: Ne, dann doch wenigstens 8 Zoll Disketten. :P

[holliesoft]

Zitat:

Zitat von implementation (Beitrag 1083480)

Code:

class Klasse
{
  protected int x;
  public int X
  {
    get { return x; }
    set { x = value; }
  }
}

Na ja, für so Fälle verwendet man ab C# 3.0 eher automatic properties:

Code:

   public int X {get; set;}

[implementation]

Da könnte auch return BerechneSonstwas(x); als Getter stehen, war ja nur als Beispiel.
Dass man es sowohl in Delphi als auch in C# verkürzen kann, ist mir auch klar, ich wollte den Unterschied zeigen mit Getter und Setter.
Das sollte auch keineswegs irgendeine Kritik gegen Delphi sein, ich wollte lediglich die Aussage unterstützen, dass Delphi keine kompakte Sprache ist, wie ihr mir sicher zustimmen werdet :roll:

[Florian Hämmerle]

Zitat:

Zitat von implementation (Beitrag 1083669)

Da könnte auch return BerechneSonstwas(x); als Getter stehen, war ja nur als Beispiel.
Dass man es sowohl in Delphi als auch in C# verkürzen kann, ist mir auch klar, ich wollte den Unterschied zeigen mit Getter und Setter.
Das sollte auch keineswegs irgendeine Kritik gegen Delphi sein, ich wollte lediglich die Aussage unterstützen, dass Delphi keine kompakte Sprache ist, wie ihr mir sicher zustimmen werdet :roll:

Ich denke aus den Zeiten sind wir raus, als man sich noch um jedes Byte Speicherplatz stritt. Und in kompilierter Form sieht das Ganze dann eh viel komprimierter aus ;)

Jetzt kommt es eben darauf an, ob man begin, end oder {, } übersichtlicher findet :)

[implementation]

Zitat:

Zitat von Florian Hämmerle (Beitrag 1083671)

Ich denke aus den Zeiten sind wir raus, als man sich noch um jedes Byte Speicherplatz stritt. Und in kompilierter Form sieht das Ganze dann eh viel komprimierter aus ;)

Jetzt kommt es eben darauf an, ob man begin, end oder {, } übersichtlicher findet :)

Full Ack.

Auch wenn ich selbst weder mit dem einen noch mit dem andern Probleme habe und beides mag.

[Florian Hämmerle]

Zitat:

Zitat von implementation (Beitrag 1083680)

Auch wenn ich selbst weder mit dem einen noch mit dem andern Probleme habe und beides mag.

Ich auch nicht, wobei eben begin - end den Charme von der Delphi-Sprache ausmachen ;)

Eine Unit kann ja so groß sein, wie man mag, zurechtfinden sollte man sich aber auf jeden Fall. Das wird durch die Tools der IDE erleichtert aber auch die können totalen "Mist" nicht schönzaubern.

Florian

[Hansa]

Zitat:

Zitat von BUG (Beitrag 1083599)

In einer case-sensitiven Sprache foobar und im gleichen Namespace nochmal fooBar zu benutzen sollte der Lesbarkeit eines Programms eh den Rest geben.

Ich denke mal, nicht fehlt da. Oder etwa nicht ? :mrgreen: Obwohl. Es könnte ja tatsächlich so sein, dass manche denken, sie müssten Programm-Schreibfehler dazu benutzen, dass das Programm selbst nicht mehr läuft. :shock: Soll da ein Grund eingebaut werden, noch eine Fehlerquelle einzubauen ? :P

[BUG]

Ich verstehe nicht ganz was du meinst.
Ich hatte vorgeschlagen, diese foobar-fooBar-Situation (in einer case-sensitiven Sprache) zu verbieten, da sie einfach eine Fehlerquelle sein kann und normalerweise eh nicht auftreten sollte.

Zitat:

Zitat von Hansa (Beitrag 1083688)

Soll da ein Grund eingebaut werden, noch eine Fehlerquelle einzubauen ? :P

Man würde in einigen Situationen sicher ein paar neue "Fehler" haben, die man aber leicht beheben kann (-> umbenennen).
Dafür würden aber Fehler durch zwei, sich nur durch die Groß-/Kleinschreibung unterscheidende, Bezeichner schnell auffallen, die man sonst ewig suchen könnte.

[David Martens]

Ich wollte mal auf das eigentliche Thema zurück.

Ich habe gerade eine Funktion vor mir, die ist über 2600 Zeilen lang.

Sieht allerdings so aus:

Delphi-Quellcode:

function TFilterZugriff.GetFilterWerte(Filter: TFilterEnum): TStringList;
begin
  case Filter of
    {$REGION 'feFilterABC :'}
    feFilterABC : begin
                    ...
                  end;
    {$ENDREGION}
    {$REGION 'feFilterXYZ :'}
    feFilterXYZ : begin
                    ...
                  end;
    {$ENDREGION}
    ...
  else
    Result := TStringList.Create;
  end;
end;

Ohne Regionen wäre es noch unübersichtlicher.

[Florian Hämmerle]

Zitat:

Zitat von David Martens (Beitrag 1084377)

Ich habe gerade eine Funktion vor mir, die ist über 2600 Zeilen lang.

Nice. Da hat man doch Freude, wenn man etwas umstellen / erweitern muss ;)

Florian

[ele]

Zitat:

Zitat von David Martens (Beitrag 1084377)

Ich wollte mal auf das eigentliche Thema zurück.

Ich habe gerade eine Funktion vor mir, die ist über 2600 Zeilen lang.

Sieht allerdings so aus:

Delphi-Quellcode:

function TFilterZugriff.GetFilterWerte(Filter: TFilterEnum): TStringList;
begin
  case Filter of
    {$REGION 'feFilterABC :'}
    feFilterABC : begin
                    ...
                  end;
    {$ENDREGION}
    {$REGION 'feFilterXYZ :'}
    feFilterXYZ : begin
                    ...
                  end;
    {$ENDREGION}
    ...
  else
    Result := TStringList.Create;
  end;
end;

Ohne Regionen wäre es noch unübersichtlicher.

Ich denke in dem Fall wäre es angebracht den Filter als Klasse zu Modellieren. Alle Filter von einem BasisFilter ableiten, dann könnte manu z.B. direkt Filter.GetFilterWerte() ausführen. Die einzelne Filter könnte man sogar je in einer eigenen Unit unterbringen.

[David Martens]

Das schöne an dem Ansatz ist ja das ich für die Filterwerte einfach :

Delphi-Quellcode:

TStrings := FFilterZugriff.FilterWerte[feFilterXYZ];

eingebe und ich die Werte des gewünschten Filters habe.

Ich unterscheide die einzelnen Filter nur noch nach dem "fe" und nicht nach der Klasse.

[ele]

Ja aber das macht die Methode unglaublich lang und unübersichtlich...

Wenn du das ganze als Klasse hättest, sähe deine Zeile einfach so aus:

Delphi-Quellcode:

MyStrings := Filter.GetFilterWerte();

oder was ich eigentlich besser fände (weil man sonst Gefahr läuft zu vergessen die Stringliste wieder freizugeben):

Delphi-Quellcode:

Filter.GetFilterWerte(MyStrings);

Ist meiner Meinung nach einfacher zu Schreiben, einfacher zu Erweitern und einfacher zu Warten. OOP lohnt sich - vorallem bei grösseren Projekten.

[Hansa]

Zeige mal die 2600 Zeilen, aber als Anhang ! Wetten, dass das innerhalb von 10 Min. übersichtlich wird ?

[EWeiss]

Hab mal nachgemessen 2,05 Zentimeter.

gruss