Was für eine Naming-Convention für Eigenschaften verwenden

tagchen leute

mein erstes posting in die runde wink

mache mir gerade gedanken zum naming von Eigenschaften.

a) m_dLengthEdgeA
b) m_dEdgeALength
c) LengthEdgeA
d) EdgeALength

-> Rect.LengthEdgeA

1: verwendet ihr noch hungarian (system) notation?
2: mir gefällt irgendwie a) bzw c) denn es ist vorangestellt WAS es ist: eine Länge, zudem sind bei intellisense alle Lengths zusammen, falls ich noch eine LengthIrgendwas habe.. bei IrgendwasLength und EdgeLength sind die in der alphabetischen Liste getrennt

Was denkt ihr?

g

Siehe:

Entwurfsrichtlinien zum Entwickeln von Klassenbibliotheken
Richtlinien für Namen (Enthält Richtlinien für die Benennung von Typen und Membern in Klassenbibliotheken.)
* Konventionen für die Groß-/Kleinschreibung (Beschreibt die unterschiedlichen Schreibweisen und wann sie verwendet werden sollten.)

• Allgemeine Benennungskonventionen (Beschreibt allgemeine Regeln für die Auswahl klarer, lesbarer Namen.)

• Namen von Assemblys und DLLs (Beschreibt Konventionen für die Benennung verwalteter Assemblys.)

• Namen von Namespaces (Beschreibt Konventionen für Namespacenamen und Möglichkeiten, Konflikte zwischen Namespaces zu minimieren. )

• Namen von Klassen, Strukturen und Schnittstellen (Beschreibt Konventionen, die befolgt werden sollten, sowie Konventionen, die beim Benennen von Typen nicht befolgt werden sollten.)

• Namen von Typmembern (Beschreibt die empfohlenen Vorgehensweisen bei der Auswahl von Namen für Methoden, Eigenschaften, Felder und Ereignisse.)

• Parameternamen (Beschreibt die empfohlenen Vorgehensweisen bei der Auswahl von sinnvollen Parameternamen.)

• Namen von Ressourcen (Beschreibt die empfohlenen Vorgehensweisen bei der Auswahl von Namen für lokalisierbare Ressourcen.)

Danke für die Links!

Wählen Sie leicht lesbare Bezeichnernamen aus. Beispielsweise ist eine Eigenschaft mit dem Namen HorizontalAlignment im Englischen besser lesbar als AlignmentHorizontal.

hier möcht ich zur Diskussion anregen:

Wie sehen andere das?
Wenn ich noch AlignmentVertical hab ists geordneter und klingt Objekt bezogen, beinahe wie Alignment.Horizontal = true;

Wäre es bei 2 oder mehr Eigenschaften gleichen Typs (im Sinne Simonyi) (Länge oder Anzahl, etc) also besser gleich zu gruppieren und einen struct / class mit allen Alignments und Lengths zu machen?

Object.Alignments.Horizontal
Object.Alignments.Vertical

g

Wenn ich noch AlignmentVertical hab ists geordneter und klingt Objekt bezogen, beinahe wie Alignment.Horizontal = true;

Geordnet vielleicht schon - aber eben nicht wirklich lesbarar 😉

Wäre es bei 2 oder mehr Eigenschaften gleichen Typs (im Sinne Simonyi) (Länge oder Anzahl, etc) also besser gleich zu gruppieren und einen struct / class mit allen Alignments und Lengths zu machen?

Ja - in manchen Fällen macht das durchaus Sinn.
Siehe z.B. Control.Margin.

Zu deinem Rechteck: Warum nicht Width und Height wie in der FCL auch?
"LengthEdgeA" hört sich IMHO doch sehr merkwürdig an...

Hallo,

Wenn ich noch AlignmentVertical hab ists geordneter und klingt Objekt bezogen, beinahe wie Alignment.Horizontal = true;

Wie Du die Dinger in Code anordnest ist ja Deine Sache. Wenn's um Intellisense geht, erleichtert das ja höchstens die Suche, wenn man nicht weiss welchen Member man benötigt. Dafür gibt's die Doku.

Beim Intellisense finde ich es persönlich besser, wenn ich nur "Hor" oder "Ver" tippen muss und bin direkt an Ort und Stelle, als daß ich "Ali" tippe und dann mit Cursortasten oder Maus auswähle.

Grundsätzlich sollte aber die Lesbarkeit im Vordergrund stehen.

Gruß, MarsStein

👍
Danke für die Antworten und Hinweise (VS2010)

hab mich nun für die leserlichere Variante entschieden und mache bei Bedarf eine Klasse mit Eigenschaften (vgl. Control.Margin. ..).