Stilfrage: C als Präfix für Klassen
-
Wieso weniger Arbeit. Ein, zwei oder drei Buchstaben mehr Tippen ist keine Arbeit und kostet mich über den Tag aggregiert 3 Minuten (die ich mir aber imho hundertfach einspare, weil ich immer den Typ kenne. Das ist ein ganz persönliches Bedürfnis von mir. Wers nicht hat, ok. Aber ich hab nunmal das starke Verlangen immer auf den ersten Blick zu sehen, ob das Teil ein int ist, oder ein double. Obs ein Zeiger ist oder keiner und sogar, ob die Objekte in einer List oder einer Map gespeicher sind. Aber das ist wie gesagt MEIN BEDÜRFNIS. Wers nicht hat, dan will ich dazu nicht zwingen - allerdings versteh ich nicht, wie man dieses Bedürfnis nicht haben kann ).
Also, ich habe nie etwas gegen Präfixe allgemein gesagt, sondern etwas gegen das C vor Klassen. Und das das C dir den Typ der Klasse sagt finde ich seltsam. Vielleicht kannst du mir das nochmal erläutern.
Da meine Variablen entweder verdammt nah an der Stelle, an der ich sie verwende definiert sind, oder gsammelt in der Klassendefinition, hab ich kein problem im Notfall nachzusehen, welchen Typ die Variable hat.
Und wenn ich will, das Peter zur Arbeit geht, sage ich einfach
peter.geh_zur_arbeit();egal, ob Peter ein Leher, Feuerwehrmann oder sonstirgendetwas ist. Mich interessiert der Typ eines Objekts nicht. Deswegen verspüre ich auch nicht das Bedürfnis ihn zu kennzeichnen. Wenn Peter arbeiten gehen kann, kann er es, wenn nicht dann nicht. Egal, welchen Typs er ist.
Und ein Interface ist bei dir also das selbe wie eine Klasse, ein POD aber nicht. Das ist auch eine interessante Sichtweise. Aberjedem das seine.
Und nochmal Präfixe sind gut, allerdings mag ich keine Cs und die Ungaren erst recht nicht
[edit] Codetags vergessen [/edit]
[ Dieser Beitrag wurde am 28.03.2003 um 15:41 Uhr von Helium editiert. ]
-
Original erstellt von kartoffelsack:
z.B.: Container: Welcher Container verwendet wird ist wichtig, da sie sich anders verhalten.finde ich nicht.
es ist peformance mäßig wichtig den überblick zu behalten um den richtigen algo auszuwählen - aber das findet ja ohne direkte programmierung statt.nachdem ich mich einmal entschlossen habe, Also A mit Container B zu verwenden ist der rest doch egal.
ich mach ein container.push_back(foo); und gut ist.
egal obs jetzt n Stack, List, Vector oder sonstwas ist.wie gesagt, der Typ ist nur zur planungszeit wichtig, aber nicht wichtig um den code zu verstehen:
if(std::find(entries.begin(),entries.end(),Entry(name))==entries.end())die zeile sagt mir, dass entries nach einem bestimmten eintrag durchuscht wird.
ob das jetzt ein vector oder ne list ist - ist doch nicht wichtig um das zu verstehen...z.B.: std::string: Weil das doch eher ein "normaler" Typ ist. Wie in vielen anderen Programmiersprachen.
es gibt aber verschiedene string klassen...
also ich verwende 3 arten von strings:
nocopyString (diese string typ kopiert nie, er besteht deshalb nur aus zeigern)
StaticArray<char,size> (diese string typ ist eigentlich ein statisches array - zB sinnvoll wenn man mit einer C API arbeitet)
std::stringdas sind also 3 unterschiedliche string klassen - fühlen sich aber alle 3 mehr oder weniger gleich an.
z.B.: smart-pointer: Weil hier auch das Verhalten wichtig ist.
ok, ich arbeite nicht viel mit besonderen smart pointern (ich benütze sie eigentlich nur zum implementieren von RAII)
Ich hab also z.B. bei einem Container mit Personen (dem aufmerksamen Leser wird nicht entgehen, dass ich "Personen" sage, obwohl ich von Instanzen der Klasse "CPerson" rede).
und wie stehts mit S_Person? wie sagst du dazu?
1. Was ist in dem Container: Personen. Also: Bestandzeil des Instanzennamens wird "Personen" sein.
vollkommen richtig. zumindest etwas was darauf hinweist, dass personen drin sind.
2. In welchem Container sind die Personen? Hab ich Random-Access, kann ich schnell einfügen, ist das ganze sortiert?
das wäre mir zB egal.
ich sage einfach
Container personen; bzw. personsWenn ich also ne Liste mit Personen hab, wird das ganze deswegen lstPersonen heißen.
ist es eine sorted list? simple oder double linked? oder gar ein ring? ne, warte: ist eine move to front list?
mhm, also soviel sagt mir das nun auch nicht
In Generischem Code, kann ich natürlich kein Präfix verwenden, weil ich die Info nicht hab. Keine Typ-Info kein Präfix.
dh du verwendest prefixe nicht konsequent überall?
ist das nicht verwirrend?
wie stehts mit std::string - das ist ja eine generische klasse.Leider erwartest Du dann aber von dem, der Deinen Code später weiterentwickelt, dass er auch so ne IDE hat.
da kann man dagegen halten, dass du von jemanden erwartest der deinen code weiter entwickelt, dass er deine prefixe auswendig lernt.
ich muss sagen, das Visual Assits Plugin für den VC++ ist jeden Cent wert. aber es geht auch ohne.
jede IDE sollte den typ einer variablen wissen, also muss ich nur kurz den mauszeiger über die variable halten und schon kenn ich den typ.wenn die IDE das nicht kann, dann muss man halt n paar zeilen rauf schauen - dann sieht man ja die definition.
einziges 'problem' sind membervariablen, da muss man auf die *.h datei umschalten, sind also 2 mausclicks, oder zweimal Tab+irgendwas (zweimal, weil man ja wieder zurück will)ich hoffe, dass du jetzt wenigstens einige argumente anerkennst. dass du deinen stil änderst verlangt ja niemand (zumindest ich nicht)
das ist alles aber nur meine persönliche ansicht.
-
nachdem ich mich einmal entschlossen habe, Also A mit Container B zu verwenden ist der rest doch egal.
ich mach ein container.push_back(foo); und gut ist.
egal obs jetzt n Stack, List, Vector oder sonstwas ist.Leider kann man nicht bei allen Containern etwas mittels push_back hinten hinhängen. Und es ist im Programm nicht egal, ob das Teil garantiert sortiert ist, oder nicht.
das sind also 3 unterschiedliche string klassen - fühlen sich aber alle 3 mehr oder weniger gleich an.Das mehr oder weniger ist aber doch genau das Problem. Genau deswegen will ichs unterscheiden können jederzeit. Weil die kleinen Unterschiede hin und wieder zu großen, wenig nachvollziehbaren Fehlern führen können.
nd wie stehts mit S_Person? wie sagst du dazu?und
da kann man dagegen halten, dass du von jemanden erwartest der deinen code weiter entwickelt, dass er deine prefixe auswendig lernt.
Du meinst Struct Person? Keine Ahnung, kommt nicht so oft vor, dass ich POD-Structs so direkt in meinen Code verwebe. Höchstens wenn ich mit ner DLL oder so kommuniziere. Das is dann aber gekapselt. Klar, meine Notation ist auf meinen Code abgestimmt. Auf etwas, was ich nie verwende, brauch ich in der Notation keine Rücksicht zu nehmen. Und wenn ich ein Projekt mit mehreren Leuten zusammen mache, dann einige ich mich halt mit denen auf ne Notation. Die UN seh ich nur als Anregung.
Aber Du verstehst auch immer noch nicht, was für mich der Witz der Notation ist: Das Programm kann man auch verstehen, wenn man die Notation nicht kennt. Die Notation ist ein Teil des Variablennamens der ignoriert werden kann, wenn es einen nicht interessiert. Und wenn man nur kurz in meinen Code schaut, dann braucht man sie auch nicht zu kennen.
Egal, wie mein Objekt heißt, Fahrgäste, oder lstFahrgaeste, einer, der sich nen Überblick verschaffen will sieht "ah ja, in der Zug-Klasse sind die Fahrgäste in nem Container abgespeichert". Wenn man sich aber durch den Code debugt oder wenn man neuen Code schreibt, dann hab ich eine vielleicht wichtige Teilinfo immer gleich an der Stelle wo ich gerade bin - ohne erst wieder zur Deklaration gehen zu müssen. Ich schreib nicht versehentlich std::sort(lstFahrgaeste). Beim Tippen würd ich dran erinnert: "ah, ne Liste, also ist sort ne Memberfunktion".
Durch die Präfixe gehen doch keine Informationen verloren! Deswegen haben sie imho auch keine Nachteile. Man kann ja von mir aus der Meinung sein "ne, den Typ brauch ich nicht zu wissen". Brauch ich nicht, mach ich nicht. Ok. Kein Problem. Aber es schadet doch auch nicht, ihn zu wissen, also warum sollten es ohne Präfixe besser sein?
Und das ist es, wogegen ich mich wehre. Die zusätzliche Information bringt keinen Schaden, aber manchmal Vorteile - dem einen mehr, dem andern weniger.Und ein Interface ist bei dir also das selbe wie eine Klasse, ein POD aber nicht. Das ist auch eine interessante Sichtweise. Aberjedem das seine.
Ein interface verhält sich wie ne Klasse (z.B. kontrollierte Zugriffsfunktionen) ein POD nicht. Das ist imho keine interessante Sichtweise sondern so ist das definiert.
Und nochmal Präfixe sind gut, allerdings mag ich keine Cs und die Ungaren erst recht nicht
Naja, das C is im Grunde wirklich nicht nötig. Ich machs deswegen, weil ich Variablennamen Groß beginne und irgendwie muss sich dieser Name halt vom Klassennamen unterscheiden.
CPerson Person;
Wenn man Variablennamen klein schreibt, dann is das C natürlich überflüssig. Aber es gibt bestimmt auch genug Gurus die gesagt haben, dass es blöd ist, wenn sich Sachen nur durch Groß- und Kleinschreibung unterscheiden.
-
wie stehts mit std::string - das ist ja eine generische klasse.
Nö. Das ist ein typedef.
das ist alles aber nur meine persönliche ansicht.
Wessen sonst. Die Aussage hat ähnlich viel sinn wie ein C vor Klassen.
Ein interface verhält sich wie ne Klasse (z.B. kontrollierte Zugriffsfunktionen) ein POD nicht. Das ist imho keine interessante Sichtweise sondern so ist das definiert.
Eine Klasse und einen POD kann ich instanzieren, ein Interface nicht. Ein POD verhält sich also wie eine Klasse, ein Interface aber nicht.
-
Durch die Präfixe gehen doch keine Informationen verloren! Deswegen haben sie imho auch keine Nachteile. Man kann ja von mir aus der Meinung sein "ne, den Typ brauch ich nicht zu wissen". Brauch ich nicht, mach ich nicht. Ok. Kein Problem. Aber es schadet doch auch nicht, ihn zu wissen, also warum sollten es ohne Präfixe besser sein?
Und das ist es, wogegen ich mich wehre. Die zusätzliche Information bringt keinen Schaden, aber manchmal Vorteile - dem einen mehr, dem andern weniger.*wink*
Weiter oben habe ich einen Nachteil aufgezeigt. Präfixe führen dazu, dass manchmal *mehr* Information vorhanden ist als nötig wäre. Dieses *mehr* an Information macht mich manchmal abhängiger und damit anfälliger gegenüber Änderungen.
-
ok, Du hast recht. Ich bin anfälliger gegenüber Änderungen. Das ist erstmal ein Nachteil.
Hab aber mal bei so ner Diskussion - hier im Forum, aber schon ein bisschen her - mal gesagt - und der Meinung bin ich immer noch - dass ich das auch als Vorteil sehe. Wenn sich was ändert, bin ich gezwungen - außer ich will, dass meine Notation komplett den Bach runtergeht - jede Stelle im Code wo die Ensprechende Variable etc. vorkommt zu ändern. Dabei seh ich mir die Stellen nochmal an und entdecke, dass es vielleicht doch auswirkungen gibt, die ich nicht bedacht hab.
Ist das innerhalb einer Klasse ist es kein extremer Aufwand. Ist eine Änderung am Interface (ich geb jetzt z.B. ein set statt ner list zurück), ist es zwar evtl. viel Aufwand, aber bei so ner Schnittstellenänderung ist das sowieso so und ich kann drauf wetten, dass das irgendwelche Auswirkungen hat, die ich nicht bedacht hab -> Je mehr ich gezwungen bin, mir das genauer anzuschauen, desto sicherer bin ich mir, dass eine Änderung keine unerwünschten Nebeneffekte hat.
Aber ok. Bei Änderungen zieht es einen gewissen Aufwand nach sich. Das ist ein Nachteil. Bei mir in der Praxis hat er sich aber noch nicht extrem ausgewirkt, dass ich mich oder nen anderen dafür verflucht hätte. Da gibts nervigere Sachen beim Programmieren. So oft ändere ich Typen eigentlich auch nicht.
Eine Klasse und einen POD kann ich instanzieren, ein Interface nicht. Ein POD verhält sich also wie eine Klasse, ein Interface aber nicht.
Stimmt nicht. Man kann nicht jede Klasse instanziieren. Eine abstrakte Klasse kann ich nicht instanziieren. Aber dass ne Klasse abstrakt ist, heißt nicht, dass sie ein Interface ist. imho ist ein Interface ein Spezialfall einer Klasse (zumindest in c++: pure virtual, komplett ohne irgendwelche implementierten Member-Funktionen und ohne Attribute). Bei ner Klasse muss ich mir immer Gedanken machen, ob und wie ich sie instanziiere (hat sie nen Standard-Ctor, nen Copy-Ctor?). Bei nem POD nicht. Bei ner Klasse kann ich mich darauf verlassen, dass sie sich nach der Instanziierung in nem gültigen Zustand befindet. Bei nem POD nicht.
-
Ein POD ist auch nur ein Spezialfall einer Klasse. Das fürt doch zu nichts. Ein Interface hat genausoviele Unterschiede zu einer Klasse, wie ein POD auch.
-
He, Marc++us benutzt auch "C-" und Ungarische Notation:
class CVehicle
{
private:
int m_nWheels;
CList<CWheel> m_....
-
jugendsünden, nehm ich an.
-
m_nWheels ist wohl kaum ungarisch. m_ ist auch nur eine Form der Kennzeichnung für Membervariablen, in erster Linie, um Kollisionen mit Funktions- (insbesondere Konstruktor-)parametern und Methoden zu vermeiden, eine Kategorie mit den allseits beliebten führenden oder angehängten Unterstrichen. Und n steht für Number. Denn nWheels sind nicht die Räder, sondern die Anzahl der Räder. Man könnte auch schreiben numberOfWheels oder numWheels oder anzRaeder oder sonstwas, aber n ist kürzer
ungarisch wäre iWheels.
-
Original erstellt von Bashar:
ungarisch wäre iWheels.Die Micosoft-Quelltexte (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvsgen/html/hunganotat.asp) notieren int gewöhnlich mit c, was für 'counter' steht. Das ist Englisch und bedeutet Ladentisch. Jeder int ist bekanntermaßen ein Ladentisch. i steht für 'index', was zufälligerweise auch Englisch ist und Zeigefinger bedeutet.
Allerdings versteht trotzdem jeder unter ungarischer Notation was anderes, wie eine kurze google-Recherche ergeben hat. Ob das daran liegt, dass 'Hungarian Notation' Englisch ist, oder ich den Text auf der Homepage von Microsoft nicht gelesen habe? Man weiß es nicht...
-
Hier schonmal zwei sich widersprechende Artikel zu dem Thema:
http://msdn.microsoft.com/library/en-us/dnw98bk/html/variablenameshungariannotation.asp http://msdn.microsoft.com/library/techart/hunganotat.htmMit dem ersten kann ich sogar leben. Solange nicht der technische Datentyp kodiert ist, sondern das Präfix nur eine Abkürzung für einen sinngebenden Namensbestandteil ist (wie bei number -> n).