zu der zeit als die mfc gemacht wurde gab es keine namespaces, ms hat sich für ein C entschieden Borland für T
selbst wenn man für compilier entwikelt die keine namespaces können sollte man nicht C benutzen sondern etwas womit man nicht mit der MFC in konflikt kommen kann
Ich würde einen Namensraum verwenden. Das ist auf jedenfall übersichtlicher, als ein Präfix und mann kann sich manchmal mit using namespace arbeit ersparen.
Ich weiß nicht, warum man sich darüber streiten kann..
Ich persönlich benutze den Präfix C_ für Klassen, S_ für Strukturen und (wenn ich sie nutzen würde) U_ für Unions. Man kann noch so weit gehen, Variablen mit V_ und Parameter mit P_ zu unterscheiden. Bin ich allerdings zu faul zu.
Es ist nicht unübersichtlich. Im Gegenteil, ich kann immer genau sagen, was klasse ist und was Struktur/Variable. Zumal sich meine Klassen häufig um die Bearbeitung einer Tabelle drehen, denen eine struct zugrunde liegt. hie hab ich dann den Vorteil, dass ich die zu bearbeitende struct gleich erkenne, die heißt nämlich - mal abgesehen vom präfix - genau wie die Klasse.
cYa
DjR
_________________ Sei froh, dass einige Menschen dümmer sind als Du.Wen würdest Du sonst damit beeindrucken können, wie gut Du bist?
Das Ding links an deinem Lenkrad ist ein BLINKER! Nutze ihn weise..
Ich hoffe du weißt, dass das dass das das sein sollte..
Original erstellt von DocJunioR:
Es ist nicht unübersichtlich. Im Gegenteil, ich kann immer genau sagen, was klasse ist und was Struktur/Variable.
es ist mir egal ob Int jetzt eine Klasse oder eine struct oder sonstwas ist (wobei struct und class in C++ ja nahezu identisch sind)
Ich weiss, dass ich mit
Int i(0);
cout<<i+5;
5 ausgebe, das reicht mir.
die implementationsdetails sind unwichtig.
und das sehe nicht nur ich so, sondern so ziemlich jeder software entwickler den ich kenne.
_________________ A language that doesn't affect the way you think about programming is not worth knowing.
Original erstellt von DocJunioR:
Ich persönlich benutze den Präfix C_ für Klassen, S_ für Strukturen und (wenn ich sie nutzen würde) U_ für Unions. Man kann noch so weit gehen, Variablen mit V_ und Parameter mit P_ zu unterscheiden. Bin ich allerdings zu faul zu.
Es ist nicht unübersichtlich. Im Gegenteil, ich kann immer genau sagen, was klasse ist und was Struktur/Variable.
So ein Zufall!
Ich machs genau anders. Bei mir haben Typen große Namen und Variablen und Funktionen kleine.
Und structs nehm ich nicht, außer mal privaten structs wie Liste::Node. Und union auch nicht.
Und irgendwie weiß ich genau, was eine Klasse/Struktur und was Variable/Funktion ist. Da dann noch die Variablen entweder einbuchstabig sind oder Gegenstände bezeichnen, und die Funktionen Tätigkeiten, kann ich sogar die unterscheiden.
Im privaten Bereich ist das vielleicht so. Aber wenn man in einem etwas größeren Umfang programmiert, muss man sich an einige Konventionen gewöhnen. rein der dokumentation wegen..
Da hab ich doch neulich einen interessanten Kommentar gehört: "Die beste Doku ist mein Source" Zur Übersichtlichkeit gehören (nach meiner Meinung!) auch sprechende Variablen- und Typennamen. Naja, wie gesagt, ich möchte mich nicht mit Dir streiten, shade (hatten wir ja schon oft genug *gg*). Ich mach's wie ich es für angebracht halte und wenn Du sagst, es ist nicht Dein Ding, dann musst du's ja nicht machen ;)
cYa
DjR
_________________ Sei froh, dass einige Menschen dümmer sind als Du.Wen würdest Du sonst damit beeindrucken können, wie gut Du bist?
Das Ding links an deinem Lenkrad ist ein BLINKER! Nutze ihn weise..
Ich hoffe du weißt, dass das dass das das sein sollte..
Original erstellt von DocJunioR:
Da hab ich doch neulich einen interessanten Kommentar gehört: "Die beste Doku ist mein Source" Zur Übersichtlichkeit gehören (nach meiner Meinung!) auch sprechende Variablen- und Typennamen.
genau, und deshalb kein ungarisch!
Zitat:
Naja, wie gesagt, ich möchte mich nicht mit Dir streiten, shade (hatten wir ja schon oft genug *gg*). Ich mach's wie ich es für angebracht halte und wenn Du sagst, es ist nicht Dein Ding, dann musst du's ja nicht machen
mach meinetwegen mit shade ein stillhalteabkommen.
aber solange du in meinem forum meinen nubes sowas ans herz legst, werde ich widersprechen.
@volkard: ich hab niemandem nie nichts nahegelegt
Ich hab gesagt,wie ich es mache. War schon immer dafür, dass jeder seine Meinung äußern sollte und denn muss man sich selbst ein Büld machen.
Sachemal, Shade. programmierst du alleine an den phps? Das kann ich dann noch verstehen. allerdings bei 50 Leuten, die an einem Projekt sitzen, ist das einfach sinnvoll, sich solche Richtlinien einfallen zu lassen.
Stell Dir vor, da ist jemand im Urlaub, das Projekt soll in zwei stunden eine Marke erreicht haben und in der Bibliothek des Urlaubers geht was schief. willst Du dich durch Variablennamen wie "w", "i", "z1, z2" durchkramen müssen?
Ist im Endeffekt auch irrelevant, wie ich das im Einzelnen mache. Wichtig ist meines Erachtens(!), dass man sich gerade bei wichtigen Werten/Objeken/etc. klare Strukturierungen schafft und diese auch knallhart durchzieht. Wenn man sich das Leben durch kurze Erweiterungen erleichtern kann, warum nicht?
Wer ohne sowas klar kommt, der macht's halt nicht. Solange ich den Code nicht warten muss, isses mir eigentlich auch egal ;)
cYa
DjR
_________________ Sei froh, dass einige Menschen dümmer sind als Du.Wen würdest Du sonst damit beeindrucken können, wie gut Du bist?
Das Ding links an deinem Lenkrad ist ein BLINKER! Nutze ihn weise..
Ich hoffe du weißt, dass das dass das das sein sollte..
Original erstellt von DocJunioR:
Sachemal, Shade. programmierst du alleine an den phps? Das kann ich dann noch verstehen. allerdings bei 50 Leuten, die an einem Projekt sitzen, ist das einfach sinnvoll, sich solche Richtlinien einfallen zu lassen.
Stell Dir vor, da ist jemand im Urlaub, das Projekt soll in zwei stunden eine Marke erreicht haben und in der Bibliothek des Urlaubers geht was schief. willst Du dich durch Variablennamen wie "w", "i", "z1, z2" durchkramen müssen?
wir sind 9 programmierer sowie ab und zu kommt n praktikant dazu.
variablennamen sind natürlich sinnvoll, aber Klassen haben kein Prefix:
$mail=new htmlMail();
und nicht
$mail=new C_htmlMail();
die zweite zeile gibt mir keine zusatzinfos.
in C++ genau das selbe:
htmlMail mail;
oder
C_htmlMail mail;
was weißt du über mail mehr? nichts, htmlMail muss ja ne class sein (oder meinetwegen auch ne struct).
sinnvoll ist es dagegen den klassen aussagekräftige namen zu geben.
zB
DB db;
ist nicht sonderlich sinnvoll.
da tendiere ich zu
Database db;
_________________ A language that doesn't affect the way you think about programming is not worth knowing.
Wenn ich mir eine Klasse zur Verwaltung der passenden Datei(en) baue, nenne ich sie grundsätzlich C_Personal. Das hat einfach den Grund, dass ich weiß, worauf die Klasse zugreift. Ich weiß, dass die Klasse hauptsächlich mit der Struktur S_Personal arbeitet. Sämtliche anderen Strukturen, die in der Klasse vorkommen, verändern nicht die Stammdaten der zugehörigen Tabellen. Das erspart mir einfach eine Menge Dokumentationsarbeit.
Das mag dir vielleicht nicht sinnvoll vorkommen, mir jedoch schon und warum sollte ich alles machen wie du? Ich kann meinen Code lesen, und darauf kommt es mir an. Außerdem wird von mir niemand gezwungen, sowas zu machen, es sei denn, er arbeitet an meinem Projekt mit ;)
<Vorschlag>
Was haltet Ihr davon, wenn wir darin übereinkommen, dass es zumindest sinnvoll ist, sich Regeln zu erstellen, nach denen man seine Objekte, etc. programmiert? Selbst wenn man zum Ergebnis kommt, dass man sowas nicht machen muss, hat man sich wenigstens Gedanken gemacht und das ist das Wichtige an der Sache.
</Vorschlag>
[ Dieser Beitrag wurde am 20.03.2003 um 15:03 Uhr von DocJunioR editiert. ]
_________________ Sei froh, dass einige Menschen dümmer sind als Du.Wen würdest Du sonst damit beeindrucken können, wie gut Du bist?
Das Ding links an deinem Lenkrad ist ein BLINKER! Nutze ihn weise..
Ich hoffe du weißt, dass das dass das das sein sollte..
Original erstellt von DocJunioR:
@volkard: ich hab niemandem nie nichts nahegelegt
mal gucken
Zitat:
allerdings bei 50 Leuten, die an einem Projekt sitzen, ist das einfach sinnvoll, sich solche Richtlinien einfallen zu lassen.
ha, erwischt? ist das keine nahelegung?
Zitat:
Stell Dir vor, da ist jemand im Urlaub, das Projekt soll in zwei stunden eine Marke erreicht haben und in der Bibliothek des Urlaubers geht was schief. willst Du dich durch Variablennamen wie "w", "i", "z1, z2" durchkramen müssen?
De begründest deine unsinnigen Klassenpräfixe mit Argumenten, die nix und überhaupt nix mit Klassenpfäfixen zu tun haben. Klar sind Variablen so zu benennen, daß man sich was drunter vorstellen kann.
beachte zum Beispiel mal folgenden Unfug:
Auto a;
Personal chef;
Gut wäre
Person chef, denn der chef ist eine Person.
Nett ist auch vector<Person*> personal.
Aber ne Klasse namens Personal kann es nicht geben.
Und nu, wo das geklärt ist, ist auch klar, daß es keine S_Personal oder C_Personal geben kann. Und selbst wenn, dann niemals beide!!! Niemals! Denn ne Person ist ne Person ist ne Person. Stammdaten? Tabellen? Deine Personen sind nur Interfaces zu ner relationalen Datenbank drunter? Sind es dann Personen?
Original erstellt von DocJunioR:
<Vorschlag>
Was haltet Ihr davon, wenn wir darin übereinkommen, dass es zumindest sinnvoll ist, sich Regeln zu erstellen, nach denen man seine Objekte, etc. programmiert? Selbst wenn man zum Ergebnis kommt, dass man sowas nicht machen muss, hat man sich wenigstens Gedanken gemacht und das ist das Wichtige an der Sache.</Vorschlag>
Nee.
Nicht mit Leuten, die daran denken, sich dann auch erbittert dran zu halten.
Alle Generalisierungen sind nämlich falsch.
Die Hauptregel beim Proggen ist, daß man jede Regel irgendwann und irgendwo verletzen sollte, um zu guten Ergebnissen zu kommen.
Wir könnten höchsten drüber nachdenken, ob es sinnvoll ist, sich manche Sachen anzugewöhnen. Und welche gewohnheiten eher gut und welche eher schlecht sind.
ich fang an mit: void-pointer sind schlecht, klassenpräfixe sind schlecht und #defines sind schlecht.
Ich hau immer ein "C" vor meine Klassennamen, und void-Pointer sind mir scheißegal!
_________________ Riskiere doch mal einen Blick auf www.WebFritzi.de.vu
FROM: doofie (192.255.2.88); TO: WebFritzi (212.128.130.6)
hi, i'm a signature virus. copy me into your signature to help me spread.
Wie gesagt, ich mach's so. wenn ihr mich dafür lynchen wollt, gerne. Zumindest Fritzi kann meinen Code schon auf den ersten Blick lesen ;)
Habt ihr mal in ner größeren firma programmiert? Da sind die Variablennamen sogar nach Datentypen, Nutzung und Länge bezeichnet und meine 'Firma' besteht nicht nur aus 10 Leuten. iwr haben dutzende Projekte am Laufen und überall ist der Code standardisiert. Wenn ihr's nicht einseht, ist das nicht mein Problem *fg*
Es sieht am Anfang umständlich aus, aber wenn man erstmal dazu kommt, code lesen zu müssen, der schon 10 Jahre alt ist, wird man solche Konventionen lieben. Der einzige Grund, warum man sowas überhaupt macht, ist die Wartbarkeit. Wäre dies nicht nötig, würden wir noch regelmäßig jumps/gotos machen.
Ich habe immernoch nie nicht niemandem was nahegelegt. ich sagte nie :"volkard, mach das so!" ich hab nur meine Meinung öffentlich geäußert. Okay, dafür wird man in letzter Zeit unter anderem auch gelyncht, abgesägt und ähnliches, aber egal. Meine Meinung kennt ihr, ich mach's so, wenn ihr nicht, isses mir auch egal. Hauptsache, ihr kommt mit klar ;)
cYa
DjR
_________________ Sei froh, dass einige Menschen dümmer sind als Du.Wen würdest Du sonst damit beeindrucken können, wie gut Du bist?
Das Ding links an deinem Lenkrad ist ein BLINKER! Nutze ihn weise..
Ich hoffe du weißt, dass das dass das das sein sollte..
Da erinnere ich mich doch daran, dass ich mit dir und Shade gestritten habe, ob es Fällen geben könnte in welchen es sinnvoll sein [b|könnte[/b]
C/C++ Code:
0 == i
C/C++ Code:
0 == i
C/C++ Code:
0 == i
statt
C/C++ Code:
i == 0
C/C++ Code:
i == 0
C/C++ Code:
i == 0
zu schreiben. Das wurde aber von dir (und Shade) generell abgelehnt.
Meine persönliche Meinung zum eigentlichen Thema dieses Threads:
Bei uns werden Präfixe verwendet und ich bin oft sogar in meinem eigenen Code froh, dass ich auch nach zwei Jahren noch schnell erkennen kann, worum es sich handelt.
Leute mit besserem Gedächtnis (oder kleineren und kürzeren Projekten) als meinem brauchen so was sicher nicht.
Wie schon bemerkt: Dies ist meine Meinung und kein Evangelium für irgendwelche Programmierer. Ich bin bisher gut damit gefahren und werde auch weiterhin so programmieren, weil ich für mich Vorteile sehe. Wer anders vielleicht sogar besser zurecht kommt, soll es anders machen.
_________________ Viele Leute glauben zu denken, dabei ordnen sie lediglich ihre Vorurteile neu.
(Williams James)
Original erstellt von Kauz01:
Da erinnere ich mich doch daran, dass ich mit dir und Shade gestritten habe, ob es Fällen geben könnte in welchen es sinnvoll sein [b|könnte[/b]
C/C++ Code:
0 == i
C/C++ Code:
0 == i
C/C++ Code:
0 == i
statt
C/C++ Code:
i == 0
C/C++ Code:
i == 0
C/C++ Code:
i == 0
zu schreiben. Das wurde aber von dir (und Shade) generell abgelehnt.
das ist etwas anderes.
es gibt generalisierungen die immer stimmen.
zB:
im Krieg sterben Menschen
und
0==i
gegen
i==0
da ist 0==i semantisch falsch.
denn das heisst ja, wenn 0 gleich i ist
es interessiert mich aber nicht was 0 ist, sondern was i ist.
aber darum geht es jetzt nicht
_________________ A language that doesn't affect the way you think about programming is not worth knowing.
Original erstellt von Kauz01:
Wir haben in einem früheren C-Projekt so programmiert und hatten einen guten Grund dafür. Der ist aber sicher generell ungültig.
OK, du meinst alte Compiler die bei einem if(i=0) nicht warnen? Zugegeben, dass ist n Problem - aber heutzutage irrelevant (zum Glück)
_________________ A language that doesn't affect the way you think about programming is not worth knowing.
Original erstellt von DocJunioR:
Habt ihr mal in ner größeren firma programmiert? Da sind die Variablennamen sogar nach Datentypen, Nutzung und Länge bezeichnet und meine 'Firma' besteht nicht nur aus 10 Leuten.
Das war einmal. Ist als historisch anzusehen.
Zitat:
iwr haben dutzende Projekte am Laufen und überall ist der Code standardisiert.
Stamdardisierung ja. Aber doch nicht mit nutzlosen Buchstaben. Sonst passiert nur, daß man den Zeiger lpachb nennt, statt begin (long pointer to array of character named begin). Der name soll verraten, WELCHE BEDEUTUNG die Variable hat, nicht welchen TYP.
Zitat:
Der einzige Grund, warum man sowas überhaupt macht, ist die Wartbarkeit. Wäre dies nicht nötig, würden wir noch regelmäßig jumps/gotos machen.
Und hier sag ist einfach, daß die Wartbarkeit dadurch nicht erhöht wird. Und mit gotos hat das überhaupt nix zu tun.
Hi, bei der Erfindung von C++ hat man sich ne Menge Mühe gegeben daß eigene Datentypen(Klassen) so gemacht werden können, daß man sie nicht mehr von eingebauten Datentypen unterscheiden kann (Operatoren überladen...verkette Zuweisung von Variablen etc...)...warum sollte man bei der Benneung eines Typs jezt unbedingt sagen.."Vorsicht das is ne Klasse". Ich glaub net daß das im Sinn der Erfinder gewesen wäre. Und sieht noch scheiße aus..ich hasse Prefixe.
also das 50 leute in firma xyz das auch so machen ist kein stichhaltiges argument.
die leute haben nicht die zeit sich mit solchen fragen zu bescheftigen, außerdem gild ja oft "never change a running system" d.h. in der steinzeit der programmierung werden irgend welche regel festgelegt und gelten noch bis heute
zu dem i==0 vs 0==i:
Ich versuche "ziemlich generell" die zu untersuchende variable allein auf eine seute zu stellen.
also
if(i==0)
und vor allem
if(abhebungsbetrag<kontoStand+kreditRahmen)
statt
if(abhebungsbetrag-kontoStand<kreditRahmen)
oder so.
ausnahme ist immer
while(x>=min && x<=max)
das schreib ich lieber als
while(min<=x && x<=max)
denkar wären auch sachen der art
if( f(x) == f(y) )
wobei f ein kleiner ausdruck ist, hier fällt mir nur kein sinnvolles beispiel ein. nur gemeine wie
if(x/10==y/10)//x und y sind int
,was ich gar nicht versuchen mag. nach x aufzulösen.
Der name soll verraten, WELCHE BEDEUTUNG die Variable hat, nicht welchen TYP.
Grundsätzlich mal richtig. In der Praxis bin ich aber ganz froh, wenn ich der Variable ansehe, ob ein (eigentlich nummerischer) Schlüssel an dieser Stelle als long oder als string abgelegt ist.
Wir können jetzt natürlich Diskussionen führen, ob so was generell nicht vorkommen sollte. Mit Generalisierungen ist das aber so eine Sache .
_________________ Viele Leute glauben zu denken, dabei ordnen sie lediglich ihre Vorurteile neu.
(Williams James)
Original erstellt von Kauz01:
Grundsätzlich mal richtig. In der Praxis bin ich aber ganz froh, wenn ich der Variable ansehe, ob ein (eigentlich nummerischer) Schlüssel an dieser Stelle als long oder als string abgelegt ist.
ok, es gibt fälle...
nubes schreiben gerne vor jeden zeiger ein p. vorteil: man sieht den fehler von if(pa==pb) wo ein if(*pa==*pb) gemeint war. mir isses auch schon vorgekommen, daß ich alte C-funktionen las (das sind die verkorksten apparate über mehrere bildschirmseiten), und auf seite 3 nicht mehr wissen konnte, was nu f war.
ob der schlüssel nu numerisch ist, ob da ne zahl oder ein string verwendet werden darf. ich weiß nicht, evtl läßt sich hier mit der recht strengen typprüfung was rausfischen. (wenn man ne mißratene API hat, die einem void* vollschreibt und typprüfung gar nicht andeutungsweise mag, sollte man auch mißratenen code damit bauen, sonst paßts gar nicht.)
aber vor allem: heute, wo funktionen 2 oder 3 und die dicken funktionen 6 zeilen haben oder trivial sind, kann man erwarten, daß die regeln zum guten programmieren sich leicht geändert haben zu damals.
(ich erinnere mich mit schaudern an klassen, die 30 attribute hatten! jo, da hab ich bezeichner mit n am anfang geliebt. kann aber sein, daß es vor allem daran lag, daß ich nicht 30 maximal 6-buchstabige bezeichner auseinanderhalten konnte.)
[/QUOTE]Wir können jetzt natürlich Diskussionen führen, ob so was generell nicht vorkommen sollte. Mit Generalisierungen ist das aber so eine Sache .[/QUOTE]
genau, die sind nämlich alle falsch.
Nachdem wir erst letztens ausführlichst über die Präfixe diskutiert haben, wollt ich nix mehr zu schreiben.
Ich bin wie Volkard der Meinung, dass der Name der Variable die Bedeutung verraten soll. Im Gegensatz zu Volkard bin ich aber durchaus geneigt, neben der Bedeutung auch noch die Zusatzinformationen über den Typ mit in den Namen zu nehmen. Das schadet nicht und wenn es mir nur einmal erspart, das Tippen zu unterbrechen, weil ich erst im Header nachgucken muss, was das für ein Typ ist, bin ich schon glücklich drüber.
Aber warum ich jetzt eigentlich hier Poste:
Zitat:
Da erinnere ich mich doch daran, dass ich mit dir und Shade gestritten habe, ob es Fällen geben könnte in welchen es sinnvoll sein [b|könnte[/b]
0 == i
statt
i == 0
zu schreiben. Das wurde aber von dir (und Shade) generell abgelehnt.
Dass das ein semantischer Unterschied sein sollte ist Quatsch imho. "Gleich" ist eine mathematisch-logisch definiert und da isses egal, wie rum das ist. Dass man bei ner Gleichung die Seiten tauschen kann wisst Ihr alle.
Dabei gibts aber in C/C++ ein imho schlagendes Argument 0 == i zu verwenden:
if( i = 0) //upsala
{
}
Da kommt, wenn ich Glück hab ne Warnung, die nicht zischen X anderen Warnungen untergeht, die mir der Compiler wegen irgendwelchen Bibliotheken, die ich verwende bringt (für die kann ich nix).
if( 0 = i) hingegen macht nen Compilerfehler.
Zitat:
Ich versuche "ziemlich generell" die zu untersuchende variable allein auf eine seute zu stellen.
Versuch ich auch. Nur eben andersrum und wenn eines von beiden const ist, dann kommt das nach links. Einfach aufgrund eines Unschönheit in der Syntax von C.
man könnte auch malern zuhören, die sich darüber streiten, ob man nun pinsel oder kelle, oder rot oder grün, öl oder aquarell verwenden soll :)
Ich seh das so: Der Programmierer ist der Künstler, der Quelldatei seine leinwand.
Wenn man sich nur ein schönes Bild malen will, ist es reichlich wurscht, welche technik man benutzt. Da kann auch kartoffeldruck schon tolle ergebnisse bringen.
Wenn man aber bilder für auftraggeber machen will, die unbedingt gerade kanten in ihrem bild haben wollen, dann muss man wohl oder übel mal ein lineal benutzen.
Hallo,
lustig. Einige von euch tun so, als ob Präfix == Professionell und alles andere gleich Hobby wäre. Dazu noch so gönnerhaft nach dem Motto: "Ach naja, solange man nur Spielzeugprogrammierung macht, ist das alles egal. Wenn ihr dann aber mal groß seit und professionell in einer so tollen Firma programmiert wie ich, dann werdet ihr einsehen, dass mein Weg der einzig logische ist." So argumentieren meine Großeltern auch immer. Wenn ihnen nichts mehr einfällt, kommt einfach ein: "Naja, in deinem Alter kannst du das noch nicht verstehen."
Ihr vergesst dabei aber ein wenig, dass die Sutters, Meyers', Volkards, Martins, Alexandrescus... dieser Welt ebenfalls professionell programmieren. Die Argumente gegen Präfixe kommen also nicht von irgendwelchen Sandkasten-Fetischisten.
Also von mir aus kann jeder programmieren wie er will. Auf dem Kopf stehend, unterm Tisch liegend, mit 17 Seiten Präfix vor jeder Variablen oder ganz ohne Variablen. Nur in dem Moment wo er behauptet, seine Methode wäre die Richtige bevorzuge ich echte Argumente statt Scheinwahrheiten wie "in der professionellen Programmierung macht man das so", "OOP Code ist wiederverwendbar" und "Java ist langsam".
_________________ Remember Sturgeon's Law:
"Ninety percent of everything is crap." and now go visit my Homepage ;-)
Original erstellt von <prokker>:
@DocJunioR ich hab schonmal Code von dir gesehen und ich finde ihn sehr sehr unübersichtlich. Du programmierst auch eher so'n C und C++ mischmasch.
Und ich hab schonmal gesagt, solch Kommentar nur mit Anmeldung. Ich kann Leute nicht ausstehen, die nicht offiziell zu ihrer Meinung stehen!
Dass ich objektorientiertes C programmiere weiß ich. Bin halt ein C-Umsteiger und seh's nicht ein, dinge fallen zu lassen, die gut sind, nur damit ich in einen ISO reingequetscht werden kann.
Im Übrigen bin ich Individualist. Ich mache immer alles so, wie's mir gefällt *fg*
_________________ Sei froh, dass einige Menschen dümmer sind als Du.Wen würdest Du sonst damit beeindrucken können, wie gut Du bist?
Das Ding links an deinem Lenkrad ist ein BLINKER! Nutze ihn weise..
Ich hoffe du weißt, dass das dass das das sein sollte..
Original erstellt von Dimah:
also das 50 leute in firma xyz das auch so machen ist kein stichhaltiges argument.
die leute haben nicht die zeit sich mit solchen fragen zu bescheftigen, außerdem gild ja oft "never change a running system" d.h. in der steinzeit der programmierung werden irgend welche regel festgelegt und gelten noch bis heute
Naja, Steinzeit. Es wird seit letztem Jahr offiziell C programmiert und dementsprechend sind die Richtlinien relativ neu.
So nebenbei: Was vor 15 Jahren sinnvoll war, muss doch jetzt nicht plötzlich sinnlos sein, oder?
Naja, ich habe hier jetzt wenigstens 4 Leute gelesen, die einen Präfix benutzen. Abschließend sag ich nur noch einmal:
Man sollte sich Gedanken über Namenskonventionen machen! Wenn man dann zum Schluß kommt, dass man keine braucht, okay. Man hat sich wenigstens damit beschäftigt.
So, ich werde mich aktiv aus diesem Thread zurückziehen, lediglich mal schauen, was es neues gibt. Ich bin hier, um meine Sicht zu erklären, und nicht, um mich mit euch zu streiten. Das wäre dann nämlich eine sinnlose Sache, die nur Antipathien erzeugt - muss ja net sein ;)
cYa
DjR
_________________ Sei froh, dass einige Menschen dümmer sind als Du.Wen würdest Du sonst damit beeindrucken können, wie gut Du bist?
Das Ding links an deinem Lenkrad ist ein BLINKER! Nutze ihn weise..
Ich hoffe du weißt, dass das dass das das sein sollte..
Man sollte sich Gedanken über Namenskonventionen machen! Wenn man dann zum Schluß kommt, dass man keine braucht, okay.
Wieder so ein eigenartiger Satz. Wer behauptet, dass nicht-Präfix-Nutzer keine Namenskonventionen haben/brauchen? Namen sind ein fundamentaler Bestandteil der Programmierung. Man sollte sehr viel Gehirnschmalz in die Benennung von Objekten und Konzepten stecken. Das gilt für Präfix-Anhänger genauso wie für alle anderen Programmierer auch. Ich habe noch nie ein Projekt ohne Namenskonventionen gesehen, aber schon viele bei denen in eben diesen der Gebrauch von Präfixen missbilligt wurde.
Um es noch mal klar zu sagen. Nur weil man auf den Einsatz von Präfixen verzichtet, heißt das nicht, dass man Humpty-Dumpty-Namen verwendet.
_________________ Remember Sturgeon's Law:
"Ninety percent of everything is crap." and now go visit my Homepage ;-)
muss mich doch nochmal melden.
Oracle hat beispielsweise Konventionen für PL/SQL-Programme eingerichtet. (die Beispiele und von Oracle entwickelten Scripte benutzen dies grundsätzlich)
Hier bekommen Parameter den Präfix p_ und andere variablen v_. Cursors bekommen ein c_
Dies sind übrigens Namenskonventionen. Okay, ich habe mich insofern falsch ausgedrückt, als dass ich natürlich Prafixe meine. Aber weiter sich darüber zu streiten, find ich sinnlos. Es wird eh immer so viele Meinungen geben, wie Programmierer.
cYa
DjR
_________________ Sei froh, dass einige Menschen dümmer sind als Du.Wen würdest Du sonst damit beeindrucken können, wie gut Du bist?
Das Ding links an deinem Lenkrad ist ein BLINKER! Nutze ihn weise..
Ich hoffe du weißt, dass das dass das das sein sollte..
Original erstellt von DocJunioR:
muss mich doch nochmal melden.
Oracle hat beispielsweise Konventionen für PL/SQL-Programme eingerichtet. (die Beispiele und von Oracle entwickelten Scripte benutzen dies grundsätzlich)
Hier bekommen Parameter den Präfix p_ und andere variablen v_. Cursors bekommen ein c_
Wie ich bereits dargelegt habe, ist es ein himmelweiter Unterschied zwischen C und C++, was die eher sinnvollen Konvestionen angeht.
Unter PL/SQL übliche Konventionen sind in keiner Hinsicht Argument für einen Stil in C++. (Ich hab damals in PL/SQL auch keine Präfixe benutzt, sondern wartete nur, bis das Semester um war und ich dieses schlechtdokumentierte Oracle-Zeugs nie mehr verwenden mußte.)
Konventionen von einer Sprache auf die andere zu konvertieren ist echt dumm, es gibt zB Leute die benutzen das C vor Klassen auch bei Java weil sie sichs in c++ angewöhnt haben...in Java gibts ja auch soviel anderes als Klassen aber auch in C++ ist es einfach ein unnötiger Auswuchs am Namen... sagt was ihr wollt , des is einfach sinnlos (und auch keine Frage von Geschmack)
Einige von euch tun so, als ob Präfix == Professionell und alles andere gleich Hobby wäre. Dazu noch so gönnerhaft nach dem Motto: "Ach naja, solange man nur Spielzeugprogrammierung macht, ist das alles egal. Wenn ihr dann aber mal groß seit und professionell in einer so tollen Firma programmiert wie ich, dann werdet ihr einsehen, dass mein Weg der einzig logische ist."
Ich verstehe deine Einschätzung nicht. Ich hatte nicht das Gefühl, als ob sich hier irgendwer als extrem professionell darstellen will. Jeder hat über seine Erfahrungen berichtet. Die meinen sind halt so. Hätte ich einen anderen Programmierstil und würde ich meine Methoden kurz genug programmieren (Gruß an Volkard), dann tendierte die Notwendigkeit von Präfixen und ungarischer Notation gegen Null. Natürlich nur, wenn ich mich auch auf meine Kollegen verlassen kann.
Zitat:
hr vergesst dabei aber ein wenig, dass die Sutters, Meyers', Volkards, Martins, Alexandrescus... dieser Welt ebenfalls professionell programmieren.
Das vergesse ich sicher nicht. Vor dem Wissen Volkards kann ich sicher nicht bestehen. Werde ich auch nie können, da ich mich in meiner Arbeit oft mehr um das kümmern muss, was wir programmieren, als um das wie. Das heißt aber nicht, dass ich keinerlei Erfahrung in der Programmierung habe. Wie gesagt: Diese Erfahrung muss sich nicht mit den Erfahrungen anderer decken. Imho geht es aber etwas zu weit, wenn es schon als überheblich angesehen wird, seine eigene Meinung zu präsentieren.
_________________ Viele Leute glauben zu denken, dabei ordnen sie lediglich ihre Vorurteile neu.
(Williams James)
Ich hatte nicht das Gefühl, als ob sich hier irgendwer als extrem professionell darstellen will.
Na dann kann einer von uns beiden nicht sonderlich gut lesen. Ich lese das aus nahezu jedem Beitrag von DocJunioR heraus. Aber ich habe auch eine Rechtschreibschwäche. Vielleicht ist die Leseschwäche da nicht weit.
Zitat:
Vor dem Wissen Volkards kann ich sicher nicht bestehen. Werde ich auch nie können, da ich mich in meiner Arbeit oft mehr um das kümmern muss, was wir programmieren, als um das wie. Das heißt aber nicht, dass ich keinerlei Erfahrung in der Programmierung habe. Wie gesagt: Diese Erfahrung muss sich nicht mit den Erfahrungen anderer decken. Imho geht es aber etwas zu weit, wenn es schon als überheblich angesehen wird, seine eigene Meinung zu präsentieren.
Scheinbar kann ich nicht nur nicht lesen sondern auch nicht schreiben. Ich habe nicht denjenigen als überheblich angesehen, der seine Meinung kund tut sondern denjenigen als gönnerhaft, der so Großmutterhaft daher redet.
Und btw. Es geht hier überhaupt nicht um Erfahrung. Erfahrung kann schließlich in vielerlei Hinsicht auch hinderlich sein. Nimm einen erfahrenen C Programmierer und versuche ihm ordentliches C++ beizubringen. Da stört die Erfahrung mehr als das sie nützt.
_________________ Remember Sturgeon's Law:
"Ninety percent of everything is crap." and now go visit my Homepage ;-)
Erster Beitrag und gleich *edit*. Find ich geil.
Naja, muss einfach auch mal meinen Senf dazugeben. Wer schonmal professionell in einer Firma gearbeitet hat der weiss, dass man einfach gewisse Namenskonventionen braucht. Dass diese einem nicht immer gefallen, kann da durchaus vorkommen. Nun hat man die Möglichkeit dies zu ändern oder auch nicht. Jedenfalls kann ich aus eigener Erfahrung sagen, dass dies selten Erfolg hat, da wie schon jemand sagte oft die Devise gilt "never change a winning team". Auch wenn "winning team == uralt Programmierung" bedeutet. Persönlich nutze ich so gut wie gar keine Präfixe. Der Name muss aussagen worum es sich handelt bzw. was ES macht, ich will ja nicht wissen wann und wie ES geboren wurde oder auf welche Schule ES ging. Nur in ganz seltenen Fällen nutze ich noch Präfixe, zB bei Zeiger Variablen, also
Code:
p_anzahl_autos
Code:
p_anzahl_autos
Code:
p_anzahl_autos
Hier weiss ich sofort, dass es sich nicht direkt um die Anzahl der Autos handelt, sondern lediglich um einen Zeiger darauf. In C nutze ich noch h_ für Handle, da diese eine Art Objekte darstellen mit eigenem Interface. In C++ sind das ja Klassen und damit unnötig. Das wars dann aber auch schon mit den Präfixen.
Absolut genial finde ich solche Sachen:
Code:
typedef struct {
int xyz32_ein;
int xyz32_paar;
int xyz32_struktur;
int xyz32_variablen;
} XYZ32;
Code:
typedef struct {
int xyz32_ein;
int xyz32_paar;
int xyz32_struktur;
int xyz32_variablen;
} XYZ32;
Code:
typedef struct {
int xyz32_ein;
int xyz32_paar;
int xyz32_struktur;
int xyz32_variablen;
} XYZ32;
No comment!
Das gleiche bei Klassen Membern (m_ *lol*).
Ich will ja hier niemandem zu nahe treten, aber ich hab so das Gefühl, dass manche ihre Quellcodes mit Notepad schreiben. Jede ordentliche IDE bringt doch Features mit, um schnell zu bestimmen welchen Typ eine Variable hat, wo sie definiert ist, wo sie verwendet wird, etc. Da muss ich doch sowas nicht im Variablennamen verschlüsseln. Ich benutze zB MSVC 6.0 mit Visual Assist (supi Tool!), will damit nicht sagen dass es das beste ist wo gibt, bin aber völlig zufrieden damit. Nur ab und zu muss ich feststellen, dass MS einige spezifische Dinge eingebaut hat *verwundernmichdastutehnichtmehr*. So wird hier bei der Erstellung einer neuen Klasse über das Menü das C Präfix berücksichtigt.
Und wenn jetzt einer anfängt zu behaupten er müsse Präfixe verwenden, weil er uU auch mal in einem billigen Editor was nachschauen muss, kann ich nur sagen: VERSORG DIR 'NE ANSTÄNDIGE IDE!
Ich denke es reicht Namen grob mit Hilfe von Gross- und Kleinschreibung zu unterscheiden. So mach ich es zB:
EIN_DEFINE
EINE_REINE_C_STRUKTUR
EineGlobaleVariable
EineFunktion
EineKlasse
eine_lokale_variable
ein_struktur_member
Absolute bzw. globale Sachen also gross oder als Capital, relative bzw. lokale Sachen klein (für Anregungen oder Verbesserungsvorschläge hab ich durchaus ein offenes Ohr).
Letztendlich muss jeder selbst entscheiden, ob und wie er Namenskonventionen benutzt. Nur sollte man sich ab und zu fragen, ob es tatsächlich einen Sinn hat was man. Manchmal ist es besser mit der Zeit zu gehen auch wenn dies vielleicht einige Überwindung kostet.
Nochwas zu dieser i == 0 Geschichte. Semantisch mag beides, also i == 0 und 0 == i korrekt sein, syntaktisch jedoch denke ich sollte man i == 0 immer den Vorzug geben. Nicht umsonst kann ein x86 Prozessor dies
Code:
cmp [i], 0
Code:
cmp [i], 0
Code:
cmp [i], 0
verarbeiten, dies aber nicht
Code:
cmp 0, [i]
Code:
cmp 0, [i]
Code:
cmp 0, [i]
_________________ Lie when your wife is waking. Lie when your belly's aching. Lie when you know she's faking. Lie, sell shoes, and lie.
C-Casts in C++ stinken - basta
modarchive.org
Original erstellt von groovemaster2002:
Nochwas zu dieser i == 0 Geschichte. Semantisch mag beides, also i == 0 und 0 == i korrekt sein, syntaktisch jedoch denke ich sollte man i == 0 immer den Vorzug geben. Nicht umsonst kann ein x86 Prozessor dies
Code:
cmp [i], 0
Code:
cmp [i], 0
Code:
cmp [i], 0
verarbeiten, dies aber nicht
Code:
cmp 0, [i]
Code:
cmp 0, [i]
Code:
cmp 0, [i]
auf c++ ebene ist das aber egal und da rum gehts hier.
Ich glaube ihr seid blos 0 == i weil ihr es als anfänger anders gelernt habt und fast nie ein i = 0 statt i == 0 geschrieben habt.
auf c++ ebene ist das aber egal und da rum gehts hier
Wusste gar nicht, dass wir uns im C++ Forum befinden. Mein Browser zeigt jedenfalls "Rund um die Programmierung" an.
Zitat:
Ich glaube ihr seid blos 0 == i weil ihr es als anfänger anders gelernt habt und fast nie ein i = 0 statt i == 0 geschrieben habt.
Dazu kann ich nur sagen, dass ich seit über 12 Jahren programmiere, Assembler, C und bin jetzt dabei die Mysterien von C++ zu erforschen. Vor 4 Jahren wurde dann aus Hobby der Beruf. Da denk ich kann man nicht mehr von Anfänger sprechen. Und mit der Begründung, die hier schon jemand gebracht hat, dass eine Warnung bei i = 0 im Getümmel von X Warnungen untergeht, der sollte besser mal versuchen ein Programm so zu schreiben, wo weder Fehler noch Warnungen entstehen (JA, das ist doch tatsächlich möglich ). Schliesslich will ich mich nicht um jede Unzulänglichkeit bezüglich Fehlervorbeugung kümmern müssen, da will ich mich voll und ganz auf meinen Compiler verlassen.
_________________ Lie when your wife is waking. Lie when your belly's aching. Lie when you know she's faking. Lie, sell shoes, and lie.
C-Casts in C++ stinken - basta
modarchive.org
Original erstellt von groovemaster2002:
Dazu kann ich nur sagen, dass ich seit über 12 Jahren programmiere, Assembler, C und bin jetzt dabei die Mysterien von C++ zu erforschen. Vor 4 Jahren wurde dann aus Hobby der Beruf. Da denk ich kann man nicht mehr von Anfänger sprechen.
das du jetzt anfänger bist will ich damit nicht sagen, ich meine als du es mal warst
Zitat:
Original erstellt von groovemaster2002:
Und mit der Begründung, die hier schon jemand gebracht hat, dass eine Warnung bei i = 0 im Getümmel von X Warnungen untergeht, der sollte besser mal versuchen ein Programm so zu schreiben, wo weder Fehler noch Warnungen entstehen (JA, das ist doch tatsächlich möglich ). Schliesslich will ich mich nicht um jede Unzulänglichkeit bezüglich Fehlervorbeugung kümmern müssen, da will ich mich voll und ganz auf meinen Compiler verlassen.
jup und auch wenn man fremd header und libs benutzt gibt es z.b. beim msvc ein nettes #pragma
Original erstellt von groovemaster2002:
Ich denke es reicht Namen grob mit Hilfe von Gross- und Kleinschreibung zu unterscheiden.
Das ist in deutschen Texten so üblich, ja. Ist auch extrem praktisch, weil ich dann Texte schön schnell überfliegen kann (die meisten Menschen lesen dann nur die Wörter die mit einem Großbuchstaben beginnen, weil Deutsch im Gegensatz zum Englischen eine eher 'Substantiv-Basierte' Sprache ist), aber genau das sollte man mit Progammcode nicht(!) machen.
Das 'Problem' liegt bei C++, weil dort einige Programmteile nicht lokal interpretierbar sind: 'a b(c);' ist zB in C eine Funktionsdeklaration, in C++ könnte man auch ein Objekt b vom Typ a in Abhängigkeit von c erzeugen wollen. Um dieses globale Wissen zu kompensieren verwendet man eine Notation, die es in C nie gebraucht hat. In C ist die Notwendigkeit eine Notation irgendeiner Art zu verwenden (damit meine ich jetzt nicht, kein sinnbasiertes Namensschema einzuführen) nicht gegeben.
_________________ Zu jedem Problem gibt es eine Lösung, die klar, einfach und falsch ist.
@Dimah
#pragma versuch ich idR zu vermeiden, da nicht alle von jedem Compiler gleich gut unterstützt werden. Habe da zB zwischen MS und Borland schon Unterschiede festgestellt (kann aber auch daran liegen, dass ich nur relativ alte Borland Compiler kenne wie der bei BC5).
@Daniel E.
Zitat:
Um dieses globale Wissen zu kompensieren verwendet man eine Notation, die es in C nie gebraucht hat.
Und wie sieht diese Notation genau aus? Vielleicht könntest du mal ein konkretes Beispiel posten. Da ich mich momentan gerade als C++ Rookie versuche würde mich das schon sehr interessieren.
_________________ Lie when your wife is waking. Lie when your belly's aching. Lie when you know she's faking. Lie, sell shoes, and lie.
C-Casts in C++ stinken - basta
modarchive.org
Original erstellt von groovemaster2002:
@Dimah
#pragma versuch ich idR zu vermeiden, da nicht alle von jedem Compiler gleich gut unterstützt werden. Habe da zB zwischen MS und Borland schon Unterschiede festgestellt (kann aber auch daran liegen, dass ich nur relativ alte Borland Compiler kenne wie der bei BC5).
#pragma wird vom compiler ignoriert wenn er den befehl nicht versteht
dh man packt das #pragma vielleicht in ein paar guards und die sache ist gegessen -> und man erreicht das sinnlose warnungen wegfallen und man trotzdem mit der höchsten warnstufe kompilieren kann (weil die 'sinnlosen' warnungen nur bei deinem code warnen).
gerade bei C/C++ ist das wichtig, da man die fehler zur compileTime erkennen muss.
_________________ A language that doesn't affect the way you think about programming is not worth knowing.
Original erstellt von Dimah:
jup und auch wenn man fremd header und libs benutzt gibt es z.b. beim msvc ein nettes #pragma
#pragma warning( push, 3 )
#include <irgendwas.h>
#pragma warning( push, 4 )
aber die header des msvc selbser werfen lauter warnungen.
dazu kann man deinen trick erweitern mit #pragma includealias(<iostream.h>,<msvc_bugfix/iostream.h> ) und in der <msvc_bugfix/iostream.h> steht dein code mit
#pragma warning( push, 3 )
#include <iostream>
#pragma warning( pop )
Erfahrung kann schließlich in vielerlei Hinsicht auch hinderlich sein. Nimm einen erfahrenen C Programmierer und versuche ihm ordentliches C++ beizubringen. Da stört die Erfahrung mehr als das sie nützt.
Der Satz lässt mich schon den ganzen Tag nicht mehr los. Jetzt muss ich das doch noch kommentieren.
Die Erfahrung ist nicht hinderlich. Das Problem ist, dass man oft zu bequem ist, sich in eine neue Sichtweise einzuarbeiten. Zu faul neu zu lernen. Wenn ein erfahrener C-Programmierer an C++ rangeht und sich auf die Sachen raussucht, die er schon kennt, einfach weil es bequemer scheint, dann findet er seinen Weg nie. Es ist nicht seine Erfahrung, die ihn behindert. Teile seiner Erfahrung können ihm auch in C++ nützlich sein. Behindert wird er, wenn er seine Erfahrung unkritisch auf das neue überträgt, wenn er sich nur auf Gemeinsamkeiten stürzt.
Jetzt mal wieder zurück zum eigentlichen Thema des Threads. Präfixe. Meine Erfahrung aus Projekten mit und ohne Präfixen ist, dass sie mir geholfen haben die Sourcen mit denen ich arbeiten musste leichter und schneller zu verstehen. Im allgemeinen behindert es mich nicht, wenn ich Präfixe benutze. Warum sollte ich sie nicht mehr verwenden?
Sollte aber der (unwahrscheinliche) Fall auftreten, dass ich die Länge von Variablennamen stark beschränken müsste, muss ich eine Entscheidung treffen. Ist es wichtiger einen aussagekräftigen Bezeichner zu haben oder ist es sehr wichtig über Präfixe den Typ zu erkennen. Bei dieser Entscheidung kann mir meine Erfahrung helfen. Wenn ich nie die Erfahrung gemacht habe, dass mir Präfixe was bringen können, werde ich die Vorteile die ich damit haben kann nie erfahren. Sollte ich aber, weil ich positive Erfahrungen mit Präfixen gemacht habe, darauf bestehen, dass diese verwendet werden, und gar nciht darüber nachdenken, dass ich auch Vorteile haben kann, wenn ich sie weglasse, dann bin ich unflexibel und borniert. Es ist nicht die Erfahrung die mich behindert, sondern die Faulheit und die Unfähigkeit über meinen Tellerrand zu gucken.
_________________ Viele Leute glauben zu denken, dabei ordnen sie lediglich ihre Vorurteile neu.
(Williams James)
Ich denke, dass Du recht hast.
Ich hab mir die Präfixe (so mal nebenbei gesagt) erst vor circa einem Jahr angewöhnt, nachdem ich bemerkt habe, dass ich durch alte Programme nicht mehr durchsehen konnte. Dass ich jetzt hier als altmodisch, unflexibel und auch noch überheblich angesehen werde - nun, damit muss ich wohl leben. Naja, wer mich kennt, kennt mich besser
<Selbsbeschreibung>
Ich habe meine Meinung, verteidige sie aber versuche nicht, sie jemandem aufzuzwingen. Ich mache mein eigenes Ding, ob es anderen sinnvoll erscheint, oder nicht. Ändern kann ich sie übrigens auch, aber nur, wenn ich stichhaltige Beweise habe, dass meine Meinung falsch ist, und die gibt es gerade in Stilfragen nicht
</Selbstbeschreibung>
Wenn ihr eure Erfahrungen macht, dann müssen es nicht meine sein. Ich hab übrigens nie gesagt "Volkard, benutze Präfixe!". Wäre blödsinn. Ich bin sie gewohnt und setze sie für mich sinnvoll ein. Volkard meint für sich, dass sie unsinnig sind. Sie würden ihn womöglich irritieren. Gut, das ist auch sein gutes recht. Ich will auch garnicht, dass alle meinen Stil schreiben. Erstens ist ein Programmierstil wie ein Fingerabdruck und zweitens weiß ich, dass ich nicht unbedingt der sauberste Programmierer bin (ich benutze sogar globale Variablen ).
Ich hab übrigens mehrmals versucht, diese Diskussion zu einem vernünftigen Ende zu bringen. Immerhin bin ich inzwischen "überheblich" geworden, weil ich dagegen gehalten habe, als andere Leute meinten, Präfixe wären "generell überflüssig" oder "schwachsinn". Ich sagte, dass das unter Umständen ziemlich sinnvoll sein kann, was aber auch wieder nur der Fall ist, wenn man damit umgehen kann und will. (ohne jemandem zu nahe treten zu wollen, aber ist der überheblich, der zu Kompromissen bereit ist?)
Die Frage, war "Sind Präfixe für Klassen sinnvoll?" Aus meiner Sicht immernoch ja! Wenn ihr mich dafür an den Marterpfahl hängen wollt, bitte. Nur solltet ihr mal drüber nachdenken, ob das nicht eher eine Beschäftigung für ein privates Treffen wäre, anstatt hier im Forum, wo jemand von Deinen Nubes, Volkard, eine (meines Erachtens durchaus berechtigte) Frage stellt und als Antwort Abschweifungen, Beleidigungen, Unfreundlichkeiten und vor lauter Verwirrung überhaupt keine sinnvolle Aussage bekommt.
Das ist nicht gerade das, was ich von einem Forum erwarte. Klar, eine Meinung sollte jeder haben, aber auch andere akzeptieren.
Was ich vergessen habe. Hat schonmal einer eine IDE ála VC++ auf einem Großrechner gesehen? Ich nicht!
Insofern bin ich nicht überholt. Der Trend geht nämlich allmählig wieder dazu über, dass man Mainframes benutzt. Mal abgesehen davon bin ich ein Freund von Papier. ich kann auf einem Monitor nicht lesen. Ich blättere vor, zurück, schreibe mir Notizen an den Rand, mache Eselsohren in wichtige Seiten - habt ihr schonmal versucht, einen Monitor zu knicken?? Klar hat sogar der Bloodshed inzwischen einen Klassenbrowser, aber wusstet ihr, dass Papier eine längere bescheinigte Haltbarkeit hat, als eine Festplatte oder CD? (Erzählt mir nix, ich hab grade ein Projekt am Laufen, in dem es um Langzeitsicherung von Daten geht )
<ironie>Zu dumm nur, dass ein Klassenbrowser nicht ausdruckbar ist.</ironie>
Es schließt mit freundlichem Gruß
DjR
_________________ Sei froh, dass einige Menschen dümmer sind als Du.Wen würdest Du sonst damit beeindrucken können, wie gut Du bist?
Das Ding links an deinem Lenkrad ist ein BLINKER! Nutze ihn weise..
Ich hoffe du weißt, dass das dass das das sein sollte..
Original erstellt von DocJunioR:
wusstet ihr, dass Papier eine längere bescheinigte Haltbarkeit hat, als eine Festplatte oder CD?
Klar. Aber Papier geht kaputt, wenn man damit arbeitet, und hält sich, wenn es in einem Buchregal verstaubt. Elektronisch gespeicherte Daten halten sich um so besser, je mehr man mit ihnen arbeitet, und gehen verloren, wenn man sie lange nicht anfaßt.
1:0 für dich, Bashar
Ich arbeite aber mit Papier. wenn ich damit fertig bin, gibt's eh ne neue druckversion ;)
[ Dieser Beitrag wurde am 24.03.2003 um 17:07 Uhr von DocJunioR editiert. ]
_________________ Sei froh, dass einige Menschen dümmer sind als Du.Wen würdest Du sonst damit beeindrucken können, wie gut Du bist?
Das Ding links an deinem Lenkrad ist ein BLINKER! Nutze ihn weise..
Ich hoffe du weißt, dass das dass das das sein sollte..
@DocJunioR
also langsam ist es einfach nur noch dreißt. Ich habe jetzt mal alle fünf Seiten nach dem Wort "überheblich" durchsucht. Ergebnis: Nur *du* und *Kauz01*
haben dieses Wort benutzt. Dabei hat sonst *niemand* irgendwas von "überheblich" geschrieben.
Zitat:
Dass ich jetzt hier als altmodisch, unflexibel und auch noch überheblich angesehen werde - nun, damit muss ich wohl leben
Wäre nett, wenn du wenigstens die Beiträge lesen und verstehen würdest, bevor du rumjammerst.
So, von mir aus kannst du jetzt mit deiner Selbstbeweihräucherung weitermachen.
_________________ Remember Sturgeon's Law:
"Ninety percent of everything is crap." and now go visit my Homepage ;-)
Original erstellt von DocJunioR:
Insofern bin ich nicht überholt. Der Trend geht nämlich allmählig wieder dazu über, dass man Mainframes benutzt.
Bitte Quelle angeben.
Zitat:
Mal abgesehen davon bin ich ein Freund von Papier. ich kann auf einem Monitor nicht lesen.
Also überholt.
Zitat:
Ich blättere vor, zurück, schreibe mir Notizen an den Rand, mache Eselsohren in wichtige Seiten - habt ihr schonmal versucht, einen Monitor zu knicken??
Andere Werkzeuge, andere Techniken.
a) Mehrer Dateien offen haben, und umschalten.
b) Editor merkt sich pro Datei letze Corsorposition.
c) Copy&Paste verwenden statt Papierschnipsel auszuschneiden und woanders hinzukleben.
d) Lesezeichen benutzen.
e) Volltextsuche benutzen.
Also überholt.
Zitat:
Klar hat sogar der Bloodshed inzwischen einen Klassenbrowser, aber wusstet ihr, dass Papier eine längere bescheinigte Haltbarkeit hat, als eine Festplatte oder CD?
Ja, und? Tontafeln haben noch ne längere.
Die sind sogar noch überholter und für Dich automatisch besser als Papier.
Die Erfahrung ist nicht hinderlich. Das Problem ist, dass man oft zu bequem ist, sich in eine neue Sichtweise einzuarbeiten.
Da bin ich anderer Meinung. Mit der Zeit prägen sich bestimmte Denkstrukturen/Herangehensweisen aus. Wer sein Leben lang Probleme strukturiert gelöst hat, wird immer Schwierigkeiten haben wirklich gut objektorientiert zu denken.
Ich denke nicht, dass all die unzähligen Programmierer die Probleme mit einem Paradigmen-Wechsel haben, nur zu faul, bequem oder unkritisch sind.
Es gibt einfach keine 100%tige flexibilität.
_________________ Remember Sturgeon's Law:
"Ninety percent of everything is crap." and now go visit my Homepage ;-)
Original erstellt von HumeSikkins:
[quote]
Ich denke nicht, dass all die unzähligen Programmierer die Probleme mit einem Paradigmen-Wechsel haben, nur zu faul, bequem oder unkritisch sind.
Es könnte auch daran liegen, dass erfahrene Programmierer nicht alles glauben, was über Objektorientierung gelogen wird.
Es könnte auch daran liegen, dass erfahrene Programmierer nicht alles glauben, was über Objektorientierung gelogen wird.
OO war nur als Beispiel gedacht. Und ich wollte auch nicht sagen, dass OO generell besser ist als andere Techniken. Fakt ist aber, dass es viele C-Experten gibt, die den Wechsel zur OOP niemals wirklich schaffen. Andersherum hört man auch von vielen OOP-Experten, dass sie nicht mehr dazu in der Lage wirklich gute strukturierete Lösungen zu basteln. Einfach, weil ihr Hirn mittlerweile automatisch in anderen Kategorien denkt.
Es geht mir also überhaupt nicht um eine Wertung der konkreten Techniken. Nur darum, dass meiner Meinung nach Erfahrung auch hinderlich sein kann.
_________________ Remember Sturgeon's Law:
"Ninety percent of everything is crap." and now go visit my Homepage ;-)
Original erstellt von HumeSikkins:
@DocJunioR
also langsam ist es einfach nur noch dreißt. Ich habe jetzt mal alle fünf Seiten nach dem Wort "überheblich" durchsucht. Ergebnis: Nur *du* und *Kauz01*
haben dieses Wort benutzt. Dabei hat sonst *niemand* irgendwas von "überheblich" geschrieben.
Zitat:
Original erstellt von HumeSikkins:
[quoteScheinbar kann ich nicht nur nicht lesen sondern auch nicht schreiben. Ich habe nicht denjenigen als überheblich angesehen, der seine Meinung kund tut sondern denjenigen als gönnerhaft, der so Großmutterhaft daher redet.
Sorry, dass ich mir den Schuh angezogen habe, vielleicht passt er mir ja garnicht. Fragt sich noch, wer seine eigenen Beiträge liest..
Deswegen finde ich übrigens Papier schöner - Es ist übersichtlich..
@ Volkard: überholt stand afaik nicht wörtlich in den Beiträgen, kam aber für mich so rüber. Zu den Arbeitstechniken. altmodisch ist nicht gleich überholt. Ich hab mich daran gewöhnt und werde es weiterhin nutzen - sorry . Möglich, dass es für Dich überholt ist, aber es geht genausowenig nach Deiner Nase, wie nach meiner auf dieser Welt! du machst es, wie Du es am besten kannst, Hume macht's wie er's will und ich habe meinen eigenen stil.
BTW: Ich möchte diese Diskussion wieder auf ein sachliches Level zurückführen. Mag sein, dass ich ab einem gewissen Punkt auch nicht mehr besonders freundlich war, aber ich habe von meinen Erfahrungen gesprochen, die hier nach meiner Auffassung einfach als völlig sinnlos und überflüssig hingestellt wurden und das ist ne Sache, mit der ich nunmal ein Problem habe.
Volkard, ich habe höchsten Respekt vor Deinem Wissen, was C++ angeht, aber ich bin nicht der Meinung, dass irgendjemand der Weisheit letzten Schluß findet. Nicht Du, nicht Hume, Kautz und erst recht nicht ich. Es sollte immer mehr als eine Meinung geben, aber diese Diskussion ist nichts mehr als eine Anhäufung von gegenseitigen haltlosen Kritiken. Das Thema ist wohl eher was für nen gemütlichen Abend bei nem Bierchen. Ich wurde hier mehrmals falsch verstanden und genauso geht's mir mit euch. Tja, der digitale Buchstabe hat halt seine Nachteile..
Ich hab ehrlich anderes im Sinn, als mich hier unbeliebt zu machen (Ich werde trotzdem immer meine Meinung zum Besten geen) zumal der Schreibstil nichts mit der Logik hinter dem Programm zu tun hat, die imho eigentlich den wichtigeren Teil des Ganzen ausmacht..
Ich habe meine Meinung gesagt und damit ist es für mich jetzt gut. Für weitere Nachfragen stehe ich immer bereit ;)
Gruß
DjR
_________________ Sei froh, dass einige Menschen dümmer sind als Du.Wen würdest Du sonst damit beeindrucken können, wie gut Du bist?
Das Ding links an deinem Lenkrad ist ein BLINKER! Nutze ihn weise..
Ich hoffe du weißt, dass das dass das das sein sollte..
Da bin ich anderer Meinung. Mit der Zeit prägen sich bestimmte Denkstrukturen/Herangehensweisen aus. Wer sein Leben lang Probleme strukturiert gelöst hat, wird immer Schwierigkeiten haben wirklich gut objektorientiert zu denken.
Mit dieser Argumentation kannst du jedes Lernen vor dem Erlernen der Objektorientierung verbieten oder als schlecht hinstellen.
Ich persönlich musste schon in der Schule Probleme und in Deutsch ganz anders lösen als die in Geschichte, hatte bei Latein eine völlig andere Vorgehensweise als bei Mathematik. Etwas überspitzt ausgedrückt sagst du: Wer Latein gelernt hat ist in den Denkstrukturen so festgefahren, dass er nie vernünftig programmieren wird.
Ich möchte die Sache hier aber nicht auf den Gipfel treiben. Es ist auch so, dass es Anstrengung erfordert, nicht immer wieder in das alte Fahrwasser zurückzugehen. Du hast recht mit der obigen Aussage. Es ist immer schwierig was neues zu lernen. Ich persönlich sähe meine Arbeit und auch mein Leben als sehr langweilig an, wenn ich aufhören würde mich diesen Schwierigkeiten zu stellen.
_________________ Viele Leute glauben zu denken, dabei ordnen sie lediglich ihre Vorurteile neu.
(Williams James)
Original erstellt von DocJunioR:
...zumal der Schreibstil nichts mit der Logik hinter dem Programm zu tun hat, die imho eigentlich den wichtigeren Teil des Ganzen ausmacht.
Zur Logik gibts auch Stil. Der eine mag eher endliche Autonaten, der andere lieber Rekursion und der dritte leiber wiederholte Anläufe. Der eine mag nur flache lokale Variablen und dafür mehr übergeben, der andere mag gerne Attribute.
Und auf jeden Fall ist's da ganz unaufgeräumt. Heut ist die Auswertung zu wpc53 gekommen: http://www.geocities.com/acmesofties/wpc.htm
Von 6 Einsendern haben die Tester drei als falsch erkannt. Der Siegercode ist auch falsch, womit's vier wären. Und daß die anderen beiden korrekt sind, mag ich auch nicht so auf Anhieb glauben, leider kenn ich deren Code nicht.
Hab mal Code von so nem 3D-Shooter gesehen. Glaub' doom war's. War schrecklich. So das zusammenfummeln der Schleifen und Bedingungen und dann wiedermal unmotiviert break oder goto...
Leider finden sich da gar keine Regeln. Und Diskussionen über den Stil größerer Codebrocken finden nicht statt.
edit: alle 6 einsendungen waren falsch.
[ Dieser Beitrag wurde am 25.03.2003 um 12:53 Uhr von volkard editiert. ]
Original erstellt von volkard:
Zur Logik gibts auch Stil. Der eine mag eher endliche Autonaten, der andere lieber Rekursion und der dritte leiber wiederholte Anläufe. Der eine mag nur flache lokale Variablen und dafür mehr übergeben, der andere mag gerne Attribute.
Und auf jeden Fall ist's da ganz unaufgeräumt. Heut ist die Auswertung zu wpc53 gekommen: http://www.geocities.com/acmesofties/wpc.htm
Von 6 Einsendern haben die Tester drei als falsch erkannt. Der Siegercode ist auch falsch, womit's vier wären. Und daß die anderen beiden korrekt sind, mag ich auch nicht so auf Anhieb glauben, leider kenn ich deren Code nicht.
Hab mal Code von so nem 3D-Shooter gesehen. Glaub' doom war's. War schrecklich. So das zusammenfummeln der Schleifen und Bedingungen und dann wiedermal unmotiviert break oder goto...
Leider finden sich da gar keine Regeln. Und Diskussionen über den Stil größerer Codebrocken finden nicht statt.[/QB]
okay, da hast du auch wieder recht.. immerhin hab ich mich mit euch lange genug drum gesstritten, ob Rekursion sinnvoll ist ;)
cYa
DjR
[ Dieser Beitrag wurde am 25.03.2003 um 13:54 Uhr von DocJunioR editiert. ]
_________________ Sei froh, dass einige Menschen dümmer sind als Du.Wen würdest Du sonst damit beeindrucken können, wie gut Du bist?
Das Ding links an deinem Lenkrad ist ein BLINKER! Nutze ihn weise..
Ich hoffe du weißt, dass das dass das das sein sollte..
OK ich verstehe es immernochnicht. Wenn einem die Firma vorschreibt, ein C vor Klassen zu setzen, OK, dann macht man es. Aber wenn man nicht dazu gezwungen ist, verstehe ich es wirklich nicht. Wenn man z.B. die Konvention Typen groß, Variablen/Funktionen klein einhält, hat man weniger arbeit, der Code ist (aus meiner sicht) leichter zu lesen und es ist nicht so dämlich auszusprechen.
Peter ist eine "Zeh"-Person. Das ist doch einfach Mist. Peter ist eine Person ist da doch gleich viel angenehmer.
Allerdings bin ich für ein m_ vor Membern (oder meinet wegen auch ein nachgestelltes _, wie einige es verwenden). Aber vielleicht sollte ich darüber nochmal nachdenken.
Aber was ist die alternative:
C/C++ Code:
set_foo(T foo)
{
this->foo = foo;
}
C/C++ Code:
set_foo(T foo)
{
this->foo = foo;
}
C/C++ Code:
set_foo(T foo)
{
this->foo = foo;
}
Das ist für mich keine Alternative. Ich finde das seiht einfach nicht übersichtlich aus. (Das ist aber eine Frage des Geschmacks.)
C/C++ Code:
set_foo(T foo)
{
Klassenneame::foo = foo;
}
C/C++ Code:
set_foo(T foo)
{
Klassenneame::foo = foo;
}
C/C++ Code:
set_foo(T foo)
{
Klassenneame::foo = foo;
}
Das sieht schon besser aus, bedeutet aber oft viel Tipparbeit. Ein m_ ist praktischer. Ich werd's mal ausprobieren.
_________________ Manual memory management is premature optimization.
Original erstellt von Bashar:
Der Thread sollte in die FAQ des Trollforums. Leute, so funktioniert das! Man stelle eine Frage wie diese und beobachte endloses aufeinander einhacken
Naja, ich bin's langsam gewohnt. Ich stelle eben die richtigen Fragen und hab die richtigen kommentare dazu, dass man auf mich losgeht *rofl*
Naja, ich gebe zu, dass ich mich auch gelegentlich im Ton vergreife.
Ich gelobe jedoch meinerseits Besserung und werde eine Technik namens "Nachfragen" anwenden, um herauszufinden, ob ich etwas vielleicht falsch aufgefasst hab.. dummsinnig reagieren kann ich ja dann immernoch :o)
cYa
DjR
_________________ Sei froh, dass einige Menschen dümmer sind als Du.Wen würdest Du sonst damit beeindrucken können, wie gut Du bist?
Das Ding links an deinem Lenkrad ist ein BLINKER! Nutze ihn weise..
Ich hoffe du weißt, dass das dass das das sein sollte..
*fg* Hallo Röspekt (wer ist hier unregistriert?).. Ich habe die Frage nicht gestellt - ich hab meine Konventionen ja schon.
Trolle sind imho Leute, die dämliche Kommentare ablassen und ziemlich sinnlos Leute angreifen. Ich vertrete nur meine Meinung und das meistens auf sachlicher Ebene, Daniel. glaub nicht, dass man das trollen nennen kann...
_________________ Sei froh, dass einige Menschen dümmer sind als Du.Wen würdest Du sonst damit beeindrucken können, wie gut Du bist?
Das Ding links an deinem Lenkrad ist ein BLINKER! Nutze ihn weise..
Ich hoffe du weißt, dass das dass das das sein sollte..
Original erstellt von Bashar:
Trolle sind in erster Linie Leute, die solche Threads hier (mit Absicht, will ja keinem was unterstellen;)) erstellen.
Ich hab mich nur angekratzt gefühlt und verteidigt. können wir den thread jetzt schließen?
Der Mensch der gefragt hat, hat eh seine Antwort nicht bekommen - mal abgesehen davon hab ich schon 3 Versuche gestartet das ganze hier zu beenden.
Edit: bezugnehmed auf den nachfolgenden Post korrigiere ich obige Aussage ;)
[ Dieser Beitrag wurde am 26.03.2003 um 18:31 Uhr von DocJunioR editiert. ]
_________________ Sei froh, dass einige Menschen dümmer sind als Du.Wen würdest Du sonst damit beeindrucken können, wie gut Du bist?
Das Ding links an deinem Lenkrad ist ein BLINKER! Nutze ihn weise..
Ich hoffe du weißt, dass das dass das das sein sollte..
Die Frage wurde beantwortet. Sie lautete daoch, was spricht gegegen ein C vor Klassenbezeichnungen und was dafür. Es wurden einige "Argument" genannt. Also ist die Frage beantwortet.
_________________ Manual memory management is premature optimization.
OK ich verstehe es immernochnicht. Wenn einem die Firma vorschreibt, ein C vor Klassen zu setzen, OK, dann macht man es. Aber wenn man nicht dazu gezwungen ist, verstehe ich es wirklich nicht. Wenn man z.B. die Konvention Typen groß, Variablen/Funktionen klein einhält, hat man weniger arbeit, der Code ist (aus meiner sicht) leichter zu lesen und es ist nicht so dämlich auszusprechen.
Sind das Deine Argumente?
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 ).
Leichter zu lesen. Das ist wie Du selber schreibst Deine Sicht. Sehr subjektiv.
Das Aussprechen wäre wirklich dämlich. Aber sorry, ich hab noch nie jemanden von ner Klasse "Zeh-Person" reden hören. Ich würd sagen, "Nimm doch die Klasse Person, die ich mal geschrieben hab". Dass die Klasse CPerson heißt, is klar, weil alle meine Klassen mit C anfangen. Oder: "Du kriegst von mir nen Zeiger auf das Haus".
Ich hab in allen Diskussionen noch nie ein echtes Argument gehört, was schlecht an den Präfixen wär. Das mit dem Lesen ist schlimmstenfalls Gewohnheit, das mit dem Aussprechen geht an der Realität vorbei und das mit dem Mehraufwand ist lächerlich. Also: Es spricht nix dagegen also weiß ich nicht, was dagegen spricht, wenns einer macht, wenn ers subjektiv besser findet. Wenns einer subjektiv schlechter findet, braucht ers nicht machen (außer die Firma schreibts vor). Aber beide Meinungen sind doch gleichwertig, weil gleich subjektiv.
Ich mein, es gibt Stilfragen, für die gibst echte stichhaltige Argumente (z.B. dass ne Funktion keinen Zeiger zurückgeben sollte, für den sie selber speicher reserviert hat). Aber es gibt auch Stilfragen, die sind geschmackssache. Und über Geschmack, kann man nicht streiten.
Und übrigens: ich wär ehrlich gesagt mal froh, wenn jemand ein Argument gegen die Präfixe bringen würde, das ich als solches akzeptieren kann. Nur damit ich mal verstehe, warum so viele was gegen sie haben.
Original erstellt von kartoffelsack:
Und übrigens: ich wär ehrlich gesagt mal froh, wenn jemand ein Argument gegen die Präfixe bringen würde, das ich als solches akzeptieren kann. Nur damit ich mal verstehe, warum so viele was gegen sie haben.
Du lässt ja kein Argument gelten
_________________ A language that doesn't affect the way you think about programming is not worth knowing.
Hallo,
ich finde Shade hat schon mehrfach ein wunderbares Argument genannt. Zumindest in der OOP sollte der Typ eines Objekts nicht im Vordergrund stehen. Im Vordergrund steht sein Verhalten. Wenn ich nun den Typ in den Namen kodiere, verschiebe ich damit das Wesentliche. Außerdem verletzte ich damit eine Form der Kapselung. Schließlich lege ich mich auf den *konkreten* Typ eines Objekts fest. Sollte sich dieser Mal ändern (unter Beibehaltung der Schnittstelle), muss ich auf einmal meine Präfixe ändern.
Und mal ne ganz andere Sache.
Wie verwendet man Präfixe im Zusammenhang mit generischem Code?
PS:
Nur um mich mal zu outen: Ich verwende auch sehr häufig das Präfix p für Pointer. Was an dieser komischen Programmiersprache C++ liegt, die mich dazu zwingt mal . und mal -> zu verwenden. Mittlerweile habe ich eine IDE die einen Punkt, falls nötig, automatisch in ein -> umwandelt. Meine ps reduzieren sich seit dem drastisch :)
Aber mir geht es eigentlich auch hauptsächlich um ungarische Notationssachen. Also sowas wie ein C vor einer Klasse oder ein lpcwHaus oder lpcstrHaus.
[ Dieser Beitrag wurde am 27.03.2003 um 12:01 Uhr von HumeSikkins editiert. ]
_________________ Remember Sturgeon's Law:
"Ninety percent of everything is crap." and now go visit my Homepage ;-)
meine IDE sagt mir immer, welchen Typ eine variable hat :p
aber naja.
wie Hume schon sagte: bei OOP ist der Typ doch uninteressant.
Beispiel:
Int32 i32;
Int64 i64;
Int128 i128;
da ist mir doch egal, ob Int32 jetzt ein typedef auf int ist und ob Int128 eine Klasse für große Zahlen ist.
ich mach ein
i128+=3;
und weiss, dass 3 zu der zahl dazugezählt werden.
ausserdem sagt mir der name, dass es eine zahl ist.
wenn man mehr will, dann benütze ich meine IDE dafür ;)
nungut, Hume hat es schon angesprochen:
wie siehts bei generischer Programmierung aus?
OK, std::vector<std::string> kann man
VecOfStr
oder so ähnlich nennen.
ABer was ist bei
smrt_ptr<ThreadPolicy, RefCountPoilcy, OwnerPolicy>
wie sieht das aus?
aber OK. auch da kann man prefixe machen (nur wer die sich dann merkt )
spThrdSveRingRCTkOwnName; (smart pointer with Thread Save, Ref count using Ring, takes owner policies named Name ) (sorry, ich konnte nicht anders)
naja, nun nehmen wir aber mal folgendes:
du änderst 1 policy, oder den typ einer variablen?
ok, das hatten wir schon: einfach ein replace über das file laufen lassen...
_________________ A language that doesn't affect the way you think about programming is not worth knowing.
Hier bin ich aber der Meinung, dass die zusätzliche Information nicht schadet. Sie hindert mich nicht, objektorientiert zu denken, v.a. weil man die Präfixe im Allgemeinen ja nur bei den eingebauten Typen verwendet. Die kommen im Code aber nur auf ganz niedriger Ebene vor. Und auf dieser Ebene is imho die Typinfo wichtig. Trotz allem "Do it as the ints": wenn ich in ner Klasse über ne set-Funktion ein Attribut setze und dieses ist außerhalb des Bereichs, in dem es sein soll, werd ich (wenn auch erst zur Laufzeit) nen aussagekräftigen Fehler bekommen ("Alter kann nicht 1000 sein!"). Wenn ich aber ne short-Variable auf 1000 setz, sagt mir das keiner. Und zur Laufzeit wird das an ganz anderen Stellen zu komischen verhalten führen. Also werd keinen Aufwand scheuen, diesen Fehler von vornherein zu vermeiden. Und ich denke, dass ein shAlter = 100000; eher ins Auge spring als ein Alter = 10000 (wenn man die Konvention kennt), v.a. wenn ich irgendwann auf die Idee komme, dass das Alter auch 10000 sein könnte, weil ich das Alter von Versteinerungen speicher will.
UND (das hab ich schon mal ausführlich erläutert):
Ich verwende Präfixe auch bei ausgewählten Klassen.
z.B.: Container: Welcher Container verwendet wird ist wichtig, da sie sich anders verhalten.
z.B.: std::string: Weil das doch eher ein "normaler" Typ ist. Wie in vielen anderen Programmiersprachen.
z.B.: smart-pointer: Weil hier auch das Verhalten wichtig ist.
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). Da gibts zwei wichtige Infos:
1. Was ist in dem Container: Personen. Also: Bestandzeil des Instanzennamens wird "Personen" sein.
2. In welchem Container sind die Personen? Hab ich Random-Access, kann ich schnell einfügen, ist das ganze sortiert?
Wenn ich also ne Liste mit Personen hab, wird das ganze deswegen lstPersonen heißen.
In Generischem Code, kann ich natürlich kein Präfix verwenden, weil ich die Info nicht hab. Keine Typ-Info kein Präfix.
Zitat:
Mittlerweile habe ich eine IDE die einen Punkt, falls nötig, automatisch in ein -> umwandelt.
klingt gut. Welche IDE ist das?
Leider erwartest Du dann aber von dem, der Deinen Code später weiterentwickelt, dass er auch so ne IDE hat. Das ist genauso, wie wenn Du davon ausgehst, dass der auch nen 21-Zoll-Monitor hat und Dir deswegen keine Gedanken über ewig lange Funktionen machst. Was ist, wenn es . und -> gibt, wie bei smart-Pointern.
Was ist, wenn es . und -> gibt, wie bei smart-Pointern.
Irrelevant. Der Code der *weiß*, dass es sich um einen smart-Pointer handelt, hat dieses Wissen *by design*, braucht kein Präfix und kann beides benutzen.
Der Code der *nicht wissen muss*, dass es sich um einen smart-Pointer handelt braucht kein Präfix, da er sowieso nur den -> (also die Zeigerschnittstelle) verwendet.
Ein smart-Pointer ist ein Implementationsdetail. Viele Teile des Code sollen überhaupt nicht wissen müssen ob sie mit einem Smart-Pointer oder einem normalen Pointer arbeiten.
Zitat:
Hier bin ich aber der Meinung, dass die zusätzliche Information nicht schadet
Gegenbeispiel. Wir schreiben eine neue Software House 1.0.
Die Software kann viele Häuser erstellen und man kann dann tolle Sachen damit machen. Schwimmen, laufen, radfahren. Was weiß ich.
Da wir modern sind und die Software viele verschiedene Häuser dynamisch erzeugen können muss, wird dies über eine Factory realisiert.
In der Version 1.0 liefert die Factory immer einen Pointer auf ein Haus:
// Irgendwo anders
class CHouse;
class CHouseCreator
{
public:
CHouse* makeHouse(const char* houseType);
//...
};
// und überall im Anwendungscode:
CHouse* ph1 = houseCreator.makeHouse("NormalesHaus");
...
CHouse* ph2 = houseCreator.makeHouse("HausOhneDach");
...
Eines schönen Tages stellen wir fest, dass die Basisklasse (C)House besser ein reines Interface sein sollte (vielleicht weil wir auf eine neue Komponententechnik umsteigen).
Code:
1 2 3 4 5 6 7 8 9
1 2 3 4 5 6 7 8 9
// kein Ctor mehr, alle Methoden abstrakt, keine Daten-Member
class House
{
public:
virtual void schwimm() = 0;
virtual void lauf() = 0;
virtual void fahrRad() = 0;
...
};
Code:
1 2 3 4 5 6 7 8 9
// kein Ctor mehr, alle Methoden abstrakt, keine Daten-Member
class House
{
public:
virtual void schwimm() = 0;
virtual void lauf() = 0;
virtual void fahrRad() = 0;
...
};
Code:
1 2 3 4 5 6 7 8 9
// kein Ctor mehr, alle Methoden abstrakt, keine Daten-Member
class House
{
public:
virtual void schwimm() = 0;
virtual void lauf() = 0;
virtual void fahrRad() = 0;
...
};
Die Änderung ist schnell gemacht. Die Factory und der Anwendungscode können unverändert bleiben.
Nicht aber in der Präfixvariante:
Code:
1 2 3 4 5 6 7 8 9
1 2 3 4 5 6 7 8 9
// kein Ctor mehr, alle Methoden abstrakt, keine Daten-Member
class IHouse
{
public:
virtual void schwimm() = 0;
virtual void lauf() = 0;
virtual void fahrRad() = 0;
...
};
Code:
1 2 3 4 5 6 7 8 9
// kein Ctor mehr, alle Methoden abstrakt, keine Daten-Member
class IHouse
{
public:
virtual void schwimm() = 0;
virtual void lauf() = 0;
virtual void fahrRad() = 0;
...
};
Code:
1 2 3 4 5 6 7 8 9
// kein Ctor mehr, alle Methoden abstrakt, keine Daten-Member
class IHouse
{
public:
virtual void schwimm() = 0;
virtual void lauf() = 0;
virtual void fahrRad() = 0;
...
};
Hier muss zusätzlich die Factory und der gesamte Anwendungscode geändert werden:
Code:
1 2 3 4 5 6 7 8 9 10 11 12 13
1 2 3 4 5 6 7 8 9 10 11 12 13
// Irgendwo anders
class IHouse;
class CHouseCreator
{
public:
IHouse* makeHouse(const char* houseType);
//...
};
// und überall im Anwendungscode:
IHouse* ph1 = houseCreator.makeHouse("NormalesHaus");
...
IHouse* ph2 = houseCreator.makeHouse("HausOhneDach");
...
Code:
1 2 3 4 5 6 7 8 9 10 11 12 13
// Irgendwo anders
class IHouse;
class CHouseCreator
{
public:
IHouse* makeHouse(const char* houseType);
//...
};
// und überall im Anwendungscode:
IHouse* ph1 = houseCreator.makeHouse("NormalesHaus");
...
IHouse* ph2 = houseCreator.makeHouse("HausOhneDach");
...
Code:
1 2 3 4 5 6 7 8 9 10 11 12 13
// Irgendwo anders
class IHouse;
class CHouseCreator
{
public:
IHouse* makeHouse(const char* houseType);
//...
};
// und überall im Anwendungscode:
IHouse* ph1 = houseCreator.makeHouse("NormalesHaus");
...
IHouse* ph2 = houseCreator.makeHouse("HausOhneDach");
...
Sicher, mit modernen Umgebungen ist sowas schnell erledigt.
Aus logischer Sicht ist die Änderung aber völlig unsinnig. Es spielt für die Anwendung überhaupt keine Rolle ob es sich bei House um ein Interface, eine abstrakte oder eine konkrete Klasse handelt. Häuser-Objekt werden sowieso durch die Factory erzeugt. Danach werden sie nur noch verwendet. Und zwar immer gleich. Ob nun IHouse, CHouse oder AHouse (keine Ahnung ob es sowas wie A gibt).
Ein weiteres Argument gegen ungarische Notation, dass ich immer wieder lese (formuliert von Charles Miller http://fishbowl.pastiche.org/)
Zitat:
Thirdly, and this is my problem with Hungarian notation in general, it's hard to read. Our eyes don't read words letter by letter, we read by pattern-matching the shapes of words, we only fall back on letter-by-letter in the worst case of not knowing a word at all. IApplication takes longer to read than Application. The extra I at the start changes the shape of the word, and your brain takes longer to parse it.
I prefer to have code that is easy to read in the general case, and tools that will tell me the supporting information if and when I need it. Hungarian notation is an artifact of a time when the tools weren't good enough to give us this information in any way but by throwing it all in our face at once. Now we have colour-coding, tool-tips and one-keypress navigation available to us, Hungarian notation is a horrendously clumsy anachronism. The information should be available, but not obscuring the code. Which is why I don't use Hungarian notation, but I do use a good, modern IDE.
<edit>Junge, Junge. Diese Code-Tags </edit>
<edit>Zitat kompletiert.</edit>
[ Dieser Beitrag wurde am 27.03.2003 um 13:37 Uhr von HumeSikkins editiert. ]
_________________ Remember Sturgeon's Law:
"Ninety percent of everything is crap." and now go visit my Homepage ;-)
In Deinem Beispiel hast Du recht. Ich kann aber natürlich nur für mich antworten: Da ein Interface und eine Klasse das gleiche Verhalten haben (und rein syntaktisch auch beide "class"en sind) käm ich nie auf die Idee für ne reine Interface-Klasse ein anderes Präfix als für ne konkrete Klasse zu nehmen.
Ich nehme z.B. ein anderes Präfix für ne Struct, aber hier ist das Verhalten auch anders. Structs sind (bei mir) immer PODs und haben somit ein anderes Verhalten als Klassen.
Du könnt Ihr jetzt ein Argument dagegen bringen: "bei mir". Bei nem anderen mag es anders sein. Aber wichtig imho ist v.a. dass es projektweit gleich ist. Und wenns die Projektleiter wichtig finden: firmenweit.
Aber Programmierstile weichen sowieso voneinander ab.
Das mit dem Lesen zieht nach wie vor nicht. Das ist schlimmstenfalls Gewöhnungssache. Je nachdem, was einen am Code interessiert, ist das Gehirn durchaus in der Lage, die Präfixe auszublenden. Man beachtet ja z.B. auch nur die Verkehrsschilder, die wichtig für einen sind. Das kann Dir jeder Wahrnehmungspsychologe sagen. Wenn ich den Code nur mal schnell durchlesen will um festzustellen, wie das ganze grob arbeitet, beachte ich die Präfixe nicht. Will ichs genau sehen (und bin evtl. auf Fehlersuche) helfen sie mir, weil sie ne Gedächtnisstütze sind. Hier geht es schneller, wenn das Gehirn das parst, als wenn es sich für jede Variable erinnern muss, welcher Typ sie war.
PS: Ich fänd ne IDE toll, wo (zumindest die eingebauten Typen) irgendwie anders gekennzeichnet sind. Farbe, Symbol am Editorrand, Bubble-Help beim drüberfahren mit der Maus, keine Ahnung wie.
Leider arbeite ich hier aber mit dem C++Builder. Und da funktioniert bei Projekten > 20 Modulen noch nicht mal das "springen zu Deklaration" oder die Codevervollständigung (zumindest nicht mit einer angemessenen Geschwindkeit < 10 sec).
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
C/C++ Code:
peter.geh_zur_arbeit();
C/C++ Code:
peter.geh_zur_arbeit();
C/C++ Code:
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. ]
_________________ Manual memory management is premature optimization.
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...
Zitat:
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::string
das sind also 3 unterschiedliche string klassen - fühlen sich aber alle 3 mehr oder weniger gleich an.
Zitat:
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)
Zitat:
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?
Zitat:
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.
Zitat:
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. persons
Zitat:
Wenn 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
Zitat:
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.
Zitat:
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.
_________________ A language that doesn't affect the way you think about programming is not worth knowing.
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.
Code:
das sind also 3 unterschiedliche string klassen - fühlen sich aber alle 3 mehr oder weniger gleich an.
Code:
das sind also 3 unterschiedliche string klassen - fühlen sich aber alle 3 mehr oder weniger gleich an.
Code:
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.
Code:
nd wie stehts mit S_Person? wie sagst du dazu?
Code:
nd wie stehts mit S_Person? wie sagst du dazu?
Code:
nd wie stehts mit S_Person? wie sagst du dazu?
und
Zitat:
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.
Zitat:
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.
Zitat:
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.
Zitat:
das ist alles aber nur meine persönliche ansicht.
Wessen sonst. Die Aussage hat ähnlich viel sinn wie ein C vor Klassen.
Zitat:
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.
_________________ Manual memory management is premature optimization.
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.
_________________ Remember Sturgeon's Law:
"Ninety percent of everything is crap." and now go visit my Homepage ;-)
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.
Zitat:
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.
_________________ Manual memory management is premature optimization.
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 :)
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...
_________________ Zu jedem Problem gibt es eine Lösung, die klar, einfach und falsch ist.
Mit 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).
Nächstes Thema anzeigen Vorheriges Thema anzeigen
Sie können keine Beiträge in dieses Forum schreiben. Sie können auf Beiträge in diesem Forum nicht antworten. Sie können Ihre Beiträge in diesem Forum nicht bearbeiten. Sie können Ihre Beiträge in diesem Forum nicht löschen. Sie können an Umfragen in diesem Forum nicht mitmachen.
c++.de ist Teilnehmer des Partnerprogramms von Amazon Europe S.à.r.l. und Partner des Werbeprogramms, das zur Bereitstellung eines Mediums
für Websites konzipiert wurde, mittels dessen durch die Platzierung von Werbeanzeigen und Links zu amazon.de
Werbekostenerstattung verdient werden kann.
Die Vervielfältigung der auf den Seiten www.c-plusplus.de, www.c-plusplus.info, www.c-sar.de, www.c-plusplus.net und www.baeckmann.de
enthaltenen Informationen ohne eine schriftliche Genehmigung des Seitenbetreibers ist untersagt
(vgl. §4 Urheberrechtsgesetz). Die Nutzung und Änderung der vorgestellten Strukturen und Verfahren in
privaten und kommerziellen Softwareanwendungen ist ausdrücklich erlaubt, soweit keine Rechte Dritter verletzt werden.
Der Seitenbetreiber übernimmt keine Gewähr für die Funktion einzelner Beiträge oder Programmfragmente, insbesondere
übernimmt er keine Haftung für eventuelle aus dem Gebrauch entstehenden Folgeschäden.
Twitter
Facebook
)
