spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Warum widerspricht das dem Gedanken der Objektorientierung?

@Wollnashorn: Pervers, na ja, wie schon gesagt eher Gewohnheit
Und für die Übersicht schon recht hilfreich.

Nöö... Membervariablen fangen mit einem Großbuchstaben an, alle anderen variablen mit einem kleinen. Konstanten werden komplett groß geschrieben und wenn ich mal irgendwo globale Variablen benutzen würde, würden sie gVariable heißen...

Für den rest ist ein aussagekräftiger Name (isActive vs. active zb) und eine vernünftige IDE da...

Zitat von »Wollnashorn«

Hat in C++-Code meiner Meinung nach nichts zu suchen

Was hat denn die Programmiersprache plötzlich mit Variablennamen zu tun?


Aber ich denke in dem Forum sieht man ganz gut, wie jeder seine eigenen Gewohnheiten hat

@crische5:

Warum bricht es die Objektorientierung, statt "name" "m_Name" oder "m_pName" zu schreiben?

Ich finde, dass es anderen, die den Code lesen und verstehen sollen, viel bringt. Einem selbst bringt es nicht viel, da man ja weiß (zumindest wissen sollte ), was man in seinen Variablen speichert.

Ja es ist Geschmackssache, wenn man sich es angewöhnt hat, merkt man den Mehraufwand nicht mehr und macht es praktisch automatisch. Ich mache eigentlich das volle Programm an ungarischer Notation, nur so was wie DWORD *m_pdwX ist mir auch zu dumm.

Nein, macht den Code unlesbar. Eine Konvention über groß/klein-schreibung reicht vollkommen aus.

In Python ist es übrigens vorgesehen "private" Member mit __ (zwei _) zu beginnen, siehe: http://docs.python.org/reference/lexical…-of-identifiers

Zitat von »hanse«

In Python ist es übrigens vorgesehen "private" Member mit __ (zwei _) zu beginnen, siehe: http://docs.python.org/reference/lexical…-of-identifiers

So weit ich das noch weiß, war ursprünglich für Python geplant, dass jeder selbst weiß, was als Privat und was als Public vorgesehen ist.
Mir wurde von dieser Konvention abgeraten, da dies den Zweck der Sprache verfehlen würde, aber ich nutze es auch zum Teil. Ist auch nicht viel Umgewöhnung, wenn man wie ich eh private Member mit einem Unterstrich kennzeichnet

Datentypen im Namen einer Variablen sind Code-Smell. Poll-Antwort: Nein.
Abgespeckt aber durchaus zu gebrauchen, wie eben Notationen für Attribute (aka Member-Variablen) oder in C/C++ eventuell auch Pointer-Typen.

Hallo

Zitat von »Architekt«

Warum widerspricht das dem Gedanken der Objektorientierung?

Weil man eben oft eigene Datentypen entwirft und man sich dann eigene Präfixe ausdenken müsste. Das wird in der Regel aber nicht gemacht, was ich auch sehr verständlich finde, weil die Abkürzungen ja eh keiner kennen würde. Wenn man nun aber nur bestimmte Typen mit einem Präfix versieht, kann man es IMHO auch gleich sein lassen. Ich weiß auch gar nicht, warum es so wichtig sein sollte den Typ zu kennen. Macht man ja im Deutschen auch nicht, dass man in einem Satz vor jedes Wort die Wortart schreibt. Wenn man bedenkt, dass Variablen einen möglichst kleinen Scope haben und man eindeutige Namen vergibt, hat man das Problem nicht und wenn doch, hilft die IDE. Ich sehe absolute gar keinen Grund für UN. Da ich fast ausschließlich mit C# arbeite und die dortigen Konventionen beachte, hat sich das Thema erledigt. Ich benutze nichts. Kein _, kein p_, kein g_. Eine große Ausnahme gibt es allerdings: I vor Interfaces. Das ist eben Konvention.

chrische

Zitat

Weil man eben oft eigene Datentypen entwirft und man sich dann eigene Präfixe ausdenken müsste

Eigene Datentypen? Du meinst Klassen oder Aliase von Datentypen wie unsigned short-> UINT8?
Wenn ich das richtig verstehe, meinst du, man müsste dann dafür auch wieder einen neuen Präfix entwickeln, wie "ui" oder "ui8" (als Beispiel).
Aber das macht es mir immer noch nicht verständlich, warum das gegen die Objektorientierung spricht, bei der Objektorientierung geht es doch hauptsächlich darum, verwandte bzw. zugehörige Daten zusammen zufassen, zu kapseln und um die Wiederverwendbarkeit. Oder gibt es da verschiedene Ansichten?

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?