Was nervt euch so, während der Programmierung oder so allgemein

[himitsu]

Früher gab's in der VCL mal die Custom-Controls ala TCustomEdit, wo nicht gleich alles Published war ... bei FMX dachte man sich wohl, sowas sei Old School und alle wollen immer gleich alles sehn.
Selbst nachträglich die Property nach Public oder Kleiner zurückzuverschieben bringt irgendwie nichts.

[himitsu]

Ich hasse zwanghafte SCOPEDENUMS.

Freiwillig (wenn nötig) mit Namespace/Scope benutzbar ist OK, aber warum muß die VCL/FMX einen immer und überall dazu zwingen?

[jaenicke]

Ich finde das (wie auch z.B. in C#) sehr sinnvoll und füge das bei allen neuen Quelltexten auch hinzu. Die alte Krücke mit den Prefixes spare ich mir dabei dann auch, so dass der Quelltext viel besser lesbar wird.

Bei VCL/FM kommt glaube ich dazu, dass aufgrund der Ähnlichkeit an manchen Stellen die Bezeichner identisch wären, wenn kein Scope angegeben würde.

Und was spricht denn dagegen?
(Außer Schreibfaulheit, aber so etwas lasse ich nicht gelten.)

[Furtbichler]

Mit gut funktionierender Codecompletion gäbe es keine Schreibfaulen.

[jaenicke]

Bei mir funktioniert die z.B. bei XE nur innerhalb von anonymen Methoden nicht und bei untypisierten Parametern wie bei Format (und bei letzterem ist es ja nachvollziehbar).

[himitsu]

Wenn es funktioniert, dann fände ich manchmal/oftmals eine andere Sortierung (erst die passenden Konstanten, dann Property/Funktionen, welche genau diesen Typen liefern und erst dann verschachtelte Dinge, wo in tieferen Ebenen dann der Typ vorkommt) und/oder eine erweiterte Suchfunktion (nicht nur der Wortanfang) nützlich, denn in der Masse an Vorschlägen findet man nicht immer das, was man braucht, vorallem wenn man grade nicht genau weiß wie das heißt, was man grade braucht.

Ansonsten sind die Dinge manchmal enfach häßlich lang.
Mit Scope und auch noch mit Präfix in einem CASE. (ala TCalloutPosition.cpTop)

PS: Wenn der Typ eindeutig ist, was in Delphi meistens der Fall ist, Dank der strikten Typisierung, dann könnte der Compiler auch etwas freundlicher sein und sich den richtigen/passenden Typen raussuchen, anstatt sich nur die letzte gefundene Implementation anzusehn und zu mackern "nee, paßt nich", dann wären an den meisten Stellen garkeine Scopes nötig, außer da, wo kein fester Typ gegeben ist, wie bei Ord, TypeInfo, offenen VAR-Parametern und Co.

[TiGü]

Zitat von himitsu:

Ansonsten sind die Dinge manchmal enfach häßlich lang.
Mit Scope und auch noch mit Präfix in einem CASE. (ala TCalloutPosition.cpTop)

PS: Wenn der Typ eindeutig ist, was in Delphi meistens der Fall ist, Dank der strikten Typisierung, dann könnte der Compiler auch etwas freundlicher sein und sich den richtigen/passenden Typen raussuchen, anstatt sich nur die letzte gefundene Implementation anzusehn und zu mackern "nee, paßt nich", dann wären an den meisten Stellen garkeine Scopes nötig, außer da, wo kein fester Typ gegeben ist, wie bei Ord, TypeInfo, offenen VAR-Parametern und Co.

Es passt zwar nicht ganz, aber:
»Remember, the future maintainer is the person you should be writing code for, not the compiler.« (Nick Hodges)

Jemand der in fünf Jahren dein Programm warten muss, wäre über die "überflüssigen" Informationen erfreut. Klar findet man vieles über Strg+Linksklick, aber das stört den Fluss beim Verstehen eines Quelltextes.

[jaenicke]

Zitat von himitsu:

Ansonsten sind die Dinge manchmal enfach häßlich lang.

Was ist an der Länge schlecht? Man sieht dadurch einfach besser was zu was gehört.

Ich habe auch Enumerationen in nested types, da ist der Bezeichner noch länger, aber auch das halte ich nicht für schlecht. Dafür ist dann der einzelne Typbezeichner kürzer, da klar ist worauf der sich bezieht. Zum Beispiel:

Delphi-Quellcode:

bipLeft
// oder
TButtonImagePosition.bipLeft

Was ist da wohl schneller lesbar, wenn man den Quelltext überfliegt? (bei neuen Werten sinnvollerweise natürlich ohne Prefix, also TButtonImagePosition.Left)

Deshalb finde ich den Zwang dazu eine gute Möglichkeit diejenigen zu disziplinieren, die ansonsten die kürzeren Bezeichner der Lesbarkeit vorziehen...

[Namenloser]

Also mir gefällt diese Schreibweise TFoo.Bar bei Enums sehr gut, denn ich hatte schon öfters Probleme mit Namenskollisionen mit den Präfixen. Mein Delphi kennt das leider noch nicht...

In PHP (schreckliche Sprache, aber darum geht es jetzt nicht) emuliere ich übrigens auch gerne auf diese Weise Enums:

Code:

class MyEnum {
  const A = 0;
  const B = 1;
  const C = 2;
}

$x = MyEnum::A;

[himitsu]

Ich empfinde es eben gerade nicht unbedingt als Lesbaret, wenn "redundanter" Code "sinnlos" den eigentlichen Code vollmüllt.