spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »Sylence«

	Quellcode
1	PushButton button;

Die Variable button hat kein Präfix... welchen nimmst du jetzt? Es ist kein Pointer, keine globale, keine statische, kein primitiver Datentyp, sondern eben eine selbsterstellte Klasse für einen button...
Gut jetzt kann man btnn sagen, aber was machst du mit variablen der Klasse Entity, oder Texture, oder Tile?

Sollten Klassennamen nicht eh für sich sprechen, wie Texture, Tile und PushButton es ja auch tun?

Ja hat nur nichts mit der UN zu tun. Ein unsigned int spricht auch für sich. Genauso wie es ein float tut. Ein pointer auf einen char auch. Aber trotzdem setzt man ein i,f oder sonstwas davor. Nur was setzt du als Präfix für eine Variable vom Typ "Texture" ?

Deswegen widerspricht die UN eben der Objektorientierten Programmierung...

Zitat von »Sylence«

Ja hat nur nichts mit der UN zu tun. Ein unsigned int spricht auch für sich. Genauso wie es ein float tut. Ein pointer auf einen char auch. Aber trotzdem setzt man ein i,f oder sonstwas davor. Nur was setzt du als Präfix für eine Variable vom Typ "Texture" ?

Deswegen widerspricht die UN eben der Objektorientierten Programmierung...

Stimmt hat nichts damit zu tun, bin noch müde oO
Aber: Nur weil ich für jede Klasse laut der UN auch einen Präfix brauche, welchen ich aber entweder nur sehr umständlich hinzufügen kann (btnnn) oder aber auf Grund der Menge an Klassen nicht für alle einen Präfix entwickeln will, spricht es gegen die Objektorientierung? Für mich sind das zwei komplett verschiedene Dinge und haben miteinander nicht wirklich etwas zu tun. Ich würde maximal sagen, die UN ist nicht für eigene Datentypen vorgesehen oder besser: beide Dinge sind nicht (oder schwer) kompatibel. Das sie der Objektorientierung widerspricht halte ich für die falsche Ausdrucksweise.

Für die meisten Klassen verwende ich eindeutige Namen wenn ich sie an eine Variable binde: Player, Asteroid(s), SpaceShip, Enemy. Oder bei Texturen/Bildern eben: space_ship_image, player_image etc. Wenn man will auch abgekürzt mit "img".
Bei Tiles, na ja, wenn ich mit Tiles arbeite hab ich entweder eins zur Zeit (Tile) oder gleich mehrere in einem kompletten array (Tiles).
Deswegen kommt es in der Regel nicht zu solchen UN Problemen bzw. ich müsste UN nie auf meine Klassen anwenden, da ich sie eindeutig zuordnen kann.
Des Weiteren bin ich gegen Aliase von Datentypen wie UINT8 usw.

Ich bin eine ganze weile mit Variablenpräfixen gefahren und habe es erst als sehr sinnvoll erachtet, damit man sofort sieht, was es für eine variable ist. Mittlerweile aber ist mir aufgefallen, dass Variablen Ohne präfixe und Unterstriche viel lesbarer sind, einfach in unserer Sprache und auch vermutlich in den meisten, wenn nicht sogar allen anderen, haben wir auch keine wenn wir ein buch lesen.
Auch der Mythos, dass man in c++ solche präfixe nutzen soll, empfinde ich mittlerweile als alt und unsinnig. Nachdem ich meine Studienarbeit in C++ komplett ohne präfixe geschrieben habe war es wesentlich besser zu lesen als mein alter code.
Zum thema unterscheidung member/parameter/lokal: namensgebung inkorrekt oder einfach mal funktionen auslagern, kann nur besser werden

Hallo

Zitat von »Architekt«

Stimmt hat nichts damit zu tun, bin noch müde oO
Aber: Nur weil ich für jede Klasse laut der UN auch einen Präfix brauche, welchen ich aber entweder nur sehr umständlich hinzufügen kann (btnnn) oder aber auf Grund der Menge an Klassen nicht für alle einen Präfix entwickeln will, spricht es gegen die Objektorientierung? Für mich sind das zwei komplett verschiedene Dinge und haben miteinander nicht wirklich etwas zu tun. Ich würde maximal sagen, die UN ist nicht für eigene Datentypen vorgesehen oder besser: beide Dinge sind nicht (oder schwer) kompatibel. Das sie der Objektorientierung widerspricht halte ich für die falsche Ausdrucksweise.

Ich glaube, wir meinen das Gleiche. Ich denke, dass man beim Entwerfen von Klassen eben keinen sinnvollen Präfixe mehr finden kann und deswegen UN und Objektorientierte Programmierung inkompatibel sind.
Klar sind es zwei verschiedene Dinge, die sich aber beeinflussen. Mehr wollte ich nicht sagen. Klar kann man das auch mischen, aber dann hat man entweder komplett kryptische Präfixe, die eh keiner kennt udn die man dokumentieren müsste, was diese ja wieder überflüssig macht oder man verwendet die Präfixe nur bei Datentypen, die bereits im Sprachumfang vorhanden sind und dann hat man eine sehr unsaubere, weil nicht stringente Konvention, was ich persönlich Mist finde.

chrische

Bei Objekten nimmt man dann eben kein Präfix und bei anderen Typen macht man es. Ich finde nicht, dass das gegen die Objektorientierung spricht. Bei Namen ohne Präfix weiß man ja sofort, dass es sich um einen komplexeren Typ handelt. Bei Handles macht man ja auch ein h davor und das eigentlich immer, auch wenn man die ungarische Notation nicht benutzt.

Hallo

Was ist z.B mit vector oder Button bei Frameworks? Ein komplexer Typ oder nicht? Sieht man häufig, dass da ein Präfix gemacht wird. Warum denn nun da und bei texture nicht?

chrische

Apps Hungarian ist eine andre Baustelle (deswegen auch meine Frage im ersten Post). Der Gedanke hinter Apps Hungarian ist in einem Präfix den Sinn des Objektes und nicht (!) seinen Typ zu spezifizieren. Im Gegensatz zu Systems Hungarian (dem was man heute gemeinhin unter "Ungarischer Notation" versteht) mag das schon sinnvoll sein. Es stammen übrigens beide Varianten aus dem Hause Microsoft, wobei Ms von Systems Hungarian heutzutage selbst abrät. Letzteres ist iirc aus einer Fehlinterpretation der ursprünglichen Konvention entstanden.

Anyway ich benutze weder das eine noch das andre. Ich seh das wie bereits gesagt so:

Zitat von »dot«

Wenn aus einem Namen und seinem Kontext nicht klar ersichtlich ist was es sein muss dann ist der Name ein schlechter Name und/oder der Kontext ein schlechter Kontext.

In gutem Code mit gut gewählten Bezeichnern sind Semantik und Typ eines Objektes aus seinem Namen und Kontext offensichtlich.

Ich finde die ungarische Notation (einfache von MS) schon als sinnvoll.

Nur wird sie nie richtig was bringen, solange sie nicht Pflicht ist. Weil ansonsten benutzt sie jemand komplett, teilweise, nur Bruchstücke davon. Und es entsteht statt einheitlichem Code, den jeder lesen und durch das Beherrschen auch Zeitersparnis bei Tippen und Verstehen bringt, exponentiell höhere Anzahl von demselben Code, der nur noch in Gruppen, die ihn anwenden, Sinn macht.

Es mag zwar kleinlich klingen aber hier mal ein Beispiel: Wenn man alle Texturen mit Präfix tx schreiben würde. Würde man auch ohne den Namenszusatz Textur wissen, dass es sich um eine Textur handelt. Somit auch das Tippen von längeren Namen sparen. Was bei einem Namen vielleicht nur eine Zeitersparnis von wenigen Millisekunden, bei einem sehr schnellem Tipper, bringen würde. Aber bei über 1000 Namen vielleicht schon einen Vorteil von Minuten bringen würde. Der Satz ist halt nur eine Aussageform, weil ich die Zahlen nur aus der Luft gegriffen habe, um meine Aussage zu abstrahieren.

Wie oben schon erwähnt. Finde ich, dass die ungarische Notation ein guter Ansatz ist, aber ohne konsequente Umsetzung kontraproduktiv.