FYI: Namenskonvention: private und lokale Variablen
Frank Dzaebel
Öfter einmal kommen Fragen zu Namenskonventionen unter C#. Speziell lokale
und private Variablen standen im Fokus. Teilweise wurden schon durch private
Emails an führende Microsoft-Verantwortliche Erkenntnisse erzielt.
Hier aber endlich einmal offizielle Empfehlungen auf MS-Seiten auch zu
privaten/lokalen Variablen, ausserhalb der Brad Abrams Recommendations.
Diese sollten CamelCase geschrieben werden!
(ich habe das hier immer wieder vertreten). Ungarische Notation vermeiden
(das ist zwar auch schon in einigen Empfehlungen, aber durch das Fehlen der
*offiziellen* "private-CamelCase-Empfehlung" wurden Member-Variablen von
einigen als legitime Ausnahme gedeutet (etwa: int m_Anzahl, speziell
VB'ler). Dies ist nun in diesem Microsoft-Artikel als "nicht" empfohlen
geklärt, denn Member-Variablen sind privat.
[Qualitätssicherung für verwalteten Sourcecode]
http://www.microsoft.com/germany/msdn/library/net/QualitaetssicherungFuerVerwaltetenSourcecode.mspx
Zitat aus obigem Artikel von Microsoft:
"Namenskonventionen:
[Namen]
Im Allgemeinen müssen Namen lesbar sein und das Element klar beschreiben.
Suchen Sie aus diesem Grund bei Codeüberprüfungen nach Abkürzungen in Namen,
Kurznamen oder nicht beschreibenden Namen. Es ist sinnvoll, Funktions- und
Methodennamen mit einem Verb zu beginnen, um die Aktion zu kennzeichnen, die
sie für ihre Objekte durchführen. Ähnlich dazu sollten Variablennamen und
Eigenschaftennamen Substantive sein, da es sich hierbei um Objekte handelt.
Wenn Sie beispielsweise eine Klasse für Ebenengeometrieobjekte (wie einen
Kreis) schreiben würden, können Sie Eigenschaften mit den Namen CenterPoint
und Radius definieren. Funktionsnamen für eine solche Klasse können
CalculateCircumference und CalculateArea sein.
[Fallkonventionen in Namen]
Stellen Sie sicher, dass der Quellcode die Fallkonventionen einhält, die im
Abschnitt Capitalization Styles (auf Englisch) der Dokumentation zu
Namensrichtlinien (siehe Verweis weiter oben in diesem Artikel) empfohlen
werden. Mit anderen Worten, verwenden Sie camelCasing (der erste Buchstabe
des Namens ist klein geschrieben, und der erste Buchstabe jedes weiteren
Worts im Namen ist groß geschrieben) für Parameter, lokale Variablen und die
*privaten* oder geschützten Variablen einer Klasse. Verwenden Sie
PascalCasing (der erste Buchstabe jedes Worts im Namen ist groß geschrieben)
für alle anderen Elemente, einschließlich Klassennamen, Methoden,
Eigenschaften, Typdeklarationen und Enumerationswerte.
[Ungarische Notation]
Ungarische Notation wird für verwalteten Code nicht empfohlen. Die korrekte
Verwendung von ungarischer Notation ist schwierig, und ungarische Notation
ist schwer lesbar. Die Schwierigkeiten beim Lesen ungarischer Notation
können außerdem die Logik verschleiern. Manche Programmierer haben sich die
Verwendung ungarischer Notation beim Programmieren von C oder C++ zur
Gewohnheit gemacht. Bedenken Sie dies bei Codeüberprüfungen."
zusätzliche Anmerkung von mir:
Im Prinzip müsste das für VB.NET hier auch gelten, da hier nicht
unterschieden wird, aber das sollte in den VB-Gruppen geklärt werden, denn
es gibt hier ein paar Besonderheiten, deswegen sollte es wenn, dann dort
thematisiert werden.
ciao Frank
--
Dipl.Inf. Frank Dzaebel [MCP/MVP C#]
http://Dzaebel.NET
Herfried K. Wagner [MVP]
> [Qualitätssicherung für verwalteten Sourcecode]
> http://www.microsoft.com/germany/msdn/library/net/QualitaetssicherungFuerVerwaltetenSourcecode.mspx
>
> Zitat aus obigem Artikel von Microsoft:
>
> "Namenskonventionen:
>[...]
> [Fallkonventionen in Namen]
Was ist eine "Fallkonvention"? Ja, ich weiss, was damit gemeint ist. Die
Übersetzung ist schlecht. Hier findet sich der englische Originalartikel:
.NET Development (General) Technical Articles -- Reviewing Managed Code
<URL:http://msdn2.microsoft.com/en-us/library/bb278146.aspx>
> Stellen Sie sicher, dass der Quellcode die Fallkonventionen einhält, die
> im Abschnitt Capitalization Styles (auf Englisch) der Dokumentation zu
> Namensrichtlinien (siehe Verweis weiter oben in diesem Artikel) empfohlen
> werden. Mit anderen Worten, verwenden Sie camelCasing (der erste Buchstabe
> des Namens ist klein geschrieben, und der erste Buchstabe jedes weiteren
> Worts im Namen ist groß geschrieben) für Parameter, lokale Variablen und
> die *privaten* oder geschützten Variablen einer Klasse.
Hier muss ich John D'Addamio unterstellen, Microsofts eigene Konventionen
nicht zu kennen. Er verweist in seinem Artikel einerseits auf die
offiziellen Benennungsrichtlinien, wo (ich nehme an, bewusst) keine Aussage
über private Variablen getroffen wird (aus guten Gründen), um sie dann
(Zitat aus dem oben genannten englischen Originalartikel) "In other words"
nicht authentisch (lies: verändert) wiederzugeben. Zudem funktioniert die
genannte Konvention ja nicht einmal in VB.NET, auf das sich der Artikel auch
beziehen soll (siehe auch Hinweis zur Anweisung 'GoTo' und in der
Einleitung).
Der Artikel ist m.E. als teilweise unbedacht geschriebene "Sekundärmeinung"
einzustufen und keinesfalls als offizielle Konvention.
Abgesehen davon halte ich (als einer der wenigen, die sich dazu Gedanken
gemacht haben) meine Kritik an der genannten Pseudokonvention aufrecht --
eben aus Gründen der Codequalität, die ich dadurch gefährdet sehe:
Zur Sinnhaftigkeit der Camel Case-Konvention
<URL:http://dotnet.mvps.org/dotnet/articles/camelcase/>
-> "Die Camel Case-Konvention als Fehlerquelle"
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>
Thomas Scheidegger [MVP]
> Öfter einmal kommen Fragen zu Namenskonventionen unter C#.
> Speziell lokale und private Variablen standen im Fokus.
> Hier aber endlich einmal offizielle Empfehlungen
schon vor ~5 Jahren waren entsprechende 'Empfehlungen'
bereits mal zB in der ECMA-Norm/Entwurf aufgeführt:
http://groups.google.com/group/microsoft.public.de.german.entwickler.dotnet.csharp/msg/eba7bc00f40b4ee6
also eigentlich nichts neues im Westen....
(ausser dass inzwischen wohl einiges an Verwässerung und Besserwisserei aufgekommen ist...)
--
Thomas Scheidegger - MVP .NET - 'NETMaster'
http://www.cetus-links.org/oo_dotnet.html - http://dnetmaster.net/
Ulf Kadner
> (ich habe das hier immer wieder vertreten). Ungarische Notation
> vermeiden (das ist zwar auch schon in einigen Empfehlungen, aber durch
> das Fehlen der *offiziellen* "private-CamelCase-Empfehlung" wurden
> Member-Variablen von einigen als legitime Ausnahme gedeutet (etwa: int
> m_Anzahl, speziell VB'ler). Dies ist nun in diesem Microsoft-Artikel als
> "nicht" empfohlen geklärt, denn Member-Variablen sind privat.
Hallo Frank!
Was für eine Rolle spielt das? In meinen Augen garkeine.
Überleg mal: MS stellt zur Sprache eine passende IDE her die von Haus
aus private Variablen in *ausschließlich* dieser Notation (m_whatever)
korrekt unterstützt.
Wie ich darauf komme? Ganz einfach... Nur mit so benannten privaten
Variablen kann ich auch anständig Refactoring anwenden.
(Refactoring->Encapsule Field) erwartet dies um vernünftige
Eigenschaftsnamen zu produzieren. Ich werde mich hüten mir mehr arbeit
zu machen als nötig wäre.
Das sollte doch (logisch betrachtet) einer der besten Idikatoren dafür
sein, das es von MS sogar so gewollt ist.
Just my 5 cents.
MfG, Ulf
Frank Dzaebel
> > Öfter einmal kommen Fragen zu Namenskonventionen unter C#.
> > Speziell lokale und private Variablen standen im Fokus.
> > Hier aber endlich einmal offizielle Empfehlungen
> schon vor ~5 Jahren waren entsprechende 'Empfehlungen'
> bereits mal zB in der ECMA-Norm/Entwurf aufgeführt:
http://groups.google.com/group/microsoft.public.de.german.entwickler.dotnet.csharp/msg/eba7bc00f40b4ee6
> also eigentlich nichts neues im Westen....
> (ausser dass inzwischen wohl einiges an Verwässerung und Besserwisserei aufgekommen ist...)
... das mit den *privaten* Variablen war nicht enthalten,
das wird jetzt explizit erwähnt,
aber vieles war im Prinzip durch die erwähnten Richtlinien klar
und somit hatten wir beide hier ähnliche Interpretationen schon
immer empfohlen. Hier nochmal die bisherigen Formulierungen,
die so natürlich weiterhin gültig sind:
[Capitalization Styles]
http://msdn2.microsoft.com/en-us/library/x2dbyw72(VS.71).aspx
:-)
Frank Dzaebel
> > (etwa: int m_Anzahl, speziell VB'ler). Dies ist nun in
> > diesem Microsoft-Artikel als
> > "nicht" empfohlen geklärt, denn Member-Variablen sind privat.
>
> Was für eine Rolle spielt das? In meinen Augen garkeine.
Doch, für Leute die sich an CodingStyles halten, oder
damit arbeiten und alle Leute die C# codieren und einen
gewissen Standard zur Qualitätssicherung für verwalteten
Sourcecode pflegen.
> Überleg mal: MS stellt zur Sprache eine passende IDE her die von Haus
> aus private Variablen in *ausschließlich* dieser Notation (m_whatever)
> korrekt unterstützt.
Das ist so unrichtig. Die meisten hier in dieser Gruppe schreiben
ohne m_*** (including me :) und mit Visual Studio ohne Probleme.
Es ist aber trotzdem nur eine Empfehlung (allerdings nunmehr explizit
und sehr deutlich ohne Interpretationsspielraum).
Wenn Du/Ihr spezielle Gründe hast, kannst Du eigene
Benamungen wählen. Allerdings solltest Du nicht
verallgemeinern, wenn Du bei bestimmten Problemen
noch keine eigene Lösung gefunden hast. Andere
könnten das vielleicht schon.
Herfried K. Wagner [MVP]
"Ulf Kadner" <dr_l...@gmx.net> schrieb:
>> (ich habe das hier immer wieder vertreten). Ungarische Notation vermeiden
>> (das ist zwar auch schon in einigen Empfehlungen, aber durch das Fehlen
>> der *offiziellen* "private-CamelCase-Empfehlung" wurden Member-Variablen
>> von einigen als legitime Ausnahme gedeutet (etwa: int m_Anzahl, speziell
>> VB'ler). Dies ist nun in diesem Microsoft-Artikel als "nicht" empfohlen
>> geklärt, denn Member-Variablen sind privat.
>
> Was für eine Rolle spielt das? In meinen Augen garkeine.
> Überleg mal: MS stellt zur Sprache eine passende IDE her die von Haus aus
> private Variablen in *ausschließlich* dieser Notation (m_whatever) korrekt
> unterstützt.
>
> Wie ich darauf komme? Ganz einfach... Nur mit so benannten privaten
> Variablen kann ich auch anständig Refactoring anwenden.
> (Refactoring->Encapsule Field) erwartet dies um vernünftige
> Eigenschaftsnamen zu produzieren. Ich werde mich hüten mir mehr arbeit zu
> machen als nötig wäre.
Zumindest laut Dokumentation sollte "Encapsulate Field" auch mit anders
benannten privaten Variablen umgehen können, z.B. 'width' (Beispiel im
Artikel "Visual C# Application Development -- How to: Refactor Code with
Encapsulate Field"). Was genau funktioniert nicht?
Herfried K. Wagner [MVP]
"Frank Dzaebel" <PostAddFranksSeitePunktDe> schrieb:
Vorweg: Wir haben hier einfach verschiedene Ansichten.
>> > (etwa: int m_Anzahl, speziell VB'ler). Dies ist nun in
>> > diesem Microsoft-Artikel als
>> > "nicht" empfohlen geklärt, denn Member-Variablen sind privat.
>>
>> Was für eine Rolle spielt das? In meinen Augen garkeine.
>
> Doch, für Leute die sich an CodingStyles halten, oder
> damit arbeiten und alle Leute die C# codieren und einen
> gewissen Standard zur Qualitätssicherung für verwalteten
> Sourcecode pflegen.
Ich behaupte, dass eben gerade diese Konvention nicht der Qualität des Codes
zuträglich ist, da ich in der Praxis nur allzuoft daraus resultierende
Probleme (Implementierungsfehler) gesehen habe. Deshalb würde ich dringend
davon abraten, alles, was Microsoft-Mitarbeiter schreiben, für bare Münze zu
nehmen, sondern vorgeschlagene Regeln selbst zu analysieren und mit den
eigenen Erfahrungen abzugleichen.
Letztendlich hat es auf die Codequalität keinen Einfluss, welche
Konventionen zur Benennung (ungeachtet ihrer näheren Analyse) genutzt
werden, solange die Nutzung konsequent erfolgt. Allerdings kann man sehrwohl
verschiedene Konventionen hinsichtlich ihrer Vorteile und Nachteile
analysieren und die sicherste, eindeutigste, am leichtesten zu codierende
und wartbarste Konvention auswählen.
>> Überleg mal: MS stellt zur Sprache eine passende IDE her die von Haus
>> aus private Variablen in *ausschließlich* dieser Notation (m_whatever)
>> korrekt unterstützt.
>
> Das ist so unrichtig. Die meisten hier in dieser Gruppe schreiben
> ohne m_*** (including me :) und mit Visual Studio ohne Probleme.
> Es ist aber trotzdem nur eine Empfehlung (allerdings nunmehr explizit
> und sehr deutlich ohne Interpretationsspielraum).
Ich würde es eher für einen Fehler im Artikel halten, denn der Autor will
mit dem Satz etwas sinngemäss wiedergeben, tut dies aber nicht.
Ulf Kadner
> Zumindest laut Dokumentation sollte "Encapsulate Field" auch mit anders
> benannten privaten Variablen umgehen können, z.B. 'width' (Beispiel im
> Artikel "Visual C# Application Development -- How to: Refactor Code with
> Encapsulate Field"). Was genau funktioniert nicht?
Hallo Herfried!
Zuerst: Es funktioniert alles wie ichs mir wünsche.
Da gabs doch aber auch Konventionen, die besagen, das man privaten
Feldern nicht den selben Namen geben sollte wie Ihren zugeordneten
Eigenschaften. Oder täusche ich mich da etwa? Aber irgendwas war da
doch... Mir liegst sozusagen auf der Zunge.
Wenn ich z.B. alle privaten Felder m_abc - m_xyz nenne, ergibt das mit
Refactoring auch die Eigenschaften Abc - Xyz. Selbiges (sinnfrei) mit
i_abc - i_xyz ergibt aber I_abc - I_xyz als resultirende
Eigenschaftsnamen. Defacto kanns ja nicht falsch sein m_* zu nutzen. Es
sei denn MS weis nicht was richtig oder falsch ist und implementiert
Funktionalität einfach nach dem Glücksrad-Prinzip. (bezweifle ich aber)
MfG, Ulf
Ulf Kadner
>> Überleg mal: MS stellt zur Sprache eine passende IDE her die von Haus
>> aus private Variablen in *ausschließlich* dieser Notation (m_whatever)
>> korrekt unterstützt.
>
> Das ist so unrichtig.
Hallo Frank!
"Unrichtig" klingt genau so seltsam wie "ungeil". :-)
> Die meisten hier in dieser Gruppe schreiben
> ohne m_*** (including me :) und mit Visual Studio ohne Probleme.
Warum baut dann MS ein spezielles Refactoring für diese Schreibweise in
der IDE ein? Aber sag jetzt nicht "Weil soviele es falsch machen"! ;-)
> Es ist aber trotzdem nur eine Empfehlung
Eben, nicht mehr
> Wenn Du/Ihr spezielle Gründe hast, kannst Du eigene
> Benamungen wählen.
Das brauche ich doch garnicht. Ich nutze die von MS durch Funktionalität
in der IDE vorgeschlagene. (m_*)
> Allerdings solltest Du nicht
> verallgemeinern, wenn Du bei bestimmten Problemen
> noch keine eigene Lösung gefunden hast.
Ich wuste nicht das ich diesbezueglich ein Problem habe!
Verallgemeinert hab ich auch nix. Von was redest Du?
MfG, Ulf
Frank Dzaebel
> >> Überleg mal: MS stellt zur Sprache eine passende IDE her die von Haus
> >> aus private Variablen in *ausschließlich* dieser Notation (m_whatever)
> >> korrekt unterstützt.
> > Das ist so unrichtig.
> "Unrichtig" klingt genau so seltsam wie "ungeil". :-)
Es ist *falsch*, was Du sagst, wenn Du es so besser verstehst :)
Ich versuche manchmal in der Formulierung etwas
Rücksicht zu nehmen.
Ich denke, die Ursache könnte sein, dass Du
Dir irgendein 3rd-Party AddIn "eingefangen" hast.
VS Studio bietet standardmässig bei
"Encapsulating field" bzw. "Umgestalten/Feld einkapseln"
die CamelCase-Darstellung an.
Das gleiche gilt für:
prop[TAB][TAB]
> > Allerdings solltest Du nicht
> > verallgemeinern, wenn Du bei bestimmten Problemen
> > noch keine eigene Lösung gefunden hast.
> Ich wuste nicht das ich diesbezueglich ein Problem habe!
> Verallgemeinert hab ich auch nix. Von was redest Du?
Naja, dass Du es anscheinend nicht schaffst, mit
CamelCase Membervariablen-Standard in Deinem Studio
zurechtzukommen. Das Problem haben zumindest
einige andere (including me) hier nicht.
ciao Frank
--
Dipl. Inf. Frank Dzaebel [MCP, MVP C#]
http://Dzaebel.NET
Herfried K. Wagner [MVP]
"Frank Dzaebel" <PostAddFranksSeitePunktDe> schrieb:
>> >> Überleg mal: MS stellt zur Sprache eine passende IDE her die von Haus
>> >> aus private Variablen in *ausschließlich* dieser Notation
>> >> (m_whatever)
>> >> korrekt unterstützt.
>> > Das ist so unrichtig.
>> "Unrichtig" klingt genau so seltsam wie "ungeil". :-)
>
> Es ist *falsch*, was Du sagst, wenn Du es so besser verstehst :)
> Ich versuche manchmal in der Formulierung etwas
> Rücksicht zu nehmen.
>
> Ich denke, die Ursache könnte sein, dass Du
> Dir irgendein 3rd-Party AddIn "eingefangen" hast.
Nein, hat er nicht. "Umgestalten" -> "Feld einkapseln" unterstützt gesondert
'm_' als Präfix und benennt die erstellte Eigenschaft richtig.
> VS Studio bietet standardmässig bei
> "Encapsulating field" bzw. "Umgestalten/Feld einkapseln"
> die CamelCase-Darstellung an.
Es bietet gar nichts an, denn man ruft es für eine bestehende Variable auf.
> Das gleiche gilt für:
> prop[TAB][TAB]
Dies bietet ohnehin einen völlig unsinnigen Standardnamen (Platzhalter) an,
der zudem nicht an den Eigenschaftennamen gebunden ist. Man könnte sogar
soweit gehen, dies als 'my'-Präfix zu interpretieren.
Ulf Kadner
> Es ist *falsch*, was Du sagst, wenn Du es so besser verstehst :)
Das finde ich natürlich nicht! :-)
> Ich versuche manchmal in der Formulierung etwas
> Rücksicht zu nehmen.
Das verfälscht nur das Original.
> Ich denke, die Ursache könnte sein, dass Du
> Dir irgendein 3rd-Party AddIn "eingefangen" hast.
Und Du erzählst mir was von "Sein VS kennen". Du kennsts scheinbar
selbst nicht besser. Ich nutze kein einziges AddIn. Das kann VS schon
seit ich es das erste mal genutzt habe.
> VS Studio bietet standardmässig bei
> "Encapsulating field" bzw. "Umgestalten/Feld einkapseln"
> die CamelCase-Darstellung an.
Da gibts doch nix anzubieten. Die Logik dahinter ist denkbar einfach.
Prüfe ob Feldname mit "m_" beginnt, wenn ja Abschneiden. Dann einfach
ersten Buchstaben nach UpperCase und das wars schon.
> Das gleiche gilt für:
> prop[TAB][TAB]
Das ist was vollkommen Anderes! Das sollte für die "Gegenrichtung
genutzt werden.
> Naja, dass Du es anscheinend nicht schaffst, mit
> CamelCase Membervariablen-Standard in Deinem Studio
> zurechtzukommen.
Das will ich ja garnicht. Wie bereits gesagt, Microsoft hats bei der
Entwicklung vom VS2005 nicht als schlechten Stil eingeordnet, sonst wärs
ja nicht Bestandteil von selbigen.
Aber mal so und mal so. Ne da bleib ich lieber bei meiner bisher
eingeschliffenen Arbeitsweise. Zumal es sich doof macht, wenn man allen
Code wegen solcher Dummheiten umarbeiten will. Bezahlt ja keiner. Es war
ja vor kurzen noch nicht als suboptimal eingestuft. Wenns doch so von
Dir wahrgenommen wurde dann kann ich Dir da nicht folgen.
Für mich stellt sich das so dar, das 2 Verschiedene Schreibweisen
existieren und scheinbar auch genutzt werden (camelCase und m_hungarian)
Die einen mögen mehr die Kamele und die Anderen mehr die Ungarn (man
verzeihe mir den Vergleich).
Diese Sichtweisen scheinen auch bei MS zu existieren und zu derartig
unterschiedlichen Meiningsbildungen beitragen. Es gibt hier meiner
Meinung nach keine verläßliche Quelle, da sich die Herausgeber der
Quelle da ja selbst nicht einig sind.
MfG, Ulf
Frank Dzaebel
> Es ist *falsch*, was Du sagst, wenn Du es so besser verstehst :)
> Ich versuche manchmal in der Formulierung etwas Rücksicht zu nehmen.
Deine Aussage war ja:
"... private Variablen in *ausschließlich* dieser Notation (m_whatever)"
Die ist halt falsch.
Tatsächlich eben standardmässig - wenn Du auf
int einFeld;
mit rMaus/Umgestalten/"Feld einkapseln"
drauf klickst, wirst Du standardmässig
private CamelCase-Member-Variablen bekommen,
ohne irgendein "m_".
Klar, wenn Du int m_w5O__h7k_;
schreibst, wird Refactoring dies auch korrekt übernehmen ;-)
Deine Aussage "*ausschließlich* dieser Notation"
ist also schlichtweg falsch. Normal umschreibe ich
das etwas, um dem anderen eine Möglichkeit zu lassen,
dies zu relativieren, aber Du wolltest ja die klare Aussage.
> AddIn "eingefangen" ...
Ich gibt AddIns, die sind in der Lage,
für Legacy-Schreibweise (speziell C++) aus
kleinen "int einFeld;" ein "m_EinFeld" machen können, mit
entsprechender Eigenschafts-Umwandlung.
Vielleicht meinst Du ja dieses, denn in Visual Studio
wird da nichts mit "m_" zugedichtet, wie Du fälschlich
vermutest.
> Das gleiche gilt für:
> prop[TAB][TAB]
hier wird auch standardmässig nicht ungarisch CamelCase ohne
irgendeine "m_" Zudichtung genommen. Also
Dein Refacturing-Argument würde ich mal eher als
Argument für eine nicht ungarische CamelCase-Notation
dahernehmen ;-)
Frank Dzaebel
>> Ich versuche manchmal in der Formulierung etwas
>> Rücksicht zu nehmen.
> Das verfälscht nur das Original.
Ich machs aber so, jeder soll seine Art behalten :-)
Du darfst gerne ordentlich reinhauen, solange Du
Dich an die Nettiquetee hältst, aber Du hältst Dich daran,
also ok. Meine Aussagen zu Deinem Posting
habe ich gleichzeitig mit Dir gepostet, Du kannst ja
dort antworten.
> Das will ich ja garnicht. Wie bereits gesagt, Microsoft hats bei der
> Entwicklung vom VS2005 nicht als schlechten Stil eingeordnet, sonst wärs
> ja nicht Bestandteil von selbigen.
ja, das ist jetzt relativ neu, dass es so offiziell in den MS-Seiten
erscheint,
obwohl ich das hier ja schon vor langem über private Emails an Brad
Abrams hier aufgezeigt hatte (CamelCase für private Variablen empfohlen).
Es ist Dir evtl. nicht mehr bekannt.
Aber ich möchte da trotzdem nochmals klarstellen, dass
dies nur eine Empfehlung ist. Du hast für Dich immernoch die
Möglichkeit gegen die Empfehlung zu verstossen, ohne Auswirkungen
auf Programm-Funktion o.ä.
> Aber mal so und mal so. Ne da bleib ich lieber bei meiner bisher
> eingeschliffenen Arbeitsweise.
Kann ich auch mal nachvollziehen, ist halt nur dann dumm, wenn
man mit Leuten zusammenkommt, die sich an die jetztigen
Standards halten. Du stehst ja auch nicht ganz allein. So empfiehlt
z.B. IDesign noch immer eine "m_" Schreibweise und die sind
eigentlich in der Richtung recht professionell. Da sind wohl auch
noch einige C++ ler drin gewesen.
> Zumal es sich doof macht, wenn man allen Code wegen solcher Dummheiten
> umarbeiten will. Bezahlt ja keiner.
ACK, wenn Du das Posting von Brad früher gelesen
hättest, wäre es evtl. jetzt nicht aufwendig.
> Für mich stellt sich das so dar, das 2 Verschiedene Schreibweisen
> existieren und scheinbar auch genutzt werden (camelCase und m_hungarian)
> Die einen mögen mehr die Kamele und die Anderen mehr die Ungarn (man
> verzeihe mir den Vergleich).
Ich kanns ja auch nicht ändern, die offizielle Empfehlung
ist halt raus. Und das eigentlich halbwegs schon länger (Brads Posting).
Allerdings hat Kwalina [MS] vor Jahren auch bestätigt, dass diese
Empfehlungen nicht zu dogmatisch gesehen werden sollen.
> Diese Sichtweisen scheinen auch bei MS zu existieren und zu derartig
> unterschiedlichen Meiningsbildungen beitragen.
ACK, die existierten und es waren *früher* auch bei MS noch einige da,
die gerne die "m_" Schreibweise genommen hätten (alte C++ ler).
Man sieht das sogar noch in ein paar Framework-Code-Stellen.
Ich kanns ja wie gesagt nicht ändern, aber von meiner Seite her
finde ich die Empfehlung gut, auch, wenn ich die Leute mit
den "m_"'s verstehen kann, wenn sie viele Codezeilen so geschrieben haben.