Was ist toll an size_t?
-
@kingruedi:
HumeSikkins schrieb:
Naja, deinen Programmierstil kann man sowieso nicht ernstnehmen.
Darunter verstehe ich nicht "unüblich" sondern "zu dumm". Da ist es schonmal Stilsache, und dann kann man bestimmte Stile erst gar nicht ernstnehmen
MfG SideWinder
-
Soweit ich das überblickt habe, benutzt Marc++us in seinem Buch auch nicht immer stringent size_t.
-
SideWinder schrieb:
Darunter verstehe ich nicht "unüblich" sondern "zu dumm". Da ist es schonmal Stilsache, und dann kann man bestimmte Stile erst gar nicht ernstnehmen
naja, ungarische Notation kann man ja auch nicht ernst nehmen. Oder ein C vor dem Klassennamen. Oder ein unsigned long int. Macht alles keinen Sinn.
Wobei ein
const unsigned short int twice(const unsigned short int param) { return(param*2); }irgendwie lustig ist.
Ungarische Notation wäre zB nur traurig.Es ist schön wenn du dich konsequent an einen Stil hältst - aber warum schreibst du denn gerne soviel? Und andererseits ist dir size_t wieder zu umständlich zu schreiben...
-
Shade Of Mine schrieb:
Ungarische Notation wäre zB nur traurig.
meinste? ich verwende es zwar auch nicht aber ganz sinnlos ist das nicht. die variablen haben im extremfall dann zwar blöde namen (z.b. rgrgrgszDerName) aber was solls.
-
aber was solls
Soll das der Grund sein, warum sie doch nicht schlecht ist`? :p
-
rófl. was für ne tolle aussage von net.
-
net schrieb:
Shade Of Mine schrieb:
Ungarische Notation wäre zB nur traurig.
meinste?
Jo, mein ich.
Wenn man OO Programmiert, dann macht ungarisch einfach keinen Sinn.
-
Shade Of Mine schrieb:
Wenn man OO Programmiert, dann macht ungarisch einfach keinen Sinn.
Warum wird hier so oft OOP angeführt, wo ihr doch alle von C++ kommt, was eine Multiparadigmensprache ist. Spielen andere Programmierparadigmen auch in C++ nur eine sehr untergeordnete Rolle?
(das soll natürlich keine Verteidigung der ungarischen Notation sein)
-
Shade Of Mine schrieb:
net schrieb:
Shade Of Mine schrieb:
Ungarische Notation wäre zB nur traurig.
meinste?
Jo, mein ich.
Wenn man OO Programmiert, dann macht ungarisch einfach keinen Sinn.das versteh ich nicht. in vielen oo-programmen taucht auch mal ein primitiver datentyp auf. ausserdem kann man den objekten mit 'erweiterter' ungarischer notation ja auch schicke namen geben z.b. man hat autos und fernseher dann könnte man die objekte 'carFerrari' und 'tvSony' nennen. ist doch cool eh?
-
Nein, ist es nicht.
-
Klasseninstanzen sollen einen Namen haben, der ihre Bedeutung im Programm erklärt und nicht erklärt, von was für einem Typ sie sind.
-
Optimizer schrieb:
Klasseninstanzen sollen einen Namen haben, der ihre Bedeutung im Programm erklärt und nicht erklärt, von was für einem Typ sie sind.
tja, da sieht man's mal - ich bin halt nur ein einfacher c-coder und hab' mit oop nicht so viel am hut
-
Aber net hat Recht, was die primitiven Datentypen angeht. Ich sehe keinen
Vorteil darin, mir den Code unübersichtlicher zu machen.Wo ist der Nachteil von:
int iObjectID??
Für eine Zahl muss ich keine Klasse ObjectID entwerfen - das wäre theoretischer
Bullshit. Hier muss die Praxisrelevanz vorgehen. Schließlich enthält C++ ja
auch noch die Standarddatentypen, oder? Und diese sind auch nicht (wie in
anderen Sprachen) als Klassen designt.Und bei primitiven Datentypen macht die ungarische Notation Sinn.
Wer _vernünftige_ Argumente hat, darf mich einen besseren belehren.
Bobby Womack - California Dreamin' hören tu *ggg* - Was kanns schöneres am
Abend geben// Edit: Präfixe für Klassen sind Müll, da stimme ich mit euch überein - man denke
an das "C" aus der MFC... Dadurch meint jeder Anfänger seine Klasse CFoo nennen
zu müssen
// Edit2: auch das m_ macht IMHO Sinn
-
EnERgYzEr schrieb:
Und bei primitiven Datentypen macht die ungarische Notation Sinn.
Begründung?? Komm erstmal du mit vernünftigen Argumenten.
Mir ist es lieber, wenn ich eine Variable sehe und anhand des Namens erkenne, "aha die Variable ist dafür da, das heisst sie enthält den Wert, den ich für des und des brauche." Mich interessiert das NULL, von welchem Typ sie ist.
Dann ist sie halt vom Typ int. Wenn ich die Programmlogik gerade verstehen will, ist mir das egal. Wird schon seinen Grund haben, warum es nicht double ist. Das wichtigste ist erstmal, dass ich weiss wofür diese Variable überhaupt gut ist. Wenn ich mir danach unbedingt einbilde, den Typ wissen zu müssen, dann fahre ich mit der Maus darüber.
-
EnERgYzEr schrieb:
Wo ist der Nachteil von:
int iObjectID??
Der Nachteil ist, dass es nicht wartbar ist. Wenn du den Typ änderst, dann mußt du durch die Änderung auch überall den Namen ändern, was nicht praktikabel ist. Das hat übrigens dazu geführt, dass in einigen Bibliotheken die Namensgebung nicht mehr mit den Typen konsistent ist. Ich glaube, ich hatte da mal ein Beispiel aus den MFC gesehen, wo das so war.
-
// Edit2: auch das m_ macht IMHO Sinn
Begründung? Dass ich hässliche Unterstriche schreiben muss, kann der Vorteil nicht sein, also muss ich fragen, warum du das gut findest.
-
Hier mal der Text aus "How to write unmaintainable code" zu der ungarischen Notation:
Hungarian Notation is the tactical nuclear weapon of source code obfuscation techniques; use it! Due to the sheer volume of source code contaminated by this idiom nothing can kill a maintenance engineer faster than a well planned Hungarian Notation attack. The following tips will help you corrupt the original intent of Hungarian Notation:
* Insist on using "c" for const in C++ and other languages that directly enforce the const-ness of a variable.
* Seek out and use Hungarian warts that have meaning in languages other than your current language. For example insist on the PowerBuilder "l_" and "a_ " {local and argument} scoping prefixes and always use the VB-esque style of having a Hungarian wart for every control type when coding to C++. Try to stay ignorant of the fact that megs of plainly visible MFC source code does not use Hungarian warts for control types.
* Always violate the Hungarian principle that the most commonly used variables should carry the least extra information around with them. Achieve this end through the techniques outlined above and by insisting that each class type have a custom wart prefix. Never allow anyone to remind you that no wart tells you that something is a class. The importance of this rule cannot be overstated: if you fail to adhere to its principles the source code may become flooded with shorter variable names that have a higher vowel/consonant ratio. In the worst case scenario this can lead to a full collapse of obfuscation and the spontaneous reappearance of English Notation in code!
* Flagrantly violate the Hungarian-esque concept that function parameters and other high visibility symbols must be given meaningful names, but that Hungarian type warts all by themselves make excellent temporary variable names.
* Insist on carrying outright orthogonal information in your Hungarian warts. Consider this real world example: "a_crszkvc30LastNameCol". It took a team of maintenance engineers nearly 3 days to figure out that this whopper variable name described a const, reference, function argument that was holding information from a database column of type Varchar[30] named "LastName" which was part of the table's primary key. When properly combined with the principle that "all variables should be public" this technique has the power to render thousands of lines of source code obsolete instantly!
* Use to your advantage the principle that the human brain can only hold 7 pieces of information concurrently. For example code written to the above standard has the following properties:
o a single assignment statement carries 14 pieces of type and name information.
o a single function call that passes three parameters and assigns a result carries 29 pieces of type and name information.
o Seek to improve this excellent, but far too concise, standard. Impress management and coworkers by recommending a 5 letter day of the week prefix to help isolate code written on 'Monam' and 'FriPM'.
o It is easy to overwhelm the short term memory with even a moderately complex nesting structure, especially when the maintenance programmer can't see the start and end of each block on screen simultaneously.und
One followon trick in the Hungarian notation is "change the type of a variable but leave the variable name unchanged". This is almost invariably done in windows apps with the migration from Win16 :- WndProc(HWND hW, WORD wMsg, WORD wParam, LONG lParam) to Win32 WndProc(HWND hW, UINT wMsg, WPARAM wParam, LPARAM lParam) where the w values hint that they are words, but they really refer to longs. The real value of this approach comes clear with the Win64 migration, when the parameters will be 64 bits wide, but the old "w" and "l" prefixes will remain forever.
-
Optimizer schrieb:
Mir ist es lieber, wenn ich eine Variable sehe und anhand des Namens erkenne, "aha die Variable ist dafür da, das heisst sie enthält den Wert, den ich für des und des brauche."
das eine schliesst das andere nicht aus. man schreibt erst den ungarische-notations-schnickschnack und dann die bedeutung in den variablennamen.
Gregor schrieb:
Der Nachteil ist, dass es nicht wartbar ist. Wenn du den Typ änderst, dann mußt du durch die Änderung auch überall den Namen ändern, was nicht praktikabel ist.
das ist unbestreitbar der grösste nachteil
-
lol, ist das der selbe Typ, der empfiehlt, in Java die Arrays möglichst undurchsichtig zu deklarieren??
int[] foo[][], bar, foo2[]; double[] d[];Der ist locker drauf.
-
das eine schliesst das andere nicht aus. man schreibt erst den ungarische-notations-schnickschnack und dann die bedeutung in den variablennamen.
Gut, aber ich hab immer noch nicht begriffen (und du wirst es auch nicht schaffen, mich zu überzeugen :p ), warum das überhaupt relevant sein soll, von welchem Typ die Variable ist. Ich schau mir ein Stück Code an und versuche es, zu verstehen.
Da ist mir des sooooo wurscht, dass das ein std::list<foo*>::const_iterator ist. Da interessiert mich das wesentlich mehr, dass dieser Iterator dazu gedacht istn über meine liste zu iterieren und alle meine foos, die weniger als 3 bars haben (um mal irgendwas schwachsinniges zu erfinden), löscht.