Namenskonventionen für Steuerelemente
Coder2001
ich steige momentan von VB6 auf C# um. Ich bin unsicher, wie ich meine
Steuerelemente benennen soll. In VB6 hatte ich grundsätzlich die "ungarische
Notation" verwendet (z. B. lblUser oder frmMain). Diese Schreibweise ist, wie
ich herausgelesen habe, inzwischen verpönt! Vielleicht hat jemand Vorschläge
zu diesem Thema.
mfg Uli
Günter Prossliner
> ich steige momentan von VB6 auf C# um.
Gute Entscheidung.
> Ich bin unsicher, wie ich meine
> Steuerelemente benennen soll. In VB6 hatte ich grundsätzlich die
> "ungarische Notation" verwendet (z. B. lblUser oder frmMain). Diese
> Schreibweise ist, wie ich herausgelesen habe, inzwischen verpönt!
Generell schon. Allerdings ist diese bei Steuerelementen durchaus noch
verbreitet und kann IMO auch verwendet werden.
Teilweise sieht man bei Controls auch z.B.:
NameLabel
NameTextBox
anstelle von
lblName
txtName
Wenn Du ein Prefix für Formulare verwedest, solltest Du allerdings auf jeden
Fall den ersten Buchstaben gross schreiben (FrmMain anstelle von frmMain).
Der Name des Formulars ist auch der Name der Klasse, und Klassennamen
"gehören" gross geschrieben.
mfg GP
Marc Weichhold
> Ich bin unsicher, wie ich meine
> Steuerelemente benennen soll. In VB6 hatte ich grundsätzlich die
> "ungarische
> Notation" verwendet (z. B. lblUser oder frmMain). Diese Schreibweise ist,
> wie
> ich herausgelesen habe, inzwischen verpönt!
>
Es ist nicht unbedingt notwendig, immer mit dem Strom zu schwimmen. Jede
Notation hat ihre Vor- und Nachteile, puristische Diskussionen über die
"richtige" Notation sind in meinen Augen unsinnig. Es gibt keine "richtige"
Notation. Wenn Du bisher mit der ungarischen Notation gut zurecht gekommen
bist, spricht nichts dagegen, sie auch beizubehalten. Ich hatte auch schon
C#-Projekte, bei denen die ungarische Notation (Applications) ohne Probleme
benutzt wurde und immer noch benutzt wird. Sie ist und bleibt
sprachübergreifend mein Favorit.
Meiner Meinung nach gibt es grundsätzlich nur eine allgemeingültige Aussage
zu den Glaubenskriegen um die "richtige" Notation:
Es ist nicht wichtig, WELCHE Notation man in einem Projekt benutzt, wichtig
ist nur, dass ALLE DIESELBE Notation benutzen.
Marc
Frank Dzaebel
Bei Steuerelementen ist es durchaus verbreitet, hier
noch ein Kürzel davorzuschreiben. Ansonsten gilt
heutzutage offiziell der Link in:
Im grossen und ganzen sollte man sich daran halten!
Es ist keineswegs egal, wie die Benennung seiner
Variablen aussieht, wie hier teilweise gepostet wird.
ciao Frank
--
Dipl. Inf. Frank Dzaebel [MCP, MVP C#]
http://Dzaebel.NET
Marc Weichhold
> Ansonsten gilt
> heutzutage offiziell der Link in:
>
> http://groups.google.com/group/microsoft.public.de.german.entwickler.dotnet.csharp/msg/2a61d6ae2c6e06f0
>
> Im grossen und ganzen sollte man sich daran halten!
> Es ist keineswegs egal, wie die Benennung seiner
> Variablen aussieht, wie hier teilweise gepostet wird.
>
1. Die Zitate aus dem MS-Artikel sprechen eindeutig EMPFEHLUNGEN aus.
Aussagen wie "sollte nicht verwendet werden", "es wird empfohlen" oder "ist
schwierig zu lesen" basieren eher auf den subjektiven Einschätzungen des
Verfassers und sind keinesfalls zu verallgemeinern.
2. Wieso die Meinung Microsofts nun plötzlich als weltweite und
allein-korrekte Richtlinie gelten soll, erschließt sich mir nicht so ganz.
Was wenn eine andere Firma eine ganz andere Konvention empfiehlt?
3. Was wenn MS nun nächstes Jahr wieder eine ganz andere Notation empfiehlt?
"Müssen" sich dann wieder alle umgewöhnen?
4. Was ist "falsch" an einer Notation, die von der von MS propagierten
abweicht?
Ich bleibe dabei:
Es ist egal, wie die Benennung seiner Variablen, Funktionen, etc. aussieht.
Wichtig allein ist, dass sie konsequent durchgehalten wird. Ich kann mir
nicht vorstellen, dass Du z.B. jemals in die Verlegenheit kommen wirst, den
Code meiner Projekte zu lesen. Wieso sollten wir also den seit Jahren
praktizierten Stil in unserer Firma ändern, nur um "mit der Mode" zu gehen?
Wir kommen mit unserer Notation hier sehr gut zurecht und allein das ist
wichtig. Wenn Du in Deiner Firma die von MS propagierte Notation benutzt,
ist das doch ok. Aber jemandem implizit verklickern zu wollen, die von ihm
benutzte Notation sei "falsch" halte ich für ziemlichen Unsinn.
Daher: Uli, bleibt bei der ungarischen Notation, wenn ihr damit zurecht
kommt (und sie wie gesagt einheitlich verwendet!).
Marc
Frank Dzaebel
> > Ansonsten gilt heutzutage offiziell der Link in:
http://groups.google.com/group/microsoft.public.de.german.entwickler.dotnet.csharp/msg/2a61d6ae2c6e06f0
> > Im grossen und ganzen sollte man sich daran halten!
> > Es ist keineswegs egal, wie die Benennung seiner
> > Variablen aussieht, wie hier teilweise gepostet wird.
> >
> Sorry, da muss ich aber mal widersprechen.
Marc, das wurde hier doch schon so oft besprochen,
da hättest Du schon mal aufpassen können.
Du kannst das für Dich alleine gerne machen.
Für das Gro der Entwickler sollten sowohl
die Richtlinien als auch die Empfehlungen
unbedingt beachtet werden. Es ist keineswegs
"egal", wie die Benennung seiner Variablen
aussieht und kann sehr nachteilige Auswirkungen
haben. Dennoch können Firmen, abgestimmt auf
auf verschiedene Anforderungen, die
Konventionen "anpassen" - dies jedoch möglichst
Standard-konform bzgl. den Empfehlungen und
Richtlinien.
Das ist bereits auch in der Spezifikation festgeschrieben:
[Ecma-334*: C# Specification]
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-334.pdf
(Annex C. Namimg Guidlines)
die auch hier zu finden sind:
[Design Guidelines for Class Library Developers]
http://msdn2.microsoft.com/en-us/library/czefa0ke(vs.71).aspx
Thomas hat es auch schon mal ganz gut
zusammengefasst:
> Aussagen wie "sollte nicht verwendet werden", "es wird empfohlen" oder "ist
> schwierig zu lesen" basieren eher auf den subjektiven Einschätzungen des
> Verfassers und sind keinesfalls zu verallgemeinern.
Nein, das sind offizielle Empfehlungen, die Du auch
in anderen offiziellen Büchern und Artikeln findest.
> Was wenn eine andere Firma eine ganz andere Konvention empfiehlt?
Anpassen auf die Firmen-Gegebenheiten, aber möglichst
Standard-konform bzgl. der Empfehlungen.
> 3. Was wenn MS nun nächstes Jahr wieder eine ganz
> andere Notation empfiehlt?
Eine Spezifikation kannst Du schlecht ändern.
Höchstens, wenn es eine neue Sprache gäbe,
da könnte man angepasste Naming-Konventionen
anwenden. Wir sprechen hier aber C#.
> 4. Was ist "falsch" an einer Notation, die von
> der von MS propagierten abweicht?
Wie gesagt, bei Richtlinien-verletzenden Notationen
gäbe es enorme negative Auswirkungen.
Ich kann Dir da beliebig viele Beispiele aufzeigen, die
aber hier ja auch schon öfters publiziert wurden.
> Es ist egal, wie die Benennung seiner Variablen
weit gefehlt. Ich würde Dir empfehlen, da mal
ein bisschen länger drüber nachzudenken und Dich
zu informieren.
Auch mal in die Tiefe gehen, schnell erkennst Du
Situationen, wo die Nichtbeachtung der Konventionen
zu KO-Situationen führt.
Dies also normal vermeiden, indem man gleich die
Standard-Richtlinien und Empfehlungen benutzt.
Ggf. an Firmen-Gegebenheiten (möglichst geringfügig)
Standard-konform anpassen.
Thomas Scheidegger [MVP]
> 2. Wieso die Meinung Microsofts nun plötzlich als weltweite und
> allein-korrekte Richtlinie gelten soll, erschließt sich mir nicht so ganz.
> Was wenn eine andere Firma eine ganz andere Konvention empfiehlt?
Microsoft als Entwickler von C#/.NET hat das Recht & IMHO sogar die Pflicht für Namenskonventionen...
(diese waren übrigens anfangs sogar im ECMA-Standardentwurf, bevor die Verwässerung begann)
Und C# ist nicht C++: C# bringt neue Konzepte & eben auch neue Namenskonventionen.
(C++ Namenskonventionen sind ja auch spät & chaotisch entstanden, sind daher kaum übernehmenswert)
Der Einstieg in C# wäre genau _die_ Chance, mal eine 'Universal-Konvention' konsequent einzuführen.
> 3. Was wenn MS nun nächstes Jahr wieder eine ganz andere Notation empfiehlt?
die Namenskonventionen für C#/.NET sind weitestgehend akzeptiert
und es besteht kein Grund diese nochmals zu ändern.
(langfristig natürlich: ganz andere/neue Sprachen/Konzepte bedeuten ggf neue Namenskonventionen)
> Ich kann mir nicht vorstellen, dass Du z.B. jemals in die Verlegenheit kommen wirst, den
> Code meiner Projekte zu lesen.
Aha!
Die MS-Namenskonvention sind aber insbesondere erst mal genau für das Gegenteil gedacht,
also für Dokumentationen/Schulunterlagen (ala MSDN, Bücher usw), Open-Source
und ausdrücklich für Public-Interfaces von wiederverwendbaren (weiterverkauften) Komponenten.
Wenn ich heute irgend ein C++ OpenSource oder Tutorial usw ansehe,
dann bekomme ich das Würgen von all den Chaoten/Exoten-Namenskonvention (+ auch zB milliardenfache typedefs)
Ich finde daher, Microsoft hat u.a. mit ihren Namenskonvention enorm dafür gesorgt,
dass konformer, 'öffentlicher' C#-Source/APIs extrem hohe Lesbarkeit aufweist.
P.S.:
Findest du es richtig, wenn ein neuer Mitarbeiter bei euch erst
mal auf die Privat-Konvention eurer Firma umgezwungen werden muss?
IMHO sehr fragwürdige/kurzsichtige Praxis....
--
Thomas Scheidegger - MVP .NET - 'NETMaster'
http://www.cetus-links.org/oo_dotnet.html - http://dnetmaster.net/
Herfried K. Wagner [MVP]
Ich benutze In VB6 weiterhin die Präfices 'lbl', 'txt' etc., in .NET
(VB.NET, C#) jedoch '<Typ><Name>', also z.B. 'TextBoxUserName',
'ButtonCancel'. Vorteil davon ist, dass die Namen der Steuerelemente eines
bestimmten Typs in IntelliSense und Objektbrowser schön visuell gruppiert
erscheinen.
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>
Frank Dzaebel
> Ich benutze In VB6 weiterhin die Präfices 'lbl', 'txt' etc., in .NET
> (VB.NET, C#) jedoch '<Typ><Name>', also z.B. 'TextBoxUserName',
> 'ButtonCancel'. Vorteil davon ist, dass die Namen der Steuerelemente eines
> bestimmten Typs in IntelliSense und Objektbrowser schön visuell gruppiert
> erscheinen.
Für VB.NET wäre dasPascalCasing sicher pragmatischer
Kompromiss/Workaround, aber in C# sollte man CamelCasing
für private und protected Variablen nehmen. In C# macht es der
Designer ja auch gleich automatisch gemäss Richtlinie:
Zitat:
"... 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."
[Qualitätssicherung für verwalteten Sourcecode]
http://www.microsoft.com/germany/msdn/library/net/QualitaetssicherungFuerVerwaltetenSourcecode.mspx
Wie Du weisst, nicht nur in diesem Artikel geschrieben.
ciao Frank
--
Dipl.Inf. Frank Dzaebel [MCP/MVP C#]
http://Dzaebel.NET
Carsten Posingies
Füge im Prinzip erstmal die Vokale wieder ein, sodass aus "lbl" "label"
und aus "frm" "form" werden. Ansonsten fährst Du gut damit, wenn Du Dich
an die Vorgaben der IDE hältst. Da sind zwar manche Benamungen von 2003
nach 2005 schwer geändert, aber für neue Anwendungen ist die einfachste
Regel, dass, je weniger Zeichen Du vom vorgeschlagenen Namen änderst,
desto kompatibler bleibst Du. Wenn da also "label1" steht und Du
"labelUser" draus machst, ist das besser, als wenn Du "lblUser" draus
machst oder gar "userLabel" oder "userName".
Zur PascalKonvention und zur camelKonvention hat Frank ja schon genug
gesagt. Im Gegensatz zu ihm bin ich jedoch der Meinung, dass Du in
Deinem Code -- abgestimmt mit anderen Entwicklern am selben Projekt bzw.
basierend auf gruppen-, unternehmens-, vertrags-weiten Konventionen --
im privaten Gültigkeitsbereich machen kannst, was Du willst. Klar ist
"lu" weniger intuitiv als "labelUser", aber wenn es um temporäre
Variablen geht, benutzt Microsoft ja auch "e" statt "eventArgs".
Genau genommen ist die beste Regel eigentlich keine Vorschrift von MS
oder ECMA oder sonstwas, sondern Dein eigener Verstand. Klar ist es
etwas aufwändiger, einmalig "labelUserFirstName" zu tippen, aber danach
ist IntelliSense Dein Freund, und "labelUserFirstName" ist eben
intuitiver als "lblUsrFName", oder? DARUM gehts bei all den Debatten.
"N" war ja zu Zeiten von 32 Kilobytes RAM nicht deswegen Netto, weil es
so logisch war, sondern weil der Speicher knapp war.
Die einzige Ausnahme, die ich hier problemlos zulasse, ist, wenn Du
Datenbank-Spalten auf Formular-Steuerelemente mappen musst. Wenn das
Feld in dBase III nunmal "LSTKANZK" statt "LohnsteuerkarteAnzahlKinder"
heißt, dann sollte ein direkt (!) gemapptes Control auch eben camelCased
"textLstkAnzK" heißen. Was freilich nicht heißt, dass man heute so
entwickelt. Aber wenn, dann eben dann schon. =D
Carsten
Herfried K. Wagner [MVP]
"Frank Dzaebel" <Po...@FranksSeite.de> schrieb:
>> Ich benutze In VB6 weiterhin die Präfices 'lbl', 'txt' etc., in .NET
>> (VB.NET, C#) jedoch '<Typ><Name>', also z.B. 'TextBoxUserName',
>> 'ButtonCancel'. Vorteil davon ist, dass die Namen der Steuerelemente
>> eines bestimmten Typs in IntelliSense und Objektbrowser schön visuell
>> gruppiert erscheinen.
>
> Für VB.NET wäre dasPascalCasing sicher pragmatischer
> Kompromiss/Workaround, aber in C# sollte man CamelCasing
> für private und protected Variablen nehmen. In C# macht es der
> Designer ja auch gleich automatisch gemäss Richtlinie:
Nochmals: Meine Ansicht zu dieser Richtlinie, die keine ist, kennst du
schon.
Frank Dzaebel
>> ... In C# macht es der Designer ja auch gleich automatisch gemäss
>> Richtlinie...
>
> ... meine Ansicht zu dieser Richtlinie ...
Es geht nicht um Ansichten, sondern um Fakten,
die jeder nachlesen kann.
Mark Doerbandt
Frank Dzaebel:
> die jeder nachlesen kann.
aktueller ist
http://msdn2.microsoft.com/en-us/library/ms229043.aspx
Gruss - Mark
Frank Dzaebel
>> die jeder nachlesen kann.
> aktueller ist
> http://msdn2.microsoft.com/en-us/library/ms229043.aspx
Du meintest bzgl. meinem ECMA-Link. Ja, das
war nur, um zu zeigen, dass die Namenkonventionen
bereits in der C# Spezifikation standen.
Da die Gruppe deutsch ist, erlaube ich mir mal
noch die deutsche Referenz zu zitieren:
[Entwurfsrichtlinien zum Entwickeln von Klassenbibliotheken]
http://msdn2.microsoft.com/de-de/library/ms229042(VS.80).aspx
Also wichtig dazu, dieser Teil gilt offiziell nur für
die Benennung von Klassenbibliotheks-Membern und Typen.
Marc Weichhold
> Marc, das wurde hier doch schon so oft besprochen,
> da hättest Du schon mal aufpassen können.
>
Nur weil ich mich bisher nicht an den Diskussionen bezüglich dieses Themas
beteiligt habe, bedeutet das nicht, dass ich sie nicht verfolgt habe, oder
dass ich - weil ich eben nicht widersprochen habe - die Meinung dieser
Ratgeber vertrete. Ich finde diese Annahme von Dir ganz schon anmaßend.
> Du kannst das für Dich alleine gerne machen.
> Für das Gro der Entwickler sollten sowohl
> die Richtlinien als auch die Empfehlungen
> unbedingt beachtet werden.
>
Ich glaube- offensichtlich im Gegensatz zu Dir -, dass die Mehrheit der
Entwickler Software entwickelt, die nicht publiziert wird. Somit wird deren
Code niemals außerhalb des Projektrahmens gesehen werden und somit ist eine
globale Namenskonvention für eine Programmiersprache nicht zwingend
notwendig. Vielleicht ist diese Einschätzung falsch von mir, vielleicht aber
auch nicht.
> Es ist keineswegs
> "egal", wie die Benennung seiner Variablen
> aussieht und kann sehr nachteilige Auswirkungen
> haben.
>
Das sehe ich eben nicht so. Die nachteiligen Auswirkungen betreffen im
Großen und Ganzen nur Code, der von anderen, nicht am Projekt beteiligten
Leuten gelesen wird. "Sehr" nachteilig halte ich die Auswirkungen auch für
diese Fälle nicht.
> Dennoch können Firmen, abgestimmt auf
> auf verschiedene Anforderungen, die
> Konventionen "anpassen" - dies jedoch möglichst
> Standard-konform bzgl. den Empfehlungen und
> Richtlinien.
>
> Das ist bereits auch in der Spezifikation festgeschrieben:
>
> [Ecma-334*: C# Specification]
> http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-334.pdf
> (Annex C. Namimg Guidlines)
> die auch hier zu finden sind:
>
> [Design Guidelines for Class Library Developers]
> http://msdn2.microsoft.com/en-us/library/czefa0ke(vs.71).aspx
>
> Thomas hat es auch schon mal ganz gut
> zusammengefasst:
>
> http://groups.google.com/group/microsoft.public.de.german.entwickler.dotnet.csharp/msg/eba7bc00f40b4ee6
>
Ich halte es grundsätzlich für fragwürdig, eine funktionierende Konvention
wegzuwerfen, nur weil eine neue Sprache entwickelt wird. Du willst mir noch
nicht erzählen, dass wenn Du in einem C#-Code m_nMaximum liest, dass es Dir
Schwierigkeiten bereitet, diese Variable zu deuten, oder? Es geht mir aber
nicht unbedingt um die Ungarische Notation, sie sollte hier nur als Beispiel
dienen, weil sie weit verbreitet ist und die Wahrscheinlichkeit hoch ist,
dass Du sie kennst.
Mit anderen Worten, wärst Du in unserem Projektteam und würdest Du unsere
Notation kennen, würde es Dir keine Schwierigkeiten bereiten, den Code
schnell und einfach zu verstehen. Um nichts anderes geht es mir.
> Nein, das sind offizielle Empfehlungen, die Du auch
> in anderen offiziellen Büchern und Artikeln findest.
>
Eine offizielle Empfehlung mag das schon sein. Aber Empfehlungen basieren
nun mal auf subjektiven Einschätzungen von einer oder mehreren Personen. Und
diese Einschätzung teile ich ganz und gar nicht.
>> Was wenn eine andere Firma eine ganz andere Konvention empfiehlt?
>
> Anpassen auf die Firmen-Gegebenheiten, aber möglichst
> Standard-konform bzgl. der Empfehlungen.
>
Das meine ich nicht. Nehmen wir mal an, Firma X entwickelt C# (Compiler,
Linker, IDE, alles was dazu gehört) für Linux. Firma X spricht nun bezüglich
der Namenskonvention eine Empfehlung aus, die der Empfehlung von MS komplett
widerspricht. Was dann? benutzt man dann also für C# unter Windows die
MS-Konvention und für C# unter Linux die X-konvention? Das wäre ja wohl
Schwachsinn, vor allem vor dem Hintergrund von portierbarem Code.
> Eine Spezifikation kannst Du schlecht ändern.
> Höchstens, wenn es eine neue Sprache gäbe,
> da könnte man angepasste Naming-Konventionen
> anwenden. Wir sprechen hier aber C#.
>
Vielleicht ist das das Problem. Ich sehe eine Namenskonvention ganz und gar
nicht an eine Sprache gebunden. Insofern erschließt sich mir - wie erwähnt -
auch der Sinn nicht, für eine neue Sprache eine komplett neue
Namenskonvention zu "erfinden". Wir benutzen die ungarische Notation für
unsere VC++- und C#-Projekte und auch für VB-, Java- und Python-Scripts.
Vollkommen sprachunabhängig. Und welch Wunder, es funktioniert. Es
funktioniert sogar ausgesprochen gut.
> Wie gesagt, bei Richtlinien-verletzenden Notationen
> gäbe es enorme negative Auswirkungen.
> Ich kann Dir da beliebig viele Beispiele aufzeigen, die
> aber hier ja auch schon öfters publiziert wurden.
>
Jede Sache hat zwei Seiten. Und ich finde erstens die negativen Dinge bei
weitem nicht so schlimm wie sie hier dargestellt werden (es handelt sich
dabei oftmals eh nur um akademische und rein hypothetische Beispiele, fern
jeglicher Realität) und zweitens bin ich der Meinung, dass die positiven
Dinge überwiegen.
>
>> Es ist egal, wie die Benennung seiner Variablen
>
> weit gefehlt. Ich würde Dir empfehlen, da mal
> ein bisschen länger drüber nachzudenken und Dich
> zu informieren.
> Auch mal in die Tiefe gehen, schnell erkennst Du
> Situationen, wo die Nichtbeachtung der Konventionen
> zu KO-Situationen führt.
>
Erneut muss ich Dich darauf hinweisen, dass Du ab und an sehr anmaßend und
von oben herab bist. Nur weil jemand eine andere Meinung vertritt wie Du,
bedeutet das nicht, dass er nicht ausreichend informiert ist. Ich bewerte
und gewichte die Fakten eben einfach anders als Du.
Ich hatte eigentlich auch nicht vor, hier einen weiteren Glaubenskrieg zu
entfachen. Aber wenn ich lese, dass behauptet wird, eine Sache sei die
allein-seeligmachende und einzig richtige und wahre Sache, dann nimmt das
schon fast religiöse Züge an und da kann es mich schon mal überkommen,
meinen Senf dazu zu geben.
Also zu guter Letzt: ich möchte hier nicht behaupten, dass die "offizielle"
Konvention falsch ist oder schlecht oder was weiss ich was. Wer auf der
Suche nach einer neuen Konvention ist, weil er der Meinung ist, seine
bisherige sei nicht gut genug oder passt nicht zu den Anforderungen, der
kann sich ja durchaus an die offizielle Konvention halten. Aber ich bin
davon überzeugt, dass eine Namenskonvention sprachunabhängig sein kann und
soll und wenn man eine solche Namenskonvention gefunden hat, dann ist der
Gebrauch einer neuen Sprache für mich ganz und gar kein Grund, von dieser
Namenskonvention abzuweichen.
Wenn also Uli (OP) bisher mit der ungarischen Notation zurecht kam und sie
zu den anstehenden Anforderungen passt, dann kann ich ihm nur empfehlen, bei
seiner bisherigen Notation zu bleiben. Sie ist nicht falsch und nicht
weniger gut als die "offizielle" Konvention. Und am Ende nochmal meine
wichtigste Aussage: Wichtiger als die Frage WELCHE Konvention in einem Team
benutzt wird, ist die Notwendigkeit, dass ALLE DIESELBE Konvention benutzen.
Marc
Marc Weichhold
> Microsoft als Entwickler von C#/.NET hat das Recht & IMHO sogar die
> Pflicht für Namenskonventionen...
>
Natürlich hat MS das Recht, eine neue Namenskonvention zu entwicklen. Die
Pflicht...? Naja, da kann man geteilter Meinung sein. Wie Du in meiner
Antwort an Frank lesen kannst, bin ich der Meinung, eine gute
Namenskonvention ist sprachunabhängig. Insofern sehe ich die Pflicht nicht,
aber egal.
Wozu MS allerdings meiner Meinung nach KEIN Recht hat, ist diese
Namenskonvention als die einzig richtige (für C#) zu verkaufen.
> Die MS-Namenskonvention sind aber insbesondere erst mal genau für das
> Gegenteil gedacht,
> also für Dokumentationen/Schulunterlagen (ala MSDN, Bücher usw),
> Open-Source
> und ausdrücklich für Public-Interfaces von wiederverwendbaren
> (weiterverkauften) Komponenten.
>
> Wenn ich heute irgend ein C++ OpenSource oder Tutorial usw ansehe,
> dann bekomme ich das Würgen von all den Chaoten/Exoten-Namenskonvention (+
> auch zB milliardenfache typedefs)
> Ich finde daher, Microsoft hat u.a. mit ihren Namenskonvention enorm dafür
> gesorgt,
> dass konformer, 'öffentlicher' C#-Source/APIs extrem hohe Lesbarkeit
> aufweist.
>
Bitte, bitte, von mir aus kann für die Publikation ja auch die MS-Konvention
benutzt werden. Aber ich glaube, dass dies den geringsten Teil des weltweit
produzierten Codes ausmacht. Und in einem (geschlossenen) Projekt ist eben
nicht wichtig, welche Notation man benutzt, sondern dass alle dieselbe
benutzen.
> Findest du es richtig, wenn ein neuer Mitarbeiter bei euch erst
> mal auf die Privat-Konvention eurer Firma umgezwungen werden muss?
> IMHO sehr fragwürdige/kurzsichtige Praxis....
>
Gegenfrage: Findest Du es besser, sich für jede Sprache an eine andere
Konvention zu gewöhnen? Bei uns wird VC++, C# als Programmiersprache und
VB.NET, Java und Python als Scriptsprache eingesetzt und wir benutzen für
ALLE Sprachen DIESELBE Konvention. Das vereinfacht die Dinge ungemein.
Damit beantworte ich Deine Frage auch: Ja, ich finde es richtig, wenn sich
der neue Mitarbeiter umgewöhnt und sich dem Stil des Teams anpasst.
Marc
Coder2001
nachdem ich mir eure Meinungen angesehen habe, neige ich dazu, mich Carsten
anzuschließen.: label1 => labelUser.
Ich werde, sobald ich Zeit habe, mir mal ECMA-334 genauer anschauen.
Carsten Posingies
> Ich hatte eigentlich auch nicht vor, hier einen weiteren
> Glaubenskrieg zu entfachen. Aber wenn ich lese, dass behauptet wird,
> eine Sache sei die allein-seeligmachende und einzig richtige und
> wahre Sache, dann nimmt das schon fast religiöse Züge an und da kann
> es mich schon mal überkommen, meinen Senf dazu zu geben.
>
> Also zu guter Letzt: ich möchte hier nicht behaupten, dass die
> "offizielle" Konvention falsch ist oder schlecht oder was weiss ich
> was. Wer auf der Suche nach einer neuen Konvention ist, weil er der
> Meinung ist, seine bisherige sei nicht gut genug oder passt nicht zu
> den Anforderungen, der kann sich ja durchaus an die offizielle
> Konvention halten. Aber ich bin davon überzeugt, dass eine
> Namenskonvention sprachunabhängig sein kann und soll und wenn man
> eine solche Namenskonvention gefunden hat, dann ist der Gebrauch
> einer neuen Sprache für mich ganz und gar kein Grund, von dieser
> Namenskonvention abzuweichen.
Dem kann ich erstmal nur zustimmen. Die Frage ist aber doch eigentlich,
ob die neue Konvention, die MS für C# vorschlägt/-schreibt, besser ist
als Ungarisch, und zwar in der Tat sprachunabhängig.
Wenn Du Sourcen mit dem Notepad / vi / ed schreibst, ist klar, dass es
Dir lästig wird, "toolbarButtonOptionsActivateScanForNewFiles" zu tippen
statt einfach "btnScanYes". Aber Dank IntelliSense und Verwandten sowie
Plattenplatz, der auf den Terabyte-Bereich zusteuert, sehe ich keinen
Grund, Akronyme und Mnemonics zu benutzen. Sprich: je klarer,
einleuchtender, umgangssprachlicher eine Bezeichnung für eine Methode,
Eigenschaft etc. ist, desto besser.
Bei Deiner Argumentation, dass die meiste Software nicht in die
allgemeine Öffentlichkeit gelangt, also als Source, hast Du zweifellos
recht. Zwei Punkte sprechen jedoch meiner Ansicht nach dagegen, dies als
Argument für beliebige Namenskonventionen zu sehen. Erstens, das ist
weniger triftig, kannst Du Deinen Code flott per Copy & Paste in eine
Newsgroup stellen, wenn Du was fragen willst, und jeder versteht ihn.
Zweitens, ähnlich, aber ungleich wichtiger: neue Mitarbeiter am Projekt
blicken schneller durch, weil die Namenskonvention intuitiv ist statt an
ein kryptisches Schema gebunden.
Ich verweise hier mal auf jemanden, der vermutlich noch niemals eine
einzige Zeile Software geschrieben hat, aber eine Menge Ahnung hat, was
Verständnis von Text betrifft, nämlich Wolf Schneider. Dessen Credo (für
Journalisten) ist: Wenn einer schreibt und zehn lesen, hat sich der eine
anzustrengen, verständlich zu sein, nicht die die zehn, zu verstehen.
liGrue,
Carsten
Carsten Posingies
> Wozu MS allerdings meiner Meinung nach KEIN Recht hat, ist diese
> Namenskonvention als die einzig richtige (für C#) zu verkaufen.
Aber doch, nämlich genau dann, wenn sie es ist. Ich würde es anders
formulieren. MS behauptet nämlich nicht, dass deren NK die einzig wahre
ist, aber doch die aktuell verständlichste (intuitivste).
private void fncAVat(double fA, double fV)
{
return fA + fV;
}
v/s
private void AddVatToAmount(double amount, double vat)
{
return amount + vat;
}
Nun?
Frank Dzaebel
> Ich glaube- offensichtlich im Gegensatz zu Dir -, dass die Mehrheit der
> Entwickler Software entwickelt, die nicht publiziert wird. Somit wird
> deren Code niemals außerhalb des Projektrahmens gesehen werden und somit
> ist eine globale Namenskonvention für eine Programmiersprache nicht
> zwingend notwendig. Vielleicht ist diese Einschätzung falsch von mir,
> vielleicht aber auch nicht.
Da liegst Du wirklich falsch.
Nur mal ein Beispiel (von vielen), wenn Du z.B. eine
Klassenbibliothek (innerhalb Deines Projektes) erstellst,
so musst Du bzw. die CaseInsentivität-Benennungs-Richtlinie
beachten, da sonst z.B. andere .NET-Sprachen diese
DLL gar nicht einbinden können. Man würde sich ohne
Not übelste Inkompatibilitäten einhandeln.
>> Marc, das wurde hier doch schon so oft besprochen,
>> da hättest Du schon mal aufpassen können.
>>
> Nur weil ich mich bisher nicht an den Diskussionen bezüglich dieses Themas
> beteiligt habe, bedeutet das nicht, dass ich sie nicht verfolgt habe, oder
> dass ich - weil ich eben nicht widersprochen habe - die Meinung dieser
> Ratgeber vertrete. Ich finde diese Annahme von Dir ganz schon anmaßend.
Marc, Du solltest Dich an die Nettiquette halten und Dich vorher rudimentär
über die Gegebenheiten/Fakten informieren. Zum Beispiel durch Suche in der
Gruppe. Wer das nicht tut, muss sich schon mal deutlichere Hinweise darauf
gefallen lassen. Den ECMA-Link z.B. immer und immer wieder zu wiederholen
macht keinen Spass (zumindest für mich), denn es bringt die Gruppe so nicht
weiter (Schnee von gestern).
Gerade bei so "abstrusen" Ansichten, man müsse
"jede Sprache mit einer einzigen Namenskonvention zu codieren".
(mal abgesehen davon, dass das syntaktisch schon gar nicht möglich wäre).
sehe ich, dass man da ganz von vorne anfangen muss.
Z.B. "was ist der Sinn von Klassenbibliotheken"?
"Welche Vorteile hat man durch MSIL"?
Vielleicht mag ich Dir etwas streng in der Formulierung vorkommen,
aber ich denke, Du hast mehr davon, ich sage Dir das hier ohne Schnörkel.
Gehe ruhig noch mal zu den Grundlagen zurück, Du wirst selber erkennen,
dass solche Richtlinien kaum anders sein können/sollten.
> Ich halte es grundsätzlich für fragwürdig, eine funktionierende Konvention
> wegzuwerfen, nur weil eine neue Sprache entwickelt wird.
Verwalteter Code ist etwas anderes als unverwalteter.
Verstehe zuerst mal die Grundlagen und gehe von da
weiter, erst dann wirst Du erkennen, wie logisch und
wichtig die Richtlinien sind. Ich glaube nicht, dass ich
Dir das Wissen in disem Thread vermitteln kann.
> Mit anderen Worten, wärst Du in unserem Projektteam und würdest Du unsere
> Notation kennen, würde es Dir keine Schwierigkeiten bereiten, den Code
> schnell und einfach zu verstehen. Um nichts anderes geht es mir.
Ja, und - was Du sicher selber kennst und was schlimmer ist - ein
Gefühl wie, als wenn ich etwas angegammeltes esse.
>> Nein, das sind offizielle Empfehlungen, die Du auch
>> in anderen offiziellen Büchern und Artikeln findest.
>>
> Eine offizielle Empfehlung mag das schon sein. Aber Empfehlungen basieren
> nun mal auf subjektiven Einschätzungen von einer oder mehreren Personen.
> Und diese Einschätzung teile ich ganz und gar nicht.
Letztlich entwickelt das keine einzelne subjektive Person,
sondern ganze Teams, bei denen jeder einzelne Spezialist ist,
und höchstwahrscheinlich mehr diesbzgl. drauf hat, als wir zwei beiden.
Was ich so von den MSlern mitbekomme, und ich deutlich näher
dran, die nehmen sich wirklich extrem gute Leute an die Hand und
habe da schon Respekt vor deren Leistungen - und das nun wahrlich
nicht rein subjektiv.
>>> Was wenn eine andere Firma eine ganz andere Konvention empfiehlt?
>>
>> Anpassen auf die Firmen-Gegebenheiten, aber möglichst
>> Standard-konform bzgl. der Empfehlungen.
>>
> Das meine ich nicht. Nehmen wir mal an, Firma X entwickelt C# (Compiler,
> Linker, IDE, alles was dazu gehört) für Linux. Firma X spricht nun
> bezüglich der Namenskonvention eine Empfehlung aus, die der Empfehlung von
> MS komplett widerspricht. Was dann? benutzt man dann also für C# unter
> Windows die MS-Konvention und für C# unter Linux die X-konvention? Das
> wäre ja wohl Schwachsinn, vor allem vor dem Hintergrund von portierbarem
> Code.
Es gilt immer die C# Spezifikation. Egal was für Firmen sich an was
auch immer versuchen.
>> Eine Spezifikation kannst Du schlecht ändern.
>> Höchstens, wenn es eine neue Sprache gäbe,
>> da könnte man angepasste Naming-Konventionen
>> anwenden. Wir sprechen hier aber C#.
>>
> Vielleicht ist das das Problem. Ich sehe eine Namenskonvention ganz und
> gar nicht an eine Sprache gebunden. Insofern erschließt sich mir - wie
> erwähnt - auch der Sinn nicht, für eine neue Sprache eine komplett neue
> Namenskonvention zu "erfinden". Wir benutzen die ungarische Notation für
> unsere VC++- und C#-Projekte und auch für VB-, Java- und Python-Scripts.
> Vollkommen sprachunabhängig. Und welch Wunder, es funktioniert. Es
> funktioniert sogar ausgesprochen gut.
Es gibt Richtlinien und Empfehlungen. Richtlinien sind
in der C# Spec festgeschrieben, ob Du es so siehst oder nicht.
Gegen Richtlinien zu verstossen, hat meist schon in kleinen
Projekten spürbare negative Auswirkungen. Bei Empfehlungen
ist das nicht immer so.
>> Wie gesagt, bei Richtlinien-verletzenden Notationen
>> gäbe es enorme negative Auswirkungen.
>> Ich kann Dir da beliebig viele Beispiele aufzeigen, die
>> aber hier ja auch schon öfters publiziert wurden.
>>
> Jede Sache hat zwei Seiten. Und ich finde erstens die negativen Dinge bei
> weitem nicht so schlimm wie sie hier dargestellt werden (es handelt sich
> dabei oftmals eh nur um akademische und rein hypothetische Beispiele, fern
> jeglicher Realität) und zweitens bin ich der Meinung, dass die positiven
> Dinge überwiegen.
Du hast meine Hinweise gelesen. Ich bin nun schon sehr lange
im Software-Geschäft und gerade im .NET Bereich schon lange
spezialisiert. Vielleicht nimmst Du's einfach als gut gemeinten Ratschlag.
Seine Erfahrungen muss man ja manchmal selber machen.
> Ich hatte eigentlich auch nicht vor, hier einen weiteren Glaubenskrieg zu
> entfachen. Aber wenn ich lese, dass behauptet wird, eine Sache sei die
> allein-seeligmachende und einzig richtige und wahre Sache, dann nimmt das
> schon fast religiöse Züge an und da kann es mich schon mal überkommen,
> meinen Senf dazu zu geben.
Da hättest Du recht, wenn das so behauptet werden würde.
Hat aber IMHO niemand.
Ich habe ja öfter mit den MS-Koryphäen bzgl. Namenskonventionen
gesprochen. Empfehlungen wollen sie nicht so sehen, dass sich
Entwickler hier dogmatisch hineingezwungen fühlen. Ist aber alles schon
von mir hier in der NG öfter publiziert worden ...
MS meint hier, es gibt viele Gründe, warum die eine oder
andere Empfehlung nicht benutzt werden muss.
> Wichtiger als die Frage WELCHE Konvention in einem Team benutzt wird, ist
> die Notwendigkeit, dass ALLE DIESELBE Konvention benutzen.
Nein, das siehst Du wieder zu kurz/dogmatisch.
Du musst bedenken, dass immer andere Entwickler hinzukommen
können. Deine Firma ist zum Scheitern verurteilt, wenn sie
nicht in der Lage ist, sich zu entwickeln.
Thomas Scheidegger [MVP]
> Konvention zu gewöhnen?
vergleiche dies (annähernd) mit dem Duden.
Dessen Regeln sind für Deutsch weitestgehend amtlich-verbindlich.
Aber für zB Englisch völlig irrelevant.
Was wäre wenn jede Stadt ihre eigene Duden-Variante hätte?
Chaos Pur. Punkt.
Mein Grundsatz entsprechend für Programmiersprachen:
eine Namenskonventionen braucht eine gewisse Masse/Verbreitung/Akzeptanz und starke Förderung (eben zB durch MS),
um überhaupt als 'Konvention' ernst genommen zu werden.
Ein andere/abweichende 'Konvention' pro Firma ist schlicht absurd.
Carsten Posingies
> nachdem ich mir eure Meinungen angesehen habe, neige ich dazu, mich
> Carsten anzuschließen.: label1 => labelUser.
Danke Dir für Deine Zustimmung für meine Meinung, zumal sie ja teilweise
doch von der der Koryphäen wie Frank, Herfried und Thomas teilweise
(marginal, aber immerhin) abweicht. Ich möchte nur noch eine Kleinigkeit
ergänzen.
Hin und wieder kommt es ja vor, dass man ein Steuerelement anders
benutzt als so, wie es die Erfinder vorgesehen haben. Da würde ich
höchst dogmatisch immer empfehlen, das Steuerelement in ein
Benutzer-Steuerelement abzuleiten, auch wenn Du gar nichts an der
Funktionalität änderst. Beispielsweise könntest Du auf die Idee kommen
(warum auch immer), ein Image als grafischen Link benutzen zu wollen.
Dann beerbe das Image zu einem ImageLink-Steuerelement oder so ähnlich,
statt aus "image1" plötzlich "graphicalImageHelpLink" zu machen. Ganz
abgesehen davon, dass man ja eigentlich beim GUI-Design sowieso, wenn
man puristisch an die Sache heran geht, kaum ein Steuerelement (bis auf
Labels und Buttons vielleicht) unvererbt lässt, also in seiner
Originalform anwendet. Aber das ist eine andere Geschichte und soll ein
anderes Mal erzählt werden :)
Carsten
Herfried K. Wagner [MVP]
"Marc Weichhold" <sp...@mailfolder.de> schrieb:
> Gegenfrage: Findest Du es besser, sich für jede Sprache an eine andere
> Konvention zu gewöhnen? Bei uns wird VC++, C# als Programmiersprache und
> VB.NET, Java und Python als Scriptsprache eingesetzt und wir benutzen für
> ALLE Sprachen DIESELBE Konvention. Das vereinfacht die Dinge ungemein.
Ich halte eine generische Konvention für eher unsinnig. Schon alleine
aufgrund unterschiedlicher Konzepte sind unterschiedliche
Benennungskonventionen sinnvoll. Wenn keine strenge Typisierung oder spätes
Binden benutzt wird, dann ist es evtl. sinnvoll, Typpräfices zu nutzen (wie
in VB6 oft üblich), in einer streng typisierten Umgebung bringt dies jedoch
keinen Mehrwert.
Marc Weichhold
> {
> return fA + fV;
> }
>
> v/s
>
> private void AddVatToAmount(double amount, double vat)
> {
> return amount + vat;
> }
>
> Nun?
Meinung ist, es passe zum Stil seines Teams, dann verdamme ich das nicht.
Und letztendlich könnte ich es auch "lesen" wenn er den Code posten würde.
Vergleiche Dein zweites Beispiel mit unserer Konvention:
private void AddVatToAmount(double p_dAmount, double p_dVat)
{
return p_dAmount + p_dVat;
}
Nun?
Nochmal: es geht mir nicht darum zu behaupten, eine NK sei besser als die
andere. Ich behaupte gerade das Gegenteil und auch wenn Frank
anmaßenderweise der Meinung ist, meine Erfahrung in der Software sei
geringer als seine, diese NK funktioniert bei uns seit Jahren und neue
Entwickler haben gar keine Probleme damit, sich einzugewöhnen. Ganz im
Gegenteil, es wird - auch und gerade von den "Neuen" - als großer Vorteil
angesehen, dass diese NK in ALLEN von uns verwendeten Sprachen benutzt wird.
Marc
Marc Weichhold
> Dessen Regeln sind für Deutsch weitestgehend amtlich-verbindlich.
> Aber für zB Englisch völlig irrelevant.
> Was wäre wenn jede Stadt ihre eigene Duden-Variante hätte?
> Chaos Pur. Punkt.
>
eine Firma produziert, publik gemacht würde. Ich behaupte mal weiterhin,
dass die große Mehrheit der Softwarefirmen ihr Kapital (nachlich den
produzierten Code) mit enormem Sicherheitsaufwand unter Verschluß hält. Ein
Chaos entsteht also garantiert nicht, wenn eine Firma Konvention X und die
andere Firma Konvention Y benutzt.
> Mein Grundsatz entsprechend für Programmiersprachen:
> eine Namenskonventionen braucht eine gewisse Masse/Verbreitung/Akzeptanz
> und starke Förderung (eben zB durch MS),
> um überhaupt als 'Konvention' ernst genommen zu werden.
> Ein andere/abweichende 'Konvention' pro Firma ist schlicht absurd.
>
Ich nehme Dir ja Deine Meinung nicht. Im Gegensatz zu Dir ("absurd")
respektiere ich sie sogar. Werd' glücklich mit der "offiziellen" Konvention.
Aber diese Aburteilung von abweichenden Meinungen und der Glaube, die einzig
wahre NK zu benutzen, finde ich echt sehr arrogant. Erinnert mich irgendwie
ganz entfernt an die Inquisition im MA.
Marc
Thomas Schremser
"Marc Weichhold" <sp...@mailfolder.de> schrieb:
> > vergleiche dies (annähernd) mit dem Duden.
> > Dessen Regeln sind für Deutsch weitestgehend amtlich-verbindlich.
> > Aber für zB Englisch völlig irrelevant.
> > Was wäre wenn jede Stadt ihre eigene Duden-Variante hätte?
> > Chaos Pur. Punkt.
> >
> Sorry, aber der Vergleich hinkt. Denn das würde bedeuten, dass der Code, den
> eine Firma produziert, publik gemacht würde. Ich behaupte mal weiterhin,
> dass die große Mehrheit der Softwarefirmen ihr Kapital (nachlich den
> produzierten Code) mit enormem Sicherheitsaufwand unter Verschluß hält. Ein
> Chaos entsteht also garantiert nicht, wenn eine Firma Konvention X und die
> andere Firma Konvention Y benutzt.
Das wiederum gilt nur für Firmen, die "Standard-Software" erstellen. Wir
setzen hier in unserem Haus auch viele Anwendungen ein, die verschiedene
Firmen für uns im Auftrag erstellt haben und deren Code uns daher übergeben
wurde. Als Inhouse-Programmierer muß ich gelegentlich Anpassungen an solchen
Anwendungen vornehmen und wäre froh, wenn nicht jede Firma ihre eigenen
Konventionen verwenden würde.
Grüße
Thomas
--
Any problem in computer science can be solved with another layer
of indirection. But that usually will create another problem.
David Wheeler
Marc Weichhold
>> Ich glaube- offensichtlich im Gegensatz zu Dir -, dass die Mehrheit der
>> Entwickler Software entwickelt, die nicht publiziert wird. Somit wird
>> deren Code niemals außerhalb des Projektrahmens gesehen werden und somit
>> ist eine globale Namenskonvention für eine Programmiersprache nicht
>> zwingend notwendig. Vielleicht ist diese Einschätzung falsch von mir,
>> vielleicht aber auch nicht.
>
> Da liegst Du wirklich falsch.
> Nur mal ein Beispiel (von vielen), wenn Du z.B. eine
> Klassenbibliothek (innerhalb Deines Projektes) erstellst,
> so musst Du bzw. die CaseInsentivität-Benennungs-Richtlinie
> beachten, da sonst z.B. andere .NET-Sprachen diese
> DLL gar nicht einbinden können. Man würde sich ohne
> Not übelste Inkompatibilitäten einhandeln.
>
schlechter als andere. Die CaseInsentivität-Benennungs-Richtlinie gab es
auch schon vor C# in der Ungarischen Notation, sie ist also keineswegs neu
und sie ist selbstverständlich auch Teil unserer Konvention.
Ich bestreite auch nicht, dass manche Teile der "offiziellen" NK sinnvoll
und wichtig sind. Sie in ihrer Gänze als die einzig wahre anzusehen, das
bestreite ich.
>> Nur weil ich mich bisher nicht an den Diskussionen bezüglich dieses
>> Themas beteiligt habe, bedeutet das nicht, dass ich sie nicht verfolgt
>> habe, oder dass ich - weil ich eben nicht widersprochen habe - die
>> Meinung dieser Ratgeber vertrete. Ich finde diese Annahme von Dir ganz
>> schon anmaßend.
>
> Marc, Du solltest Dich an die Nettiquette halten und Dich vorher
> rudimentär über die Gegebenheiten/Fakten informieren. Zum Beispiel durch
> Suche in der Gruppe. Wer das nicht tut, muss sich schon mal deutlichere
> Hinweise darauf gefallen lassen. Den ECMA-Link z.B. immer und immer wieder
> zu wiederholen macht keinen Spass (zumindest für mich), denn es bringt die
> Gruppe so nicht weiter (Schnee von gestern).
>
Ich weiss nicht, wie Du auf die Idee kommst, ich hätte mich nicht
ausreichend informiert. Nur weil meine Meinung eine andere ist? Vielleicht
solltest Du Dich selbst an die Nettiquette halten und akzeptieren, dass
andere Leute auch andere Meinungen haben können. Und Werkzeuge benutzen, die
für ihre Prozesse seit Jahren mehr als gut funktionieren.
> Gerade bei so "abstrusen" Ansichten, man müsse
> "jede Sprache mit einer einzigen Namenskonvention zu codieren".
> (mal abgesehen davon, dass das syntaktisch schon gar nicht möglich wäre).
> sehe ich, dass man da ganz von vorne anfangen muss.
> Z.B. "was ist der Sinn von Klassenbibliotheken"?
> "Welche Vorteile hat man durch MSIL"?
>
Ich hatte vorher mehr als deutlich gesagt, dass es mir nicht um Code geht,
der auf irgendeine Art und Weise veröffentlicht wird. Dies schließt
Klassenbibliotheken natürlich ein. Außerdem reden wir von der/den
Hochsprache(n), nicht von der MSIL (im Übrigen inzwischen CIL, wenn Du schon
so viel Wert auf ECMA-Konventionen legst). MSIL-Code werden nur die
wenigsten .NET-Programmierer direkt erzeugen, lesen (müssen) oder ändern.
> Vielleicht mag ich Dir etwas streng in der Formulierung vorkommen,
> aber ich denke, Du hast mehr davon, ich sage Dir das hier ohne Schnörkel.
> Gehe ruhig noch mal zu den Grundlagen zurück, Du wirst selber erkennen,
> dass solche Richtlinien kaum anders sein können/sollten.
>
Ich habe das nie bestritten. Ich weiß nicht, drücke ich mich so undeutlich
aus?
>> Ich halte es grundsätzlich für fragwürdig, eine funktionierende
>> Konvention wegzuwerfen, nur weil eine neue Sprache entwickelt wird.
>
> Verwalteter Code ist etwas anderes als unverwalteter.
> Verstehe zuerst mal die Grundlagen und gehe von da
> weiter, erst dann wirst Du erkennen, wie logisch und
> wichtig die Richtlinien sind. Ich glaube nicht, dass ich
> Dir das Wissen in disem Thread vermitteln kann.
>
Ich hoffe, dass ich Dir noch vermitteln kann, mit welcher Arroganz und mit
wie wenig Argumenten Du hier diskutierst. Ich glaube kaum, dass Du Dir ein
Urteil darüber erlauben kannst, ob ich die Grundlagen von managed und
unmanaged Code kenne oder nicht.
>> Mit anderen Worten, wärst Du in unserem Projektteam und würdest Du unsere
>> Notation kennen, würde es Dir keine Schwierigkeiten bereiten, den Code
>> schnell und einfach zu verstehen. Um nichts anderes geht es mir.
>
> Ja, und - was Du sicher selber kennst und was schlimmer ist - ein
> Gefühl wie, als wenn ich etwas angegammeltes esse.
>
Also ein sehr subjektives Gefühl. Wie ich gesagt habe.
>> Eine offizielle Empfehlung mag das schon sein. Aber Empfehlungen basieren
>> nun mal auf subjektiven Einschätzungen von einer oder mehreren Personen.
>> Und diese Einschätzung teile ich ganz und gar nicht.
>
> Letztlich entwickelt das keine einzelne subjektive Person,
> sondern ganze Teams, bei denen jeder einzelne Spezialist ist,
> und höchstwahrscheinlich mehr diesbzgl. drauf hat, als wir zwei beiden.
> Was ich so von den MSlern mitbekomme, und ich deutlich näher
> dran, die nehmen sich wirklich extrem gute Leute an die Hand und
> habe da schon Respekt vor deren Leistungen - und das nun wahrlich
> nicht rein subjektiv.
>
Solange Menschen an solchen Entscheidungen beteiligt sind, ist das Ergebnis
immer ein Stück weit subjektiv.
>
>> Das meine ich nicht. Nehmen wir mal an, Firma X entwickelt C# (Compiler,
>> Linker, IDE, alles was dazu gehört) für Linux. Firma X spricht nun
>> bezüglich der Namenskonvention eine Empfehlung aus, die der Empfehlung
>> von MS komplett widerspricht. Was dann? benutzt man dann also für C#
>> unter Windows die MS-Konvention und für C# unter Linux die X-konvention?
>> Das wäre ja wohl Schwachsinn, vor allem vor dem Hintergrund von
>> portierbarem Code.
>
> Es gilt immer die C# Spezifikation. Egal was für Firmen sich an was
> auch immer versuchen.
>
So? Was wenn Borland nun einen C#-Compiler entwickelt und das PascalCase
propagiert? Dazu noch etliche andere Punkte in einer Richtlinie? Dann werden
diejenigen, die Borland C# benutzen (analog zu Borland C++ damals) eine
andere Konvention als die einzig wahre propagieren, als die, die MS-C#
benutzen.
>> Vielleicht ist das das Problem. Ich sehe eine Namenskonvention ganz und
>> gar nicht an eine Sprache gebunden. Insofern erschließt sich mir - wie
>> erwähnt - auch der Sinn nicht, für eine neue Sprache eine komplett neue
>> Namenskonvention zu "erfinden". Wir benutzen die ungarische Notation für
>> unsere VC++- und C#-Projekte und auch für VB-, Java- und Python-Scripts.
>> Vollkommen sprachunabhängig. Und welch Wunder, es funktioniert. Es
>> funktioniert sogar ausgesprochen gut.
>
> Es gibt Richtlinien und Empfehlungen. Richtlinien sind
> in der C# Spec festgeschrieben, ob Du es so siehst oder nicht.
> Gegen Richtlinien zu verstossen, hat meist schon in kleinen
> Projekten spürbare negative Auswirkungen. Bei Empfehlungen
> ist das nicht immer so.
>
Ich glaube echt, Du hast rein inhaltlich gar nichts von dem verstanden, was
ich gesagt habe... Ich habe nie behauptet, dass die NK von MS keine
Richtlinie ist. Ich habe nicht mal behauptet, dass sie schlecht sei oder
dass man sie nicht benutzen soll.
Ist das echt so schwer zu verstehen?
Im Übrigen entwickeln wir hier seit Jahren Software und haben noch nie eine
MS-NK zu 100% übernommen. Dennoch gab es in den letzten 10 Jahren nur ein
Jahr, in dem der Umsatz unserer Firma nicht den des Vorjahres übertroffen
hat. Gäbe es diese negativen Auswirkungen, wäre dies wohl kaum möglich
gewesen.
>> Jede Sache hat zwei Seiten. Und ich finde erstens die negativen Dinge bei
>> weitem nicht so schlimm wie sie hier dargestellt werden (es handelt sich
>> dabei oftmals eh nur um akademische und rein hypothetische Beispiele,
>> fern jeglicher Realität) und zweitens bin ich der Meinung, dass die
>> positiven Dinge überwiegen.
>
> Du hast meine Hinweise gelesen. Ich bin nun schon sehr lange
> im Software-Geschäft und gerade im .NET Bereich schon lange
> spezialisiert. Vielleicht nimmst Du's einfach als gut gemeinten Ratschlag.
> Seine Erfahrungen muss man ja manchmal selber machen.
>
Ich denke, nach mehr als 10 Jahren insgesamt und fast 5 Jahren .NET habe ich
ausreichend Erfahrungen gemacht. Was ich Dir als gut gemeinten Ratschlag ans
Herz lege ist, dass Du Dir nochmal meine Kern-Aussage vornimmst und
versuchst, sie zu verstehen. Ich wettere nicht gegen MS und die von ihnen
aufgestellte NK für C#. Ich bin nur der Meinung (die wie gesagt auf
ausreichend langer Erfahrung basiert), dass man sie nicht zwingend benutzen
muss, um erfolgreich mit C# Software zu entwickeln.
>> Ich hatte eigentlich auch nicht vor, hier einen weiteren Glaubenskrieg zu
>> entfachen. Aber wenn ich lese, dass behauptet wird, eine Sache sei die
>> allein-seeligmachende und einzig richtige und wahre Sache, dann nimmt das
>> schon fast religiöse Züge an und da kann es mich schon mal überkommen,
>> meinen Senf dazu zu geben.
>
> Da hättest Du recht, wenn das so behauptet werden würde.
> Hat aber IMHO niemand.
>
IMHO schon:
"[...]Im grossen und ganzen sollte man sich daran halten! Es ist keineswegs
egal, wie die Benennung seiner Variablen aussieht, wie hier teilweise
gepostet wird.[...]"
"[...]Für das Gro der Entwickler sollten sowohl die Richtlinien als auch die
Empfehlungen unbedingt beachtet werden.[...]"
"[...]Dies also normal vermeiden, indem man gleich die Standard-Richtlinien
und Empfehlungen benutzt. Ggf. an Firmen-Gegebenheiten (möglichst
geringfügig) Standard-konform anpassen.[...]"
"[...]Wozu MS allerdings meiner Meinung nach KEIN Recht hat, ist diese
Namenskonvention als die einzig richtige (für C#) zu verkaufen.[...] ==>
[...]Aber doch, nämlich genau dann, wenn sie es ist.[...]"
"[...]Es geht nicht um Ansichten, sondern um Fakten, die jeder nachlesen
kann.[...]"
Gut, vielleicht überinterpretiere ich auch diese Aussagen.
> Ich habe ja öfter mit den MS-Koryphäen bzgl. Namenskonventionen
> gesprochen. Empfehlungen wollen sie nicht so sehen, dass sich
> Entwickler hier dogmatisch hineingezwungen fühlen. Ist aber alles schon
> von mir hier in der NG öfter publiziert worden ...
> MS meint hier, es gibt viele Gründe, warum die eine oder
> andere Empfehlung nicht benutzt werden muss.
>
Na, dann verstehe ich nicht, wieso Du diskutierst. Geht es Dir "nur" um die
Richtlinien? Denn ansonsten habe ich genau dasselbe gesagt wie die
MS-Leute...
>> Wichtiger als die Frage WELCHE Konvention in einem Team benutzt wird, ist
>> die Notwendigkeit, dass ALLE DIESELBE Konvention benutzen.
>
> Nein, das siehst Du wieder zu kurz/dogmatisch.
> Du musst bedenken, dass immer andere Entwickler hinzukommen
> können. Deine Firma ist zum Scheitern verurteilt, wenn sie
> nicht in der Lage ist, sich zu entwickeln.
>
Wie gesagt, das ist bei uns seit etlichen Jahren gängige Praxis. Und sie
funktioniert. Gut. Sehr gut sogar. Wenn jemand in ein anderes Land geht,
muss/sollte er auch die Sprache, die dort gesprochen wird, beherrschen.
Marc
Marc Weichhold
> Das wiederum gilt nur für Firmen, die "Standard-Software" erstellen. Wir
> setzen hier in unserem Haus auch viele Anwendungen ein, die verschiedene
> Firmen für uns im Auftrag erstellt haben und deren Code uns daher
> übergeben
> wurde. Als Inhouse-Programmierer muß ich gelegentlich Anpassungen an
> solchen
> Anwendungen vornehmen und wäre froh, wenn nicht jede Firma ihre eigenen
> Konventionen verwenden würde.
>
meiner Aussage auch von vornherein ausgeschlossen.
Marc
Thomas Scheidegger [MVP]
>> Chaos Pur. Punkt.
> Sorry, aber der Vergleich hinkt. Denn das würde bedeuten, dass der Code, den
> eine Firma produziert, publik gemacht würde. Ich behaupte mal weiterhin,
> dass die große Mehrheit der Softwarefirmen ihr Kapital (nachlich den
> produzierten Code) mit enormem Sicherheitsaufwand unter Verschluß hält.
ein ordentliche Namenskonvention sollte gar nicht abhängig sein,
ob bei Closed- oder Open-Source angewandt.
Es geht um eine allgemeingültige Systematik & Arbeits-/Denkmodell,
so dass Bücher/Webseiten(MSDN)/Lernmittel/Snippets/Tools/Examples usw ein einheitliches Erscheinungsbild
und Mitarbeiter nicht auf irgend eine willkürliche Variante einer Firma fixiert sind...
Ich kann dir aus der Praxis nur sagen (falls eure Firma nicht irgendwie ein totales & ewiges Monopol hat),
früher oder später können im offenen Markt jederzeit plötzlich Projekte/Änderungen 'auftauchen',
wo eine abweichende Namenskonvention nur noch hinderlich ist...
Marc Weichhold
> Es geht um eine allgemeingültige Systematik & Arbeits-/Denkmodell,
> so dass Bücher/Webseiten(MSDN)/Lernmittel/Snippets/Tools/Examples usw ein
> einheitliches Erscheinungsbild
> und Mitarbeiter nicht auf irgend eine willkürliche Variante einer Firma
> fixiert sind...
>
Nein, darum geht es nicht. Ich habe nie bestritten, dass die "offizielle" NK
nicht allgemeingültig sei, dass sie schlecht sei oder dass man sie nicht
benutzen sollte. Wenn man auf der Suche nach einer NK ist, sollte man es
ruhig mit der empfohlenen und am stärksten Verbreiteten Variabte versuchen.
Hat man aber eine NK, die den Anforderungen genügt, spricht auch nichts
dagegen, diese weiter zu verwenden. Sie ist nicht "falscher" als alle
anderen, obwohl hier manchmal so getan wird, als beginge man damit ein
Sakrileg. Das kann ich wirklich nicht nachvollziehen.
> Ich kann dir aus der Praxis nur sagen (falls eure Firma nicht irgendwie
> ein totales & ewiges Monopol hat),
> früher oder später können im offenen Markt jederzeit plötzlich
> Projekte/Änderungen 'auftauchen',
> wo eine abweichende Namenskonvention nur noch hinderlich ist...
>
Ich kann mir ehrlich gesagt nicht vorstellen (und in all den Jahren, in
denen ich Software entwickle ist es auch nicht vorgekommen, also ebenfalls
ein Praxisbericht), dass es bei uns zu Problemen wegen neuen Projekten oder
Änderungen an unserer Software, nur weil wir int m_nMaximum statt int
Maximum, oder class CBuffer statt class Buffer benutzen. Oder weil jemand
getThreshold statt GetThreshold schreibt (wir nicht, nur ein Beispiel).
Sorry, das ist es was ich mal erwähnte in dem Thread. Die Argumentationen
sind meist sehr akademischer Natur.
Ich will niemandem ausreden, die empfohlene NK zu verwenden. Wirklich nicht.
Marc
Thomas Scheidegger [MVP]
> Änderungen an unserer Software, nur weil wir int m_nMaximum statt int
> Maximum, oder class CBuffer statt class Buffer benutzen.
dies dürfte (historisch bedingt) auf die chaotische (bzw ganz fehlende) Konventionen _gewohnte_ C/C++ Welt gelten...
Einzig darum sind unendlich viele Konventionen (eine pro Firma) überhaupt erst entstanden,
was sich mit gesundem Menschenverstand & Weitsicht ja niemand ernsthaft wünscht.
Vorsicht, im C#/.NET Umfeld wird dagegen viel stärker auf Systematik & Konformität geachtet,
weil von _Anfang_ an die MS-Guidelines klar und deutlich kommuniziert und gefördert wurden
und weitherum auch (nur diese) _akzeptiert_ sind.
Frank Dzaebel
>> Z.B. "was ist der Sinn von Klassenbibliotheken"?
>> "Welche Vorteile hat man durch MSIL"?
>>
> Ich hatte vorher mehr als deutlich gesagt, dass es mir nicht um Code geht,
> der auf irgendeine Art und Weise veröffentlicht wird. Dies schließt
> Klassenbibliotheken natürlich ein.
Ihr dürft also keine Klassenbibliotheken in
Euren Projekten benutzen? Dann wundert mich
gar nichts mehr in Eurer Firma. Ich würde mich
hüten, den Namen Eurer Firma hier zu veröffentlichen ;-)
> MSIL heisst jetzt CIL
Der normale Namensgebrauch im MS-Umfeld ist
noch MSIL. Die ECMA hat dies in der 355er Spec
CIL genannt. Das ist auch ok und synonym. CIL
betont mehr die OS-Unabhängigkeit.
>> Vielleicht mag ich Dir etwas streng in der Formulierung vorkommen,
>> aber ich denke, Du hast mehr davon, ich sage Dir das hier ohne Schnörkel.
>> Gehe ruhig noch mal zu den Grundlagen zurück, Du wirst selber erkennen,
>> dass solche Richtlinien kaum anders sein können/sollten.
>>
> Ich habe das nie bestritten.
Dann ziehe auch mal die Konsequenzen und nutze sie.
>>> Ich halte es grundsätzlich für fragwürdig, eine funktionierende
>>> Konvention wegzuwerfen, nur weil eine neue Sprache entwickelt wird.
Ich halte es für *abstrus* bei neuen Sprachen und Frameworks
alte Konventionen dogmatisch hineinpressen zu wollen.
Das zeigt eigentlich nur, dass derjenige sich diesen Teil einfach mal
zeitlich sparen wollte. Das ist aber eben wichtig und nicht "egal"!
Marc, ich denke, wir sollten hier aufhören.
Ich sehe da kein Weiterkommen mit Dir.
Ich habe Dir einen kurzen Eindruck gegeben,
wies aussieht. Ob Du was damit anfangen kannst,
bleibt Dir überlassen. Ansonsten höre auf die anderen
Mitstreiter, die haben IMHO auch recht sinnreiche Erklärungen.
Herfried K. Wagner [MVP]
"Frank Dzaebel" <Po...@FranksSeite.de> schrieb:
>>>> Ich halte es grundsätzlich für fragwürdig, eine funktionierende
>>>> Konvention wegzuwerfen, nur weil eine neue Sprache entwickelt wird.
>
> Ich halte es für *abstrus* bei neuen Sprachen und Frameworks
> alte Konventionen dogmatisch hineinpressen zu wollen.
Wer spricht denn hier von "dogmatisch hineinpressen"? Wenn sich eine
Konvention bewährt hat und bei einer Abwägung der Vor- und Nachteile die
Vorteile des Weiterbehaltens der Konvention überwiegen, dann ist es doch
sinnvoll, die Konvention zu benutzen. Gutes und Passendes kann man
übernehmen, Ungeeignetes verwerfen.
Frank Dzaebel
>> Ich halte es für *abstrus* bei neuen Sprachen und Frameworks
>> alte Konventionen dogmatisch hineinpressen zu wollen.
>
> Wer spricht denn hier von "dogmatisch hineinpressen"?
Es ging hier um seine Ansicht, "alle Sprachen müssten
die gleiche (bei ihm wohl C++) Namenskonvention nutzen"
*abstrus*
> Gutes und Passendes kann man übernehmen, Ungeeignetes verwerfen.
Klar, wenn man im Spielraum der Empfehlungen ist,
(nicht der Richtlinien), darf man darüber nachdenken.
Dann aber sicher mit Sorgfalt, denn meistens haben
diese Empfehlungen einen Sinn, für den man evtl.
auch ein paar Stündchen Recherche einplanen sollte.
Ein "egal" wäre hier deutlich fehl am Platze.
Marc Weichhold
> die gleiche (bei ihm wohl C++) Namenskonvention nutzen"
> *abstrus*
>
lesen. Denn DAS habe ich nicht behauptet. Insofern hast Du recht, es hat
keinen Sinn, wenn Du versuchst, Deinem Gegenüber die Worte im Mund zu
verderehen und ihm Dinge anzudichten, die er so nie gesagt hat. So geht man
nicht miteinander um. Auch Deine spöttische Bemerkung über die Benutzung von
Klassenbibliotheken schlägt in dieselbe Kerbe. Mit ein wenig Nachdenken
könntest Du die von Dir implizit gestellte Frage selbst beantworten.
Herfried hat es schon korrekt wieder gegeben.
Marc
Marc Weichhold
> Wer spricht denn hier von "dogmatisch hineinpressen"? Wenn sich eine
> Konvention bewährt hat und bei einer Abwägung der Vor- und Nachteile die
> Vorteile des Weiterbehaltens der Konvention überwiegen, dann ist es doch
> sinnvoll, die Konvention zu benutzen. Gutes und Passendes kann man
> übernehmen, Ungeeignetes verwerfen.
>
Das ist absolut korrekt und nichts anderes habe ich sagen wollen. Wenn der
OP bisher mit seiner Notation zurecht kam (ob es nun die Ungarische Notation
ist oder irgendeine andere spielt überhaupt keine Rolle) und durch die
Weiterbenutzung keine gravierenden Nachteile entstehen für sein(e)
Projekt(e), dann kann er sie meiner Meinung nach auch weiter verwenden, auch
wenn MS eine andere NK empfiehlt.
Marc
Frank Dzaebel
> > Es ging hier um seine Ansicht, "alle Sprachen müssten
> > die gleiche (bei ihm wohl C++) Namenskonvention nutzen"
> > *abstrus*
> >
> ... DAS habe ich nicht behauptet.
Ist wohl von Deinem Zitat:
"Bei uns wird VC++, C# als Programmiersprache und
VB.NET, Java und Python als Scriptsprache eingesetzt und wir
benutzen für ALLE Sprachen DIESELBE Konvention."
nebst:
"Es ist egal, wie die Benennung seiner Variablen, Funktionen, etc. aussieht."
gekommen. Ich freue mich, wenn Du meinst, dass Du
dies alles nicht so gemeint hast, denn das wäre
halt wirklich nicht sinnvoll. Deswegen haben hier auch
recht viele geantwortet, denn es wäre nicht egal.
ciao Frank
--
Dipl. Inf. Frank Dzaebel [MCP, MVP C#]
http://Dzaebel.NET
Frank Dzaebel
>>Gutes und Passendes kann man
>> übernehmen, Ungeeignetes verwerfen.
> >
> Das ist absolut korrekt und nichts anderes habe ich sagen wollen. Wenn der
> OP bisher mit seiner Notation zurecht kam (ob es nun die Ungarische Notation
> ist oder irgendeine andere spielt überhaupt keine Rolle) und durch die
> Weiterbenutzung keine gravierenden Nachteile entstehen für sein(e)
> Projekt(e), dann kann er sie meiner Meinung nach auch weiter verwenden, auch
> wenn MS eine andere NK empfiehlt.
hört sich ja auch schon "etwas" besser an, jedoch wäre
"keine gravierende Nachteile" dann zu klären.
"Oft" wird man darauf kommen, dass es zu einem
gravierende Nachteil kommen kann! Wer genug Zeit hat,
alle Eventualitäten auszutesten und eine eigene Konvention
zu entwickeln, die mit dem Entwickler-Markt ggf. einigermassen
kompatibel ist und alle Inkompatibilitäten vermeidet
(wäre z.B. gravierender Nachteil) ist es IMHO durchaus erlaubt im
Rahmen der "Empfehlungen" Änderungen/Anpassungen
durchzuführen.
Ich schätze somit, dass Du Deine Formulierung:
"Es ist egal, wie die Benennung seiner Variablen, Funktionen, etc. aussieht."
ein bisschen relativiert siehst, denn wie Du ja erkannt hast, können
sich ggf. gravierende Nachteile ergeben.
Marc Weichhold
>> > Es ging hier um seine Ansicht, "alle Sprachen müssten
>> > die gleiche (bei ihm wohl C++) Namenskonvention nutzen"
>> > *abstrus*
>> >
>> ... DAS habe ich nicht behauptet.
>
> Ist wohl von Deinem Zitat:
>
> "Bei uns wird VC++, C# als Programmiersprache und
> VB.NET, Java und Python als Scriptsprache eingesetzt und wir
> benutzen für ALLE Sprachen DIESELBE Konvention."
>
> nebst:
> "Es ist egal, wie die Benennung seiner Variablen, Funktionen, etc.
> aussieht."
>
> gekommen.
>
Ich habe zwar gesagt, dass wir bei UNS für alle Sprachen dieselbe NK
benutzen (und dies nach wie vor erfolgreich), aber nie behauptet, dass ich
der Meinung sei, dass dies immer so sein muss oder müsste. Es diente
lediglich als Beispiel für meine Aussage, dass es meiner Meinung nach
wichtiger sei, dass alle (innerhalb eines Teams) dieselbe NK benutzen, egal
welche es ist. Es kann und darf (und - wenn man eine neue NK benötigt, weil
die bisherige nicht den Anforderungen genügt - sollte) auch die von MS
empfohlene NK sein.
Diesen Zusammenhang hatte ich allerdings auch mehrfach erläutert.
Dabei sollten wir es jetzt aber auch bewenden lassen.
Marc
Marc Weichhold
> hört sich ja auch schon "etwas" besser an
>
Es ist doch genau dasselbe, dass ich schon vorher gesagt habe. Hier mal ein
Zitat von weiter "oben":
"[...]Also zu guter Letzt: ich möchte hier nicht behaupten, dass die
"offizielle"
Konvention falsch ist oder schlecht oder was weiss ich was. Wer auf der
Suche nach einer neuen Konvention ist, weil er der Meinung ist, seine
bisherige sei nicht gut genug oder passt nicht zu den Anforderungen, der
kann sich ja durchaus an die offizielle Konvention halten.[...]"
> Ich schätze somit, dass Du Deine Formulierung:
> "Es ist egal, wie die Benennung seiner Variablen, Funktionen, etc.
> aussieht."
> ein bisschen relativiert siehst, denn wie Du ja erkannt hast, können
> sich ggf. gravierende Nachteile ergeben.
>
Ich habe meine Aussage nie als absolut angesehen und dies auch nie
behauptet. Es muss aber eben jedem selbst gestattet sein, die Nachteile
"seiner" NK abzuwägen und dann selbst zu entscheiden, ob "seine" bisherige
NK gut genug für sein(e) Projekt(e) ist oder nicht. So war mein "egal" von
vornherein gemeint, was Du auch leicht erkennen kannst, wenn Du Dir den
Thread nochmal durchliest.
Insofern würde ich jetzt eher sagen, dass Du Deine Aussagen relativiert
siehst. ;-)
Lass uns das jetzt beenden, näher kommen wir uns in diesem Punkt nicht mehr.
Marc
Frank Dzaebel
> > nebst:
> > "Es ist egal, wie die Benennung seiner Variablen,
> > Funktionen, etc. aussieht."
> >
> Ich denke, Du hast mich einfach falsch verstanden.
> Ich habe zwar gesagt, dass wir bei UNS für alle Sprachen dieselbe NK
> benutzen (und dies nach wie vor erfolgreich), aber nie behauptet, dass ich
> der Meinung sei, dass dies immer so sein muss oder müsste.
Ok, wenn Du das anders (so) gemeint hast, ist das eine gute
Klarstellung. Ich habe trotzdem nochmal zum Abschluss
eine Auszug-Kopie meines Postings gemacht:
"Klar, wenn man im Spielraum der Empfehlungen ist,
(nicht der Richtlinien), darf man darüber nachdenken.
Dann aber sicher mit Sorgfalt, denn meistens haben
diese Empfehlungen einen Sinn, für den man evtl.
auch ein paar Stündchen Recherche einplanen sollte.
Ein "egal" wäre hier deutlich fehl am Platze."
Vielleicht sind wir dort dann ja näher gekommen.
> lediglich als Beispiel für meine Aussage, dass es meiner Meinung nach
> wichtiger sei, dass alle (innerhalb eines Teams) dieselbe NK benutzen, egal
> welche es ist.
Nein, es ist nicht "egal", wie Du bereits selber ja erkannt hattest.
Wenn diese "gravierenden Nachteile" (so Dein Ausdruck) hätte,
würdest Du die eben auch nicht einsetzen. Diese Nachteile
würde man vorher checken und eroieren (es gibt deren viele),
weswegen mir (uns) hier ein "egal" fehl am Platze erscheint.
> Dabei sollten wir es jetzt aber auch bewenden lassen.
Das ist ein guter Zeitpunkt.
Paul Werkowitz
> Verwalteter Code ist etwas anderes als unverwalteter.
> Verstehe zuerst mal die Grundlagen und gehe von da
> weiter, erst dann wirst Du erkennen, wie logisch und
> wichtig die Richtlinien sind.
Frank, daraus schließt du doch nicht im Ernst, dass *eine bestimmte*
Konvention besser als eine andere ist! Der Punkt ist doch, dass überhaupt
eine Konvention eingehalten wird. Diese muss nicht weltweit eindeutig sein.
[snip]
>
> Letztlich entwickelt das keine einzelne subjektive Person,
> sondern ganze Teams, bei denen jeder einzelne Spezialist ist,
> und höchstwahrscheinlich mehr diesbzgl. drauf hat, als wir zwei beiden.
> Was ich so von den MSlern mitbekomme, und ich deutlich näher
> dran, die nehmen sich wirklich extrem gute Leute an die Hand und
> habe da schon Respekt vor deren Leistungen - und das nun wahrlich
> nicht rein subjektiv.
>
Aha. Ich erinnere mich gut an die Notation "m_Irgendwas" (also das m_
Prefix) aus der MFC/C++ - Welt. Das war damals ebenso "offiziell" und
ebenso katastrophal. Wenn man schon eine Namenskonvention macht, sollte man
die Lesbarkeit der Konstrukte als Qualitätskriterium beachten. Wurde hier
völlig ignoriert - trotzdem offizielle Microsoft-Norm.
Anmerkung: Aus meiner Praxis als Consultant kann ich sagen, dass nur
Rookies diese Norm so eingehalten haben. Alle erfahreneren Teams haben sich
erst mal vernünftige Konventionen gegeben.
My 2 cents
Paule
Frank Dzaebel
>> Verwalteter Code ist etwas anderes als unverwalteter.
>> Verstehe zuerst mal die Grundlagen und gehe von da
>> weiter, erst dann wirst Du erkennen, wie logisch und
>> wichtig die Richtlinien sind.
>
> Frank, daraus schließt du doch nicht im Ernst, dass
> *eine bestimmte* Konvention besser als eine andere ist!
Eine Konvention kann in ihrem System (sagen wir C++)
gut sein und in anderen Systemen (z.B. C#) schlecht, bis
gar nicht (z.B. syntaktisch) möglich.
Das ist doch auch eine allgemeine Lehre des Lebens.
Also eher die Frage zurück an Dich "meinst Du das im Ernst".
> Der Punkt ist doch, dass überhaupt eine
> Konvention eingehalten wird.
Das ist *ein* wichtiger Punkte, aber wenn die Konvention
schlecht wäre (sagen wir alle Identifier klein schreiben)
hätte man einen kontraproduktiven Effekt. Deswegen
also: "nicht *egal* welche".
> Diese muss nicht weltweit eindeutig sein.
"Muss" nicht, im Rahmen von *Empfehlungen*.
Das gilt nicht für Richtlinien.
Richtlinien verhindern gottseidank, dass
grobe Fehler auftauchen können (z.B.
Ermöglichung sprachübergreifender DLL-Nutzung).
Eigene Zusätze - wie mehrfach erwähnt - mit
aüsserstem Bedacht entscheiden.
Die Richtlinien sollten eingehalten werden.
>> Letztlich entwickelt das keine einzelne subjektive Person,
>> sondern ganze Teams, bei denen jeder einzelne Spezialist ist,
>> und höchstwahrscheinlich mehr diesbzgl. drauf hat, als wir zwei beiden.
>> Was ich so von den MSlern mitbekomme, und ich deutlich näher
>> dran, die nehmen sich wirklich extrem gute Leute an die Hand und
>> habe da schon Respekt vor deren Leistungen - und das nun wahrlich
>> nicht rein subjektiv.
> Aha. Ich erinnere mich gut an die Notation "m_Irgendwas" (also das m_
> Prefix) aus der MFC/C++ - Welt. Das war damals ebenso "offiziell" und
> ebenso katastrophal. Wenn man schon eine Namenskonvention macht,
> sollte man die Lesbarkeit der Konstrukte als Qualitätskriterium beachten.
> Wurde hier
> völlig ignoriert - trotzdem offizielle Microsoft-Norm.
Du hast jetzt aber evtl. die Systeme vermixt.
In einem anderen System wie C++ hast Du nicht die Reflection
und Metadaten-Möglichkeiten wie in einem verwalteten.
Hier können andere Benennungsrichtlinien greifen.
Ebenso sind heutzutage die IDEs so mächtig geworden, dass
Benennungen oft schon durch spezielle IDE-Darstellung
überflüssig werden. Das hat eben auch inhärent etwas mit den
Grundlagen - sprich den Möglichkeiten der Sprache, des
Frameworks - zutun.
> Anmerkung: Aus meiner Praxis als Consultant kann
> ich sagen, dass nur Rookies diese Norm so eingehalten
> haben. Alle erfahreneren Teams haben sich
> erst mal vernünftige Konventionen gegeben.
Dass Teams versuchen sich zu einigen, dass alle
bestimmte Konventionen einhalten ist gängig und gut.
Die Praxis ist da, dass dies eher zu wenig geschieht.
Je mehr das aber geschieht und je fachlich besser
informiert, desto mehr gehts in Richtung offiziellerer
Empfehlungen. Nicht verwunderlich, haben da doch
Profis dran gearbeitet, die sich schon etwas länger mit
der Materie beschäftigen.
Wer ohne aüssersten Bedacht Konventionen aufstellt,
wäre kein Profi. Ein Profi ist sich evtl. eher seiner Lücken
bewusst, als ein mittlerer Entwickler, der denkt, er wisse
alles. Wie gesagt, im Rahmen der
Empfehlungen, sind solche Dinge aber möglich.
Leider hat man auch den Effekt, dass
tatsächlich Leute da sind, die die Gruppe z.B. dominieren.
Wenn dieser aber trotzdem eher weniger Ahnung (auf dem
Gebiet) haben, hat man ggf. solche Schoten auch in
Firmen-Konventionen.
Paul Werkowitz
> Hallo, Coder2001, Du schriebst:
>> Hallo allerseits,
>> ich steige momentan von VB6 auf C# um. Ich bin unsicher, wie ich meine
>> Steuerelemente benennen soll. In VB6 hatte ich grundsätzlich die
>> "ungarische Notation" verwendet (z. B. lblUser oder frmMain). Diese
>> Schreibweise ist, wie ich herausgelesen habe, inzwischen verpönt!
>> Vielleicht hat jemand Vorschläge zu diesem Thema.
>
> Füge im Prinzip erstmal die Vokale wieder ein, sodass aus "lbl" "label"
> und aus "frm" "form" werden. Ansonsten fährst Du gut damit, wenn Du Dich
> an die Vorgaben der IDE hältst. Da sind zwar manche Benamungen von 2003
> nach 2005 schwer geändert, aber für neue Anwendungen ist die einfachste
> Regel, dass, je weniger Zeichen Du vom vorgeschlagenen Namen änderst,
> desto kompatibler bleibst Du. Wenn da also "label1" steht und Du
> "labelUser" draus machst, ist das besser, als wenn Du "lblUser" draus
> machst oder gar "userLabel" oder "userName".
Hallo Carsten,
> Genau genommen ist die beste Regel eigentlich keine Vorschrift von MS
> oder ECMA oder sonstwas, sondern Dein eigener Verstand. Klar ist es
> etwas aufwändiger, einmalig "labelUserFirstName" zu tippen, aber danach
> ist IntelliSense Dein Freund, und "labelUserFirstName" ist eben
> intuitiver als "lblUsrFName", oder? DARUM gehts bei all den Debatten.
> "N" war ja zu Zeiten von 32 Kilobytes RAM nicht deswegen Netto, weil es
> so logisch war, sondern weil der Speicher knapp war.
>
Nein, es gibt weitere Gründe. Betrachtet man Quellcode auch als
Kommunikationsmedium zwischen Menschen, ist die Lesbarkeit ein wesentliches
Kriterium. Wenn ich z.B hundert mal den Begriff HeilUndKostenplan brauche,
kürze ich den ab. - Aber nicht um Tipparbeit zu sparen (in Zeiten von
Intellisense eh unwichtig), sondern um die Lesbarkeit des Codes zu erhöhen.
HKN lässt sichintuitiv erfassen - man muss nicht den ganzen Wurm lesen.
Bekanntere Beispiele sind auch offset -> ofs, oder numer -> nbr, etc.
Wenn es im Programm tausend labels gibt, ist lbl durchaus OK. label bring
t dann nicht mehr Information. FirstName mit FName abzukürzen halte ich
auch für nicht gut. Regel: Immer erst die Vokale wegnehmen - die enthalten
am wenigsten Information.
Paule
Paul Werkowitz
Paul Werkowitz
Moin,
> Eine Konvention kann in ihrem System (sagen wir C++)
> gut sein und in anderen Systemen (z.B. C#) schlecht, bis
> gar nicht (z.B. syntaktisch) möglich.
> Das ist doch auch eine allgemeine Lehre des Lebens.
> Also eher die Frage zurück an Dich "meinst Du das im Ernst".
>
Prinzipiell richtig, IMHO aber wesentlich weniger, als du denkst. Dazu
schreibe ich gleich noch was - hier gings aber darum, dass diese eine
Konvention als die einzig selig machende bezeichnet wurde. Und das kann man
so nicht lassen.
>
>> Der Punkt ist doch, dass überhaupt eine
>> Konvention eingehalten wird.
>
> Das ist *ein* wichtiger Punkte, aber wenn die Konvention
> schlecht wäre (sagen wir alle Identifier klein schreiben)
> hätte man einen kontraproduktiven Effekt. Deswegen
> also: "nicht *egal* welche".
>
Stimmt, ist nicht egal. Es gibt (zumindest einige) *objektive* Kriterien,
welche Dinge gut und welche weniger gut sind. Man sollte natürlich
Konventionen bevorzugen, die objektiv besser als andere sind. Insofern habe
ich mich nicht ganz klar ausgedrückt - ich meinte, dass es wichtiger sei,
sich überhaupt mit Komnventionsdingen zu befassen als eine, von der
behauptet wird, sie sei gut, unreflektiert zu übernehmen.
Mein Standardbeispiel hier ist eben die bereits genannte m_irgendwas
Konvention zur Namensgebung von Mitgliedsvariablen. War offizielle
MS-Meinung, und damit Standard - nichtsdestotrotz unter *objektiven*
Kriterien unakzeptabel.
Es ist zumindest mal zu überlegen, ob ähnliche Effekte nicht hier auch
vorliegen könnten.
Nun einige Worte zu dem Argument, dass für unterschiedliche Sprachen auch
unterschiedliche Konventionen angezeigt sein können. Dem ist - zumindest
was die C-Sprchfamilie angeht - nicht so. Ich kann nicht sehen, warum z.B.
camelCasing für C# gut, für Java dagegen schlecht sein könnte (um das böse
Wort C++ hier mal zu vermeiden). Die Sprachen der C-Familie sind sich
syntaktisch so ähnlich, dass für die Benennung von Bezeichnern und zum
Aufbau von Code die gleichen Regeln gelten müssen (nicht: *sollen*, sondern
*müssen*). Ich kann außerdem nicht sehen, wie die Möglichkeit zu
Reflection, MSIL und die anderen genannten Sachen hier irgendeinen
Unterschied machen können. Vielleicht kannst du mal ein Beispiel bringen.
[snip]
>
> Du hast jetzt aber evtl. die Systeme vermixt.
> In einem anderen System wie C++ hast Du nicht die Reflection
> und Metadaten-Möglichkeiten wie in einem verwalteten.
> Hier können andere Benennungsrichtlinien greifen.
Genau hier hätte ich mal -v, bitte.
> Ebenso sind heutzutage die IDEs so mächtig geworden, dass
> Benennungen oft schon durch spezielle IDE-Darstellung
> überflüssig werden. Das hat eben auch inhärent etwas mit den
> Grundlagen - sprich den Möglichkeiten der Sprache, des
> Frameworks - zutun.
Die IDE Unterstützung hat nichts mit den Sprachgrundlagen zu tun. Die
Syntax von C# bleibt gleich, egal mit welcher IDE ich den Code erstelle.
Weiterhin - und häufig übersehen - : Code wird 8x häufiger gelesen als
geschrieben, und beim Lesen habe ich keine IDE-Unterstützung.
Korrekt ist, dass die IDE das Erstellen von Code vereinfacht. Dinge wie
Intellisense und dort vor allem die alphabetische Sortierung in
Auswahllisten legen eine andere Konvention für Programmbezeichner nahe als
das vielleicht früher ohne Intellisense war. Dies gilt für alle Sprachen,
für C# und Java ebenso wie für C und C++, denn auch dort gibt es
mittlerweile gute IDEs mit Intellisense.
[snip]
> Nicht verwunderlich, haben da doch
> Profis dran gearbeitet, die sich schon etwas länger mit
> der Materie beschäftigen.
Richtig, aber Leute dieses Kalibers haben auch die ungarische Notation für
gut befunden, oder wie gesagt die unsägliche m_* Schreibweise. Man muss das
schon bisschen selber reflektieren, und IMO haben wir beide ausreichend
Erfahrung, um das auch zu wissen.
Paule
Marc Weichhold
Ich will mich gar nicht weiter einmischen, da aus meiner Sicht alles
(wichtige) gesagt wurde. Aber eine Frage hätte ich dann doch noch...
> Mein Standardbeispiel hier ist eben die bereits genannte m_irgendwas
> Konvention zur Namensgebung von Mitgliedsvariablen. War offizielle
> MS-Meinung, und damit Standard - nichtsdestotrotz unter *objektiven*
> Kriterien unakzeptabel.
>
Kannst Du diese objektiven Kriterien mal nennen? AFAIK ist gerade "m_" eine
der Dinge, die auch heute noch von etlichen C#-Entwicklern benutzt wird. Sei
es aus Gewohnheit, sei es, weil "this." (<-- das wäre glaube ich MS-konform
für C#) 3 Zeichen mehr zu schreiben sind. Fakt ist doch, dass es notwendig
ist, Membervariablen einer Klasse von Parametern und/oder "normalen"
Variablen syntaktisch und auch semantisch zu unterscheiden. Wie würde Deine
Lösung aussehen, um so etwas zu realisieren:
public class MyClass
{
private int m_Maximum; // Ok, ich würde jetzt sogar m_nMaximum
schreiben...
public MyClass(int Maximum)
{
m_Maximum = Maximum;
}
}
Marc
Marc Weichhold
> Nein, es gibt weitere Gründe. Betrachtet man Quellcode auch als
> Kommunikationsmedium zwischen Menschen, ist die Lesbarkeit ein
> wesentliches
> Kriterium. Wenn ich z.B hundert mal den Begriff HeilUndKostenplan brauche,
> kürze ich den ab. - Aber nicht um Tipparbeit zu sparen (in Zeiten von
> Intellisense eh unwichtig), sondern um die Lesbarkeit des Codes zu
> erhöhen.
> HKN lässt sichintuitiv erfassen - man muss nicht den ganzen Wurm lesen.
> Bekanntere Beispiele sind auch offset -> ofs, oder numer -> nbr, etc.
>
> Wenn es im Programm tausend labels gibt, ist lbl durchaus OK. label bring
> t dann nicht mehr Information. FirstName mit FName abzukürzen halte ich
> auch für nicht gut. Regel: Immer erst die Vokale wegnehmen - die enthalten
> am wenigsten Information.
>
N, dnn wrst D j kn Prblm hbn, dsn Txt z vrsthn.
Mrc
Frank Dzaebel
> public class MyClass
> { private int m_Maximum; }
Nein.
Die offizielle *Empfehlung* lautet auf *CamelCase*.
Auch für Membervariablen. Dennoch ist es immernoch
im Rahmen einer Empfehlung (keiner Richtlinie).
CamelCase sieht etwa so aus:
public class MyClass
{
private int meineVariable;
}
[Qualitätssicherung für verwalteten Sourcecode]
http://www.microsoft.com/germany/msdn/library/net/QualitaetssicherungFuerVerwaltetenSourcecode.mspx
[Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable
.NET Libraries (Microsoft .NET Development Series) (Hardcover)]
http://www.amazon.com/gp/product/0321246756/
by Krzysztof Cwalina (Author), Brad Abrams (Author)
Bei privater Korrespondenz von mir mit Brad und Krzysztof,
wurde folgende Linie deutlich:
http://groups.google.com/group/microsoft.public.de.german.entwickler.dotnet.csharp/msg/96bae222fd79ed35
Da auch MS noch viele C++ Entwickler hatte, war die
Umstellung damals auf CamelCase bei den MemberVariablen
auch nicht ohne Gegner und man sieht heutzutage immernoch
vereinzelt ungarische Notationen selbst bei C#.
Frank Dzaebel
> Wenn es im Programm tausend labels gibt, ist lbl durchaus OK. label bring
> t dann nicht mehr Information. FirstName mit FName abzukürzen halte ich
> auch für nicht gut. Regel: Immer erst die Vokale wegnehmen - die enthalten
> am wenigsten Information.
Ich bin bei der Steuerelement-Benennung Deiner Meinung.
Marc Weichhold
> Nein.
> Die offizielle *Empfehlung* lautet auf *CamelCase*.
> Auch für Membervariablen. Dennoch ist es immernoch
> im Rahmen einer Empfehlung (keiner Richtlinie).
> CamelCase sieht etwa so aus:
>
> public class MyClass
> {
> private int meineVariable;
> }
>
> [Qualitätssicherung für verwalteten Sourcecode]
> http://www.microsoft.com/germany/msdn/library/net/QualitaetssicherungFuerVerwaltetenSourcecode.mspx
>
hat/bewähren kann, denn ich halte sie für extrem fehleranfällig. Ich zitiere
mal den entscheidenden Satz aus der Empfehlung:
"[...]verwenden Sie camelCasing [...] für Parameter, lokale Variablen und
die privaten oder geschützten Variablen einer Klasse[...]"
Mit anderen Worten, die Empfehlung sagt, man soll gar keine äußerliche
Unterscheidung zwischen Membervariablen, Parametern und lokalen Variablen
machen?!? Wie gesagt, das wird zwangsläufig zu Fehlern führen, die - je nach
Größe des Projekts/der Klassen - schwer aufzuspüren sind.
class MyClass
{
private int myVar;
void MyFunc()
{
int myVar;
myVar = 3; // Welche Variable hier geändert wird, ist nicht sofort
klar.
}
}
> Bei privater Korrespondenz von mir mit Brad und Krzysztof,
> wurde folgende Linie deutlich:
> http://groups.google.com/group/microsoft.public.de.german.entwickler.dotnet.csharp/msg/96bae222fd79ed35
>
> Da auch MS noch viele C++ Entwickler hatte, war die
> Umstellung damals auf CamelCase bei den MemberVariablen
> auch nicht ohne Gegner und man sieht heutzutage immernoch
> vereinzelt ungarische Notationen selbst bei C#.
>
Das war es, was ich meinte. Ich habe hier in der NG schon öfter gesehen,
dass speziell das "m_" nicht sehr verpönt ist unter den C#-Entwicklern.
Marc
PS: Interessant übrigens der Satz von Krzysztof Cwalina:
"Yes, we try not to get into the business of defining guidelines for
non-public visible identifiers. There is just too much personal taste
involved here and the consistency argument is not as strong."
Aber egal, lass uns bitte nicht von vorne anfangen.
Marc Weichhold
>> Wenn es im Programm tausend labels gibt, ist lbl durchaus OK. label bring
>> t dann nicht mehr Information. FirstName mit FName abzukürzen halte ich
>> auch für nicht gut. Regel: Immer erst die Vokale wegnehmen - die
>> enthalten
>> am wenigsten Information.
>
> Ich bin bei der Steuerelement-Benennung Deiner Meinung.
>
http://www.microsoft.com/germany/msdn/library/net/QualitaetssicherungFuerVerwaltetenSourcecode.mspx
"[...]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.[...]"
Ich meine, WENN Du diese offizielle NK schon so verteidigst...
Marc
Paul Werkowitz
> Kannst Du diese objektiven Kriterien mal nennen? AFAIK ist gerade "m_" eine
> der Dinge, die auch heute noch von etlichen C#-Entwicklern benutzt wird.
Gerne.
Der Unterstrich enthält sehr wenig Tinte (klassisch "Blei"), und ist daher
von einem whitespace kaum zu unterscheiden. Betrachtet man Quelltext als
Folge von bedeutungsvollen Textpassagen, ergeben sich daraus folgende
Forderungen:
1.) Zusammengehörige Teile sollen als solche zu erkennen sein
2.) Die Teile sollen optisch voneinander getrennt sein.
Code der diese Anforderungen erfüllt, ist wesentlich leichter zu lesen, was
sich z.B. nach 10h konzentrierter Arbeit schon mal positiv bemerkbar machen
kann. Also:
result_type result_code calculate_social_security_number(person
citizen,bool checked_local_insurance_state, exception_flags flags);
ist ERHEBLICH schwerer zu lesen als z.B.
ResultType resultCode calculateSocialSecurityNumber( Person citizen, bool
checkedLocalInsuranceState, ExceptionFlags flags );
(Anmerkung: Zur Verdeutlichung auch noch das casing verändert. Beachte die
Verwendung von whitespace!).
oder evtl. sogar
ResultType resultCode
calculateSocialSecurityNumber
(
Person citizen
, bool checkedLocalInsuranceState
, ExceptionFlags flags
);
das erfüllt - neben den zwei oben genannten Forderunge - weitere
Forderungen an die Formatierung, die in diesem Posting zunächst unerläutert
bleiben sollen.
OK, das war jetzt ein Extremfall, aber z.B. die Entwickler der C++
Standardbibliothek haben sich für erstere Konvention entschieden (aus
Gründen, die ich nachvollziehen kann). Trotzdem kann man wohl sagen, dass
erstere Version *objektiv* schlechter zu lesen ist als zweitere. Und da
Quellcode zunächst einmal ein Mittel zur Kommunikation zwischen Menschen
ist, kommt es auf die Lesbarkeit ganz wesentlich an. Quellcode wird 8x
häufiger gelesen als geschrieben!
Damit sollte die Unterlegenheit der m_ Konvention ausreichend begründet
sein.
>Sei
> es aus Gewohnheit, sei es, weil "this." (<-- das wäre glaube ich MS-konform
> für C#) 3 Zeichen mehr zu schreiben sind. Fakt ist doch, dass es notwendig
> ist, Membervariablen einer Klasse von Parametern und/oder "normalen"
> Variablen syntaktisch und auch semantisch zu unterscheiden. Wie würde Deine
> Lösung aussehen, um so etwas zu realisieren:
>
> public class MyClass
> {
> private int m_Maximum; // Ok, ich würde jetzt sogar m_nMaximum
> schreiben...
>
> public MyClass(int Maximum)
> {
> m_Maximum = Maximum;
> }
> }
>
> Marc
Absolut richtig erkannt: Parameter sollten von lokalen Variablen und
Klassenmitgliedern unterschieden werden können - und ich lege noch eins
drauf und fordere, dass die irrtümliche Verwendung einen Syntaxfehler
produzieren soll.
Die Verwendung von this-> zur Bezeichnung von membern erfüllt diese
Forderung nicht. Code wie
Maximum = Maximum;
ist syntaktisch OK, gemeint war wohl
this->Maximum = Maximum;
oder auch
Maximum = this->Maximum;
Wieder ein Fehler, den man zur Laufzeit bemerkt, obwohl man es zur
Übersetzungszeit hätte schon merken können. Ungut! (ein guter Compiler gibt
hier eine Warnung, muss aber nicht).
Daher ist z.B. etwas wie
public MyClass( int aMaximum )
{
mMaximum = aMaximum;
}
die bessere Lösung.
("a" steht für "Arument" und wurde von mir gewählt, da "p" für Parameter
etwas wie
public MyClass( int pMaximum )
ergeben würde, was vor allem unter C++ mit einer anderen Namenskonvention
(ungarisch, dort steht p für pointer) kollidieren würde.
Analoge Überlegungen führen übrigens auch zu einer Konvention für die
Namensgebeung von Funktionen. Es ist z.B. ein Unterschied, ob es sich um
eine "normale" Klassenfunktion handelt, oder aber um die Implementierung
einer Funktion aus einem Interface.
Etc. für Typen (Klassen, Interfaces, usw.)
My 2 cents
Paule
Paul Werkowitz
> "[...]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.[...]"
>
Anmerkung hierzu:
Die Beschränkung auf Codeüberprüfungen macht es mal wieder vollkommen
deutlich, welche Leute da dahinter sitzen. IMO gehört eine Abkürzungskultur
mit zu den wichtigsten Dingen bei der Projektentwicklung. Dies muss
*vorher* erfolgen!
Codeüberprüfungen sind ein Luxus, den sich nur wenige leisten. Die Praxis
sieht so aus, dass Code, der läuft, aber nicht optimal ist, niemals mehr
verändert wird. Entwickler kosten Geld, und haben "Besseres" zu tun (aus
Sicht des Managements) - nämlich Funktionalität bereitstellen.
Ich habe es noch niemals erlebt, dass Geld dafür locker gemacht wurde, Code
zu "verschönern", ohne die Funktionalität zu verändern. Schon Refactoring -
wie es in der Agilen Entwicklung immer wieder notwendig ist - kann man kaum
durchdrücken.
Paule
Marc Weichhold
> result_type result_code calculate_social_security_number(person
> citizen,bool checked_local_insurance_state, exception_flags flags);
>
> ist ERHEBLICH schwerer zu lesen als z.B.
>
> ResultType resultCode calculateSocialSecurityNumber( Person citizen, bool
> checkedLocalInsuranceState, ExceptionFlags flags );
>
Da gebe ich Dir uneingeschränkt recht.
Daher ist "m_" auch als eine der wenigen Ausnahmen, bei denen wir
Unterstriche zulassen in unserer NK. Ansonsten sind bei uns die Unterstriche
ebenfalls "verboten". Allerdings halte ich es für ein gut funktionierendes
Mittel, Membervariablen zu kennzeichnen. Ich glaube ehrlich gesagt nicht,
dass jemand in die Verlegenheit kommt, "m_" irgendwie zu überlesen oder
mißzuinterpretieren.
> OK, das war jetzt ein Extremfall, aber z.B. die Entwickler der C++
> Standardbibliothek haben sich für erstere Konvention entschieden (aus
> Gründen, die ich nachvollziehen kann). Trotzdem kann man wohl sagen, dass
> erstere Version *objektiv* schlechter zu lesen ist als zweitere.
> ...
> Damit sollte die Unterlegenheit der m_ Konvention ausreichend begründet
> sein.
>
Wie gesagt, nur wenn man den Gebrauch von Unterstrichen nicht stark
eingrenzt. Als Ausnahme benutzt halte ich es auch objektiv nicht für
schlechter lesbar, allerdings im Vergleich zu den Alternativen für weitaus
weniger fehleranfällig. Eben aus den unten von Dir aufgeführten Gründen. Und
dieses Argument sollte bei der Erzeugung von Quellcode denke ich die
stärkere Gewichtung haben.
> Absolut richtig erkannt: Parameter sollten von lokalen Variablen und
> Klassenmitgliedern unterschieden werden können - und ich lege noch eins
> drauf und fordere, dass die irrtümliche Verwendung einen Syntaxfehler
> produzieren soll.
>
Was aber nur vom jeweiligen Compiler abhängt und nicht von einer NK, wie Du
ja selbst bemerkt hast.
> Daher ist z.B. etwas wie
>
> public MyClass( int aMaximum )
> {
> mMaximum = aMaximum;
> }
>
> die bessere Lösung.
> ("a" steht für "Arument" und wurde von mir gewählt, da "p" für Parameter
> etwas wie
>
> public MyClass( int pMaximum )
>
> ergeben würde, was vor allem unter C++ mit einer anderen Namenskonvention
> (ungarisch, dort steht p für pointer) kollidieren würde.
>
Und 'a' für Array (bei uns). Insofern ist in unserem Fall (und es ging ja um
eine an die jeweiligen Umstände angepasste Notation) "m_" bzw. "p_" (für
Parameter) die bessere Wahl.
Ganz sooo objektiv kann man also nicht behaupten "m_" sei "böse". Allgemein
kann man vielleicht aus den von Dir genannten Gründen nur stark empfehlen,
die Nutzung von Unterstrichen ganz stark einzuschränken, aber die Feinheiten
müssen meiner Meinung nach eben an die Gegebenheiten in der jeweiligen Firma
angepasst werden.
Marc
Paul Werkowitz
Am Fri, 20 Apr 2007 16:41:52 +0200 schrieb Marc Weichhold:
>
> Daher ist "m_" auch als eine der wenigen Ausnahmen, bei denen wir
> Unterstriche zulassen in unserer NK. Ansonsten sind bei uns die Unterstriche
> ebenfalls "verboten". Allerdings halte ich es für ein gut funktionierendes
> Mittel, Membervariablen zu kennzeichnen. Ich glaube ehrlich gesagt nicht,
> dass jemand in die Verlegenheit kommt, "m_" irgendwie zu überlesen oder
> mißzuinterpretieren.
OK, dann machst du eine Güterabwägung, bei der für euch die Vorteile
überwiegen. Das ist OK, hat aber mit *objektiv* - und darauf bezieht sich
meine Aussage - nichts zu tun.
Wie ich am Beispiel der C++ Standardlib erläutert habe, kann man durchaus
zu dem Ergebnis kommen, dass Unterstriche OK sind. Dann spielen aber andere
Gründe eine Rolle.
[snip]
> Und 'a' für Array (bei uns). Insofern ist in unserem Fall (und es ging ja um
> eine an die jeweiligen Umstände angepasste Notation) "m_" bzw. "p_" (für
> Parameter) die bessere Wahl.
IMO sollten Typen nicht im Namen kodiert werden. Ob es struct, eine class,
ein enum oder array ist, hat in dern Namenskonvention nichts zu suchen (ich
meine jetzt nicht die Singular/Plural/Verb/Hauptwort-Geschichte). a für
array - und was nehmt ihr für enums?
> Ganz sooo objektiv kann man also nicht behaupten "m_" sei "böse". Allgemein
> kann man vielleicht aus den von Dir genannten Gründen nur stark empfehlen,
> die Nutzung von Unterstrichen ganz stark einzuschränken, aber die Feinheiten
> müssen meiner Meinung nach eben an die Gegebenheiten in der jeweiligen Firma
> angepasst werden.
Umgekehrt wird ein Schuh draus: Ich habe objektive Kriterien genannt, warum
UNterstriche nicht in Bezeichnern auftauschen sollen. Persönliche
Vorlieben, Historie, Firmenkultur und eine große Reihe weiterer Gründe
können dazu führen, dass man es dann doch anders macht - das ist OK.
Insofern ist gegen m_ nichts einzuwenden. Bei uns ist das aber definitiv
keine Option.
Grüße - Paule
Paul Werkowitz
>> Wenn es im Programm tausend labels gibt, ist lbl durchaus OK. label bring
>> t dann nicht mehr Information. FirstName mit FName abzukürzen halte ich
>> auch für nicht gut. Regel: Immer erst die Vokale wegnehmen - die enthalten
>> am wenigsten Information.
>>
> N, dnn wrst D j kn Prblm hbn, dsn Txt z vrsthn.
>
> Mrc
Habe ich in der Tat nicht, und jeder wird das lesen können - wenn auch mit
Mühe. Denn das Hauptproblem bei diesem Satz ist, dass die Eintzelteile nur
durch Betrachtung des Ganzen ihren Sinn enthüllen. Oder kannst du mir
sagen, was mit "N" oder "z" gemeint ist, ohne den Satz zu sehen?
Schreibe ich jedoch in einer Software zur Flugplanbearbeitung 1000 mal
ETA
anstelle von
EstimatedTimeOfArrival
ist schon die Frage, was günstiger ist. Insbesondere sagt auch jeder
Piloteur ETA und nicht die Langform.
Paule
Günter Prossliner
> Und 'a' für Array (bei uns). Insofern ist in unserem Fall (und es
> ging ja um eine an die jeweiligen Umstände angepasste Notation) "m_"
> bzw. "p_" (für Parameter) die bessere Wahl.
Heissen dann die Funktionen z.B.:
public void Foo(int[] p_aiNumbers, p_bFlag){ ... } ?
Ist IMO zu der offiziellen MS Konvention
public void Foo(int[] numbers, bool flag) { ... }
sehr unlesbar. Die zahlreichen Prefixe ziehen die Aufmerksamkeit auf sich,
obwohl die Information ja in C# ohnehin immer vor dem Bezeichner befindet.
Ausserdem "verunstalten" diese Prefixe die öffentliche Schnittstelle. Hat in
streng typisierten Sprachen IMO keinen Mehrwert.
> ..., aber die Feinheiten müssen meiner Meinung nach eben
> an die Gegebenheiten in der jeweiligen Firma angepasst werden.
Warum sollte es für eine Firma besser sein als für die andere z.b. Argumente
mit "p_" zu starten?
Ausserdem gibt es nahezu keinen mir bekannten .Net Code (Framework selbst,
diverse Open-Source und kommerzielle Produkte bzw. Tools, Samples bzw.
Arikel im Netz, Zeitschriften, ...) welche eine ungarische Notation im .Net
Umfeld verwendet. Warum ist naheliegend.
P.S.: Bei Member-Variablen bin ich auch der Meinung, dass sich diese von
lokalen Variablen bzw. Parametern unterscheiden sollten (bei uns mit einem
Underscore z.B. "_field"). Parameter und lokale Variablen sind IMO in deren
Verhalten sehr änlich (z.B. Gültigkeit). Eine Unterscheidung ist IMO nicht
erfolderlich. Zu Typ-Prefixen habe ich mich bereits geäussert.
mfg GP
Frank Dzaebel
> "[...]verwenden Sie camelCasing [...] für Parameter, lokale Variablen und
> die privaten oder geschützten Variablen einer Klasse[...]"
>
> Mit anderen Worten, die Empfehlung sagt, man soll gar keine äußerliche
> Unterscheidung zwischen Membervariablen, Parametern und lokalen Variablen
> machen?!? Wie gesagt, das wird zwangsläufig zu Fehlern führen, die - je
> nach Größe des Projekts/der Klassen - schwer aufzuspüren sind.
Nein, wenn es tatsächlich ggf. unklar wäre, würde man
this.meineMemberVariable
benutzen. Ist es meistens allerhöchstens in Konstruktoren.
Also, das ist schon wohl durchdacht von MS.
http://groups.google.com/group/microsoft.public.de.german.entwickler.dotnet.csharp/msg/96bae222fd79ed35
>> Da auch MS noch viele C++ Entwickler hatte, war die
>> Umstellung damals auf CamelCase bei den MemberVariablen
>> auch nicht ohne Gegner und man sieht heutzutage immernoch
>> vereinzelt ungarische Notationen selbst bei C#.
>>
> Das war es, was ich meinte. Ich habe hier in der NG schon öfter gesehen,
> dass speziell das "m_" nicht sehr verpönt ist unter den C#-Entwicklern.
Sagen wir so, es gibt noch (geschätzt) ~5% die das noch
bei C# machen, obwohl sie die Empfehlungen kennen. Das sind
u.a. auch Profis. Das gibt's bei MS auch. Ich habe
sogar im Orcas-Designer noch ein m_* gesehen. Mal sehen,
wie's bei der Beta1 ist.
> PS: Interessant übrigens der Satz von Krzysztof Cwalina:
> "Yes, we try not to get into the business of defining guidelines for
> non-public visible identifiers. There is just too much personal taste
> involved here and the consistency argument is not as strong."
Ja, deswegen auch der Rahmen "Empfehlung" im
Gegensatz zu den Richtlinien.
Herfried K. Wagner [MVP]
"Marc Weichhold" <sp...@mailfolder.de> schrieb:
>> result_type result_code calculate_social_security_number(person
>> citizen,bool checked_local_insurance_state, exception_flags flags);
>>
>> ist ERHEBLICH schwerer zu lesen als z.B.
>>
>> ResultType resultCode calculateSocialSecurityNumber( Person citizen, bool
>> checkedLocalInsuranceState, ExceptionFlags flags );
>>
> Da gebe ich Dir uneingeschränkt recht.
>
> Daher ist "m_" auch als eine der wenigen Ausnahmen, bei denen wir
> Unterstriche zulassen in unserer NK. Ansonsten sind bei uns die
> Unterstriche ebenfalls "verboten".
Das halte ich für sinnvoll. Ich setze den Unterstrich auch nur in diesem
Fall und bei Methoden zur Ereignisbehandlung ein (wenn man von PInvoke u.ä.
absieht).
> Ganz sooo objektiv kann man also nicht behaupten "m_" sei "böse".
> Allgemein kann man vielleicht aus den von Dir genannten Gründen nur stark
> empfehlen, die Nutzung von Unterstrichen ganz stark einzuschränken, aber
> die Feinheiten müssen meiner Meinung nach eben an die Gegebenheiten in der
> jeweiligen Firma angepasst werden.
Ich bin der Ansicht, dass ein Präfix wie 'm_' rein praktischen Charakter
hat, nämlich die Vermeidung von Namenskollisionen (sowohl technischer als
auch visueller Natur). Der Typ einer Variable ist m.E. nicht sinnvoll im
Bezeichner aufgehoben, sofern man es mit einer Programmiersprache wie C# und
VB.NET mit 'Option Strict On' zu tun hat.
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>
Herfried K. Wagner [MVP]
"Paul Werkowitz" <newsg...@primaprogramm.de> schrieb:
>>> Wenn es im Programm tausend labels gibt, ist lbl durchaus OK. label
>>> bring
>>> t dann nicht mehr Information. FirstName mit FName abzukürzen halte ich
>>> auch für nicht gut. Regel: Immer erst die Vokale wegnehmen - die
>>> enthalten
>>> am wenigsten Information.
>>>
>> N, dnn wrst D j kn Prblm hbn, dsn Txt z vrsthn.
>
> Habe ich in der Tat nicht, und jeder wird das lesen können - wenn auch mit
> Mühe. Denn das Hauptproblem bei diesem Satz ist, dass die Eintzelteile nur
> durch Betrachtung des Ganzen ihren Sinn enthüllen. Oder kannst du mir
> sagen, was mit "N" oder "z" gemeint ist, ohne den Satz zu sehen?
Für mich sind Präfices bei Steuerelementen eher Symbole, deren Bedeutung man
einmal lernen muss (z.B., dass 'dgvw' für 'DataGridView' steht).
Herfried K. Wagner [MVP]
"Günter Prossliner" <g.prossliner/gmx/at> schrieb:
>> Und 'a' für Array (bei uns). Insofern ist in unserem Fall (und es
>> ging ja um eine an die jeweiligen Umstände angepasste Notation) "m_"
>> bzw. "p_" (für Parameter) die bessere Wahl.
>
> Heissen dann die Funktionen z.B.:
>
> public void Foo(int[] p_aiNumbers, p_bFlag){ ... } ?
>
> Ist IMO zu der offiziellen MS Konvention
>
> public void Foo(int[] numbers, bool flag) { ... }
>
> sehr unlesbar. Die zahlreichen Prefixe ziehen die Aufmerksamkeit auf sich,
> obwohl die Information ja in C# ohnehin immer vor dem Bezeichner befindet.
Ohne jetzt für die gezeigte Konvention sprechen zu wollen, aber der "Nutzen"
der Präfices wird ja erst dann ausgespielt, wenn auf den Parameter/die
Variable innerhalb einer Implementierung zugegriffen wird. Die Präfices
erleichtern es (könnte man argumentieren), sofort zu erkennen, um welche
Variable mit welchen Eigenschaften es sich handelt.
> Ausserdem "verunstalten" diese Prefixe die öffentliche Schnittstelle. Hat
> in streng typisierten Sprachen IMO keinen Mehrwert.
Das sehe ich auch so (bezogen auf Typpräfices).
> P.S.: Bei Member-Variablen bin ich auch der Meinung, dass sich diese von
> lokalen Variablen bzw. Parametern unterscheiden sollten (bei uns mit einem
> Underscore z.B. "_field"). Parameter und lokale Variablen sind IMO in
> deren Verhalten sehr änlich (z.B. Gültigkeit).
Man könnte aber argumentieren, dass sie dies nicht in ihren Eigenschaften
sind (Veränderbarkeit: 'ref', 'out' etc.; Werttyp vs. Verweistyp) und es
deshalb wichtig ist, ihnen das auch anzusehen.
Dennoch teile ich die Ansicht, dass die Typpräfices nicht sinnvoll sind und
eine Unterscheidung zwischen Parameter und lokaler Variable nicht unbedingt
im Bezeichner codiert werden muss. Moderne Entwicklungsumgebungen erlauben
es, die Information über andere Wege rasch zu erhalten (Farbcodierung,
kleine Symbole, ToolTips etc.).
Herfried K. Wagner [MVP]
"Marc Weichhold" <sp...@mailfolder.de> schrieb:
>> Die offizielle *Empfehlung* lautet auf *CamelCase*.
>> Auch für Membervariablen. Dennoch ist es immernoch
>> im Rahmen einer Empfehlung (keiner Richtlinie).
Meine Empfehlung lautet anders :-).
>> CamelCase sieht etwa so aus:
>>
>> public class MyClass
>> {
>> private int meineVariable;
>> }
>>
>> [Qualitätssicherung für verwalteten Sourcecode]
>> http://www.microsoft.com/germany/msdn/library/net/QualitaetssicherungFuerVerwaltetenSourcecode.mspx
Nicht schon wieder!
> Hmm, also ich weiß nicht ob diese Empfehlung sich in der Praxis bewährt
> hat/bewähren kann, denn ich halte sie für extrem fehleranfällig. Ich
> zitiere mal den entscheidenden Satz aus der Empfehlung:
>
> "[...]verwenden Sie camelCasing [...] für Parameter, lokale Variablen und
> die privaten oder geschützten Variablen einer Klasse[...]"
Das obengenannte Dokument kannst du hinsichtlich der getroffenen Aussagen zu
Benennungskonventionen grossteils vergessen (Begründung:
<URL:http://groups.google.de/group/microsoft.public.de.german.entwickler.dotnet.csharp/msg/8186592b6e9b476f>).
> Mit anderen Worten, die Empfehlung sagt, man soll gar keine äußerliche
> Unterscheidung zwischen Membervariablen, Parametern und lokalen Variablen
> machen?!? Wie gesagt, das wird zwangsläufig zu Fehlern führen, die - je
> nach Größe des Projekts/der Klassen - schwer aufzuspüren sind.
Das sehe ich genau so. Schliesslich verwendet kaum jemand durchgehend
'this.<Variablenname>'. Wenn dann noch dazu bei mehreren Bearbeitern eines
Codestücks 'this.foo' und 'foo' gemischt werden, könnte irrtümlich
angenommen werden, bei 'foo' handle es sich um eine lokale Variable, obwohl
ebenfalls die private Variable gemeint ist.
>> Bei privater Korrespondenz von mir mit Brad und Krzysztof,
>> wurde folgende Linie deutlich:
>> http://groups.google.com/group/microsoft.public.de.german.entwickler.dotnet.csharp/msg/96bae222fd79ed35
>>
>> Da auch MS noch viele C++ Entwickler hatte, war die
>> Umstellung damals auf CamelCase bei den MemberVariablen
>> auch nicht ohne Gegner und man sieht heutzutage immernoch
>> vereinzelt ungarische Notationen selbst bei C#.
>>
> Das war es, was ich meinte. Ich habe hier in der NG schon öfter gesehen,
> dass speziell das "m_" nicht sehr verpönt ist unter den C#-Entwicklern.
Eine optische Unterscheidbarkeit zwischen lokalen Variablen bzw. Parametern
und privaten Variablen ist offensichtlich in der Praxis von Bedeutung.
'this' ist hier nicht sehr hilfreich, da nicht erzwungen werden kann, dass
auf private Variablen über 'this.' zugegriffen wird. Deshalb werden Präfices
genutzt, die immer sichtbar sind, wenn die Variable im Spiel ist. Dass
häufig 'm_' zum Einsatz gelangt, ist sicher historisch zu sehen -- der
Buchstabe "m" hat hier keine besondere Bedeutung; genausogut könnte man 'x_'
schreiben.
Marc Weichhold
> Dass häufig 'm_' zum Einsatz gelangt, ist sicher historisch zu sehen --
> der Buchstabe "m" hat hier keine besondere Bedeutung; genausogut könnte
> man 'x_' schreiben.
>
Marc
Marc Weichhold
> OK, dann machst du eine Güterabwägung, bei der für euch die Vorteile
> überwiegen. Das ist OK, hat aber mit *objektiv* - und darauf bezieht sich
> meine Aussage - nichts zu tun.
>
> Wie ich am Beispiel der C++ Standardlib erläutert habe, kann man durchaus
> zu dem Ergebnis kommen, dass Unterstriche OK sind. Dann spielen aber
> andere
> Gründe eine Rolle.
>
Gut, so gesehen hast Du recht.
> IMO sollten Typen nicht im Namen kodiert werden. Ob es struct, eine class,
> ein enum oder array ist, hat in dern Namenskonvention nichts zu suchen
> (ich
> meine jetzt nicht die Singular/Plural/Verb/Hauptwort-Geschichte). a für
> array - und was nehmt ihr für enums?
>
e natürlich. :-)
Bei uns werden halt die Typen mit kodiert, angelehnt an die ungarische
Notation (Applications, nicht Systems). Ist historisch bedingt, weil einige
nur seeeehr schwer davon zu überzeugen waren, ihren emacs gegen eine moderne
IDE einzutauschen. Und als alle dann endlich VS benutzten, sahen wir nicht
wirklich einen Grund, unsere Konvention über den Haufen zu schmeißen und den
ganzen Code dahin gehend zu ändern.
> Umgekehrt wird ein Schuh draus: Ich habe objektive Kriterien genannt,
> warum
> UNterstriche nicht in Bezeichnern auftauschen sollen. Persönliche
> Vorlieben, Historie, Firmenkultur und eine große Reihe weiterer Gründe
> können dazu führen, dass man es dann doch anders macht - das ist OK.
>
So kann man es auch sehen, stimmt.
> Insofern ist gegen m_ nichts einzuwenden. Bei uns ist das aber definitiv
> keine Option.
>
Darum ging es ja eben ursprünglich. Kaum eine Regel/Empfehlung passt 100%ig
auf alle, die damit arbeiten müssen. Wenn es bei euch nicht passt (und bei
vielen, vielen anderen sicherlich auch nicht), dann werdet ihr eben eure
eigene NK verwenden, vielleicht sogar die von MS empfohlene. Da ist nichts
gegen einzuwenden. Blöd ist halt nur, wenn jeder Mitarbeiter eine andere
verwendet.
Marc
Marc Weichhold
Ich antworte mal hier für die anderen Posts vpn euch mit, da ich mich sonst
nur wiederholen würde.
> Heissen dann die Funktionen z.B.:
>
> public void Foo(int[] p_aiNumbers, p_bFlag){ ... } ?
>
> Ist IMO zu der offiziellen MS Konvention
>
> public void Foo(int[] numbers, bool flag) { ... }
>
> sehr unlesbar. Die zahlreichen Prefixe ziehen die Aufmerksamkeit auf sich,
> obwohl die Information ja in C# ohnehin immer vor dem Bezeichner befindet.
> Ausserdem "verunstalten" diese Prefixe die öffentliche Schnittstelle. Hat
> in streng typisierten Sprachen IMO keinen Mehrwert.
>
Es sind zwei Dinge. Erstens der p_-Präfix. Im Prinzip kann man hier genauso
argumentieren wie beim m_-Präfix. Es wird hier die Gefahr verringert, eine
als Parameter deklarierte Variable lokal falsch zu benutzen, wobei im
Gegensatz zur Membervariable bei der erneuten Deklaration einer lokalen
Variable natürlich der Compiler schon meckern würde. Aber auf diese Art und
Weise kommt es gar nicht so weit. Ich weiss, das ist kein starkes Argument
und ich möchte diese Art und Weise auch keinesfalls propagieren.
Anders sieht es dabei aber schon bei der Implementierung aus (vor allem
auch, wie Herfried erwähnte bei out- und ref-Parametern). Klar, Funktionen,
die so lang sind, dass sie nicht auf eine Bildschirmseite passen, sollte man
evtl. neu strukturieren, aber es passiert eben zu häufig, dass man bei der
Implementierung eben erst wieder "hoch" scrollen müsste, um zu sehen, wie
jetzt dieser blöde out-Parameter heißt (das, was ich bei Delphi immer
gehasst habe: Variablendeklaration nur am Anfang der Funktion). Auf "unsere"
Weise tippe ich "p_" ein, und lasse mir mit IntelliSense alle Parameter der
Funktion anzeigen. Bequeme Sache.
Die Typ-Präfixes haben noch einen anderen Hintergrund. Zum einen gibt es bei
uns eben etliche C++-Programmierer, die mit der ungarischen Notation
(Applications) "groß" geworden sind (Da zähle ich auch zu). Wir möchten uns
gar nicht wirklich umgewöhnen, wenn es nicht sein muss. Zum anderen gibt es
bei uns Leute, denen wir in einer Nach-und-Nebel-Aktion ihren emacs vom
System deinstallieren mussten, um sie dazu zu kriegen, eine moderne IDE zu
benutzen. ;-)
Als es soweit war, dass nun alle das VS benutzen, war der Code schon sehr
weit fortgeschritten und jetzt eine neue NK zu benutzen und den ganzen Code
zu ändern, dazu fehlen uns die finanziellen Mittel, vor allem weil der
Nutzen in keinem Verhältnis steht. Bei uns funktioniert das Ganze so wie ich
es beschrieben habe und es funktioniert gut.
> Ausserdem gibt es nahezu keinen mir bekannten .Net Code (Framework selbst,
> diverse Open-Source und kommerzielle Produkte bzw. Tools, Samples bzw.
> Arikel im Netz, Zeitschriften, ...) welche eine ungarische Notation im
> .Net Umfeld verwendet. Warum ist naheliegend.
>
Wie gesagt, ich möchte keinesfalls die ungarische Notation als das
Non-Plus-Ultra hinstellen. Die Gründe weshalb wir sie benutzen habe ich
genannt. Und ich kann aus Erfahrung sagen, dass sie auch in C# funktioniert
(vielleicht mit ein paar kleinen Abweichungen, ich möchte nicht behaupten,
dass wir sie penibel genau nach Definition benutzen, bei uns ist der
integer-Typ z.B. n und nicht i).
Marc
Marc Weichhold
> Schreibe ich jedoch in einer Software zur Flugplanbearbeitung 1000 mal
>
> ETA
>
> anstelle von
>
> EstimatedTimeOfArrival
>
> ist schon die Frage, was günstiger ist. Insbesondere sagt auch jeder
> Piloteur ETA und nicht die Langform.
>
Fachgebiet zutreffen. Würdest Du Deinen Code von einem branchenfremden
Menschen reviewen lassen, würde er nichts mit ETA anzufangen wissen. Auch
bei uns gibt es gängige Abkürzungen, die wir allerdings nur untereinander
und in der Kommunikation mit unserer Kundschaft verwenden. Weißt Du, was
eine Variable mit dem Namen "PTU" bedeuten könnte? Ich schätze mal nicht,
selbst wenn Du wüsstest, dass unsere Software externe Hochkeistungskameras
steuert, um Bilder aufzunehmen und zu verarbeiten. Heißt die Variable
"ProgrammableTimeUnit" kannst Du Dir vielleicht schon denken, was diese
Variable bedeuten könnte.
Alles in allem halte ich es für sinnvoller, Namen auszuschreiben, wenn die
"Gefahr" besteht, dass Außenstehende den Code sehen (müssen). Und dank
IntelliSense kannst Du "EstimatedTimeOfArrival" genauso schnell "tippen" wie
"ETA".
Marc
Herfried K. Wagner [MVP]
"Marc Weichhold" <weic...@gmx.de> schrieb:
Eindeutig ist das nicht zu beantworten. In Classic VB wurde z.B. oft 'm_' im
Sinne von "auf _M_odulebene" (also für private Variablen in Formularen,
Modulen und Klassenmodulen) und 'g_' im Sinne von "_g_lobal" verwendet. Der
Präfix wurde je nach Kontext (Programmiersprache etc.) evtl. anders
interpretiert.
Frank Dzaebel
>> [Qualitätssicherung für verwalteten Sourcecode]
>> http://www.microsoft.com/germany/msdn/library/net/QualitaetssicherungFuerVerwaltetenSourcecode.mspx
> Das obengenannte Dokument kannst du hinsichtlich der getroffenen Aussagen
> zu Benennungskonventionen grossteils vergessen
Das ist falsch. Obiger Artikel erläutert die professionelle Ansicht
und Empfehlung. Er unterstreicht nur das, was immer schon in
den Richtlinien und Empfehlungen stand. Siehe auch einfach C# -
Spezifikation.
> 'this' ist hier nicht sehr hilfreich,
"this" ist hier der Standard und sehr simpel.
Meistens benötigt man es eh nicht, es ist nur ein
Hinweis, wie man dies verdeutlichen kann, nicht notwendig.
Es steht ja auch schon alles in der C# Spezifikation.
In der Praxis hat sich dies nicht als Fehler-anfällig
(Marcs Vermutung) erwiesen.
Herfried K. Wagner [MVP]
"Frank Dzaebel" <Po...@FranksSeite.de> schrieb:
>>> [Qualitätssicherung für verwalteten Sourcecode]
>>> http://www.microsoft.com/germany/msdn/library/net/QualitaetssicherungFuerVerwaltetenSourcecode.mspx
>> Das obengenannte Dokument kannst du hinsichtlich der getroffenen Aussagen
>> zu Benennungskonventionen grossteils vergessen
>
> Das ist falsch. Obiger Artikel erläutert die professionelle Ansicht
> und Empfehlung. Er unterstreicht nur das, was immer schon in
> den Richtlinien und Empfehlungen stand. Siehe auch einfach C# -
> Spezifikation.
Im Unterschied zu dir bin ich anscheinend nicht blind und vorbehaltlos
obrigkeitshörig, sondern reflektiere über meinen Standpunkt und jenen der
anderen. Warum der obengenannte Artikel "Murks" ist, habe ich bereits
begründet. Die Begründung hast du halt wieder einmal einfach entfernt:
>> 'this' ist hier nicht sehr hilfreich,
>
> "this" ist hier der Standard und sehr simpel.
Bitte zitiere künftig meine Beiträge nicht sinnentstellend. Insbesondere
ersuche ich dich, die Begründungen meiner Aussagen nicht zu entfernen, da
ich, offensichtlich im Gegensatz zu dir, meine Ansichten argumentativ zu
untermauern pflege.
> Meistens benötigt man es eh nicht
Genau das ist der Punkt. Der Compiler zwingt nicht, 'this.' zu schreiben, um
auf ein privates Feld zuzugreifen.
> es ist nur ein Hinweis, wie man dies verdeutlichen kann, nicht notwendig.
Genau deshalb (du hast ja meine Begründung gelöscht) ist 'this.' untauglich,
um als optisches Entscheidungskriterium zwischen gleichnamigen privaten und
lokalen Variablen zu dienen.
> Es steht ja auch schon alles in der C# Spezifikation.
Was? Worauf beziehst du dich? Auf 'this.'? Auf eine Benennungskonvention für
private Variablen?
> In der Praxis hat sich dies nicht als Fehler-anfällig
> (Marcs Vermutung) erwiesen.
Vielleicht nicht in deiner Praxis, weil die Fehler leider nicht
offensichtlich (lies: durch den Compiler erkennbar) sind.
Dass die genannte Regel (gleiche Namen für private und lokale Variablen) ein
Fehlerpotential erster Güte in sich birgt, liegt auf der Hand. Wenn man zwei
unterschiedliche Dinge so bezeichnen will, dass man sie auch unterscheiden
kann, dann wird man sinnvollerweise auch unterschiedliche Bezeichner wählen.
Die Verwendung der gleichen Bezeichner ist hier die /schlechtestmögliche/
Lösung.
Der Sinn eines Bezeichners ist es ja gerade, Dinge möglichst (eindeutig) zu
bezeichnen. Je spezifischer die Bezeichnung, desto besser (denn desto
eindeutiger und informationsreicher). Praktisches Beispiel: In einem
Unternehmen existiert ein Ordner für den Posteingang und einen für den
Postausgang, die beide die gleiche Farbe haben. Es ist sinnvoller, sie mit
"Posteingang" und "Postausgang" zu beschriften, als schlicht mit "Post".
Frank Dzaebel
> So kann man es auch sehen, stimmt.
>> Insofern ist gegen m_ nichts einzuwenden. Bei uns ist das aber definitiv
>> keine Option.
>>
> Darum ging es ja eben ursprünglich. Kaum eine Regel/Empfehlung passt
> 100%ig auf alle, die damit arbeiten müssen. Wenn es bei euch nicht passt
> (und bei vielen, vielen anderen sicherlich auch nicht), dann werdet ihr
> eben eure eigene NK verwenden, vielleicht sogar die von MS empfohlene. Da
> ist nichts gegen einzuwenden. Blöd ist halt nur, wenn jeder Mitarbeiter
> eine andere verwendet.
Eben, zwar in gewisser Weise noch im Rahmen, aber je nach
Aussmass eben kontraproduktiv. IMHO habt Ihr ein bisschen zu sehr
(lange) am alten System festgehalten. Eine graceful accommodation
ist bei Namenskonventionen eben ziemlich schwer möglich.
Hier ist ein kompletter Umstieg IMHO besser, klarer und einfacher.
Nun hast Du Dich ja über die Ansichten, Konventionen und
Empfehlungen ganz gut informiert und ich denke, ihr werdet
irgendwann ein paar produktive Meetings haben, um die
Konventionen Eurer Entwickler ggf. anzupassen. (ohne dabei
von einem bestimmten Ausmass zu reden).
Ist ist doch normal. Die Dinge sind in Bewegung.
Gottfried Lesigang
Für mich stand das "m" immer für "my" oder "mein". Sozusagen aus der
"subjektiven" Sicht einer Objektinstanz...
So lässt sich der Code auch recht gut lesen...
Ich habe allerdings den IMO völlig sinnlosen Unterstrich immer weggelassen.
Also "mVar" statt "m_Var".
In C# habe ich jetzt konsequent auf "camelCase" umgestellt. Bin aber noch
nicht restlos überzeugt.
Gerade in der alphabetischen Sortierung von Intellisense macht ein Präfix
Sinn. Solange man dort nicht (ähnlich dem PropertyGrid) Kategorien sieht,
finde ich es z.B. mühsam, die Exception-Klassen eines Namespaces zu suchen.
Hätten die alle ein "err" vorne dran, stünden sie hübsch beieinander...
(ähnlich für EventArgs, EventHandler, Attribute ...)
lg
Gottfried
P.S. Bei mir haben (in VB) lokal deklarierte Variablen immer ein "tmp"
vorne dran. So kann ich Kollisionen ausschließen und sehe sofort, was "out
of scope" läuft. In C# wäre das durch die verschachtelten Scopes nicht mehr
ganz so eindeutig...
--
Home: www.develes.net
Mail: gol /at/ develes /dot/ net
Access-FAQ: www.donkarl.com
Paul Werkowitz
> Das sehe ich genau so. Schliesslich verwendet kaum jemand durchgehend
> 'this.<Variablenname>'. Wenn dann noch dazu bei mehreren Bearbeitern eines
> Codestücks 'this.foo' und 'foo' gemischt werden, könnte irrtümlich
> angenommen werden, bei 'foo' handle es sich um eine lokale Variable, obwohl
> ebenfalls die private Variable gemeint ist.
>
Deckt sich mit meiner Erfahrung. Die this-Notation verwendet kaum jemand
durchgängig.
Was jedoch viel schlimmer ist, dass es bei Verwendung dieser Notation oft
zu Situationen kommen kann, in denen sowohl die Ausdrücke
foo
als auch
this.foo
syntaktisch korrekt sind. Das ist eine Fehlerquelle! Das wäre nicht weiter
schlimm - Fehler sind unvermeidlich. Was mich daran aber ärgert, ist die
Tatsache, dass man diese Fehlerklasse durch eine andere Namenskonvention
vollständig vermeiden könnte. Hier sollte Frank als Verfechter des
"Standards" aus theoretischer Sicht mal was zu sagen.
Wie bereits mehrfach gesagt, möchte ich auch hier nochmal wiederholen: Die
MS-Leute, obwohl exzellente Fachleute, kommen manchmal zu nicht
nachvollziehbaren Erkenntnissen. Das ging los damals mit ungarischer
Notation, geht weiter über die m_ - Namensgebung und hört bei der
Behandlung von Outlook-Attachments mit potentiell schädlichen Endungen auf.
Paule
Paul Werkowitz
Hallo Marc,
>
> Bei uns werden halt die Typen mit kodiert, angelehnt an die ungarische
> Notation (Applications, nicht Systems). Ist historisch bedingt, weil einige
> nur seeeehr schwer davon zu überzeugen waren, ihren emacs gegen eine moderne
> IDE einzutauschen. Und als alle dann endlich VS benutzten, sahen wir nicht
> wirklich einen Grund, unsere Konvention über den Haufen zu schmeißen und den
> ganzen Code dahin gehend zu ändern.
Das verlangt auch niemand. Aber mit diesr Einstellung zieht ihr auf ewig
alte Probleme in neue Entwicklungen mit hinein. Dies ist so ziemlich das
Schlimmste, was man machen kann. In (großen) Projekten muss man immer
Möglichkeiten finden, um neu aufzusetzen, aber trotzdem alte Sachen
verwenden zu können.
In eurem konkreten Fall gibts dann eben zwei Namenskonventionen im System.
Das ist vielleicht nicht optimal, aber immer noch besser als die
Alternative, alles immer mit dem alten System zu machen. Vielleicht stellt
ihr mal auf ein anderes Logging um, verwendet in einem neu zu erstellenden
Teil mal andere, neue Controls etc. Das kann ja auch alles parallel zum
alten Bestand laufen.
Weiterer Punkt am Rande: zugekaufte Bibliotheken etc. verwenden häufig
andere Konventionen, als in der eigenen Firma verwendet. Es ist
normalerweise überhaupt kein Problem, damit zurecht zu kommen. Die
Verwendung einer einzigen Konvention im gesamten Projekt ist IMO nicht
erforderlich. Ich erwarte von einem Entwickler, dass er mit mehreren
Konventionen umgehen kann.
Paule
Paul Werkowitz
> Eben, zwar in gewisser Weise noch im Rahmen, aber je nach
> Aussmass eben kontraproduktiv. IMHO habt Ihr ein bisschen zu sehr
> (lange) am alten System festgehalten. Eine graceful accommodation
> ist bei Namenskonventionen eben ziemlich schwer möglich.
Wieso? Ab einem nestimmten Zeitpunkt nimmt man halt eine Neue. Die alte
bleibt ja weiterhin lesbar. Es braucht halt ein wenig Zeit und
Konzentration seitens der Entwickler, eine neue Konvention zu verwenden.
Ich selbst habe das in unterschiedlichen Firmen häufig selbst erlebt -
musste mich eben eingewöhnen. Wie bereits gesagt, stellen mehrere
Konventionen in einem System kein Negativmerkmal dar - wenn man die
Alternativen korrekt bewertet.
> Hier ist ein kompletter Umstieg IMHO besser, klarer und einfacher.
Und wer bitte bezahlt das? Frank, die Aussage ist sicher korrekt, aber doch
völlig weltfremd. Ich kenne keine Projektleitung, die für das Umformatieren
von Quellcode ("Verschönern") auch nur einen Penny rausgibt.
Paule
Paul Werkowitz
Hallo Marc,
> Das sind dann aber ganz spezielle Abkürzungen, die nur auf das jeweilige
> Fachgebiet zutreffen. Würdest Du Deinen Code von einem branchenfremden
> Menschen reviewen lassen, würde er nichts mit ETA anzufangen wissen.
Jo, aber das ist auch nicht gefordert. Für Branchenfremde erscheint unser
Code weitgehend sinnfrei. Wer in einem Flugleitplansystem an Code etwas
ändert, wo ETA vorkommt, sollte wissen, was er tut....
>Auch
> bei uns gibt es gängige Abkürzungen, die wir allerdings nur untereinander
> und in der Kommunikation mit unserer Kundschaft verwenden. Weißt Du, was
> eine Variable mit dem Namen "PTU" bedeuten könnte? Ich schätze mal nicht,
> selbst wenn Du wüsstest, dass unsere Software externe Hochkeistungskameras
> steuert, um Bilder aufzunehmen und zu verarbeiten.
Gleiches Argument wie oben. Ich könnte nichts Sinnvolles and er Software
ändern.
>Heißt die Variable
> "ProgrammableTimeUnit" kannst Du Dir vielleicht schon denken, was diese
> Variable bedeuten könnte.
Trotzdem könnte och dann immer noch nichts machen. Was ich bräuchte, wäre
eine Schulung etc. in dem Gebiet. Wenn ich ausreichend Wissen angesammelt
habe, um eure SW sinnvoll bearbeiten zu können, wüsste ich auch über PTUs
Bescheid, und ich würde sofort die Abkürzungen verwenden.
> Alles in allem halte ich es für sinnvoller, Namen auszuschreiben, wenn die
> "Gefahr" besteht, dass Außenstehende den Code sehen (müssen). Und dank
> IntelliSense kannst Du "EstimatedTimeOfArrival" genauso schnell "tippen" wie
> "ETA".
Stimmt, aber das ist völlig irrelevant. Quelltext wird viel häufiger
gelesen als geschrieben, und wir sollten daher wesentlich mehr Augenmerk
auf Lesbarkeit legen - zumal das Schreiben dank Intellisense eh problemlos
ist.
Beim Lesen von Wortwürmern muss man sich erheblich mehr konzenktrieren als
bei Abzürzungen. Wer sieht schon nach 10h konzentrierter Arbeit sofort den
Unterschied zwischen EstimatedTimeOfArrival und EstimatedTimeToArrival?
Wenn du alles ausschreiben möchtest, dann hälst du sicher auch
void f()
BEGIN_FUNCTION_BODY
return;
END_FUNCTION_BODY
für aussagekräftiger als
void f()
{
return;
}
(So eine Syntax gibts in der Tat!)
Die geschweiften Klammern sind nichts als Abkürzungen.... Klarer wäre es
schon, wenn man hinschreiben würde, was die gerade bedeuten.
Paule
Frank Dzaebel
> Was jedoch viel schlimmer ist, dass es bei Verwendung dieser Notation oft
> zu Situationen kommen kann, in denen sowohl die Ausdrücke
> foo
> als auch
> this.foo
> syntaktisch korrekt sind. Das ist eine Fehlerquelle! Das wäre nicht weiter
> schlimm - Fehler sind unvermeidlich. Was mich daran aber ärgert, ist die
> Tatsache, dass man diese Fehlerklasse durch eine andere Namenskonvention
> vollständig vermeiden könnte. Hier sollte Frank als Verfechter des
> "Standards" aus theoretischer Sicht mal was zu sagen.
Sowohl in der Theorie als auch in der Praxis gibt es hier kein Problem.
Wie gesagt, der Compiler machts es hier richtig und this ist dann eigentlich
nur für Leute, die es gerne noch deutlicher sehen wollen.
Ich selber mach es in Konstruktoren auch mit this.
Aber mal angenommen, es gäbe eine "Fehler-Möglichkeit", so wäre normal
dessen Wahrscheinlich multipliziert mit dem Ausmass gegen die Auswirkungen
schlechterer Lesbarkeite, Verstoss gegen C# Spezifikations-Empfehlungen,
etc.
gegenüberzustellen.
> MS-Leute, obwohl exzellente Fachleute, kommen manchmal zu nicht
> nachvollziehbaren Erkenntnissen.
Nachvollziehbar bedeutet meist "über Doku zur Verfügung gestellt".
Manchmal ist da nicht genügend dokumentiert - mag sein.
Aber wenn man tiefere Einblicke hat, versteht man das
meistens. Vielleicht könnten einmal mehr Artikel über
die Entwurfsentscheidungen von MS kommen - sicher.
> Das ging los damals mit ungarischer Notation, geht
Vorsicht, Du musst unterscheiden. Unverwaltetes C++ ist halt
da nicht so einfach wie verwaltetes behandelbar mit der
Namenskonvention. Ich sprach es an.
Herfried K. Wagner [MVP]
"Frank Dzaebel" <Po...@FranksSeite.de> schrieb:
>> Was jedoch viel schlimmer ist, dass es bei Verwendung dieser Notation oft
>> zu Situationen kommen kann, in denen sowohl die Ausdrücke
>> foo
>> als auch
>> this.foo
>> syntaktisch korrekt sind. Das ist eine Fehlerquelle! Das wäre nicht
>> weiter
>> schlimm - Fehler sind unvermeidlich. Was mich daran aber ärgert, ist die
>> Tatsache, dass man diese Fehlerklasse durch eine andere Namenskonvention
>> vollständig vermeiden könnte. Hier sollte Frank als Verfechter des
>> "Standards" aus theoretischer Sicht mal was zu sagen.
>
> Sowohl in der Theorie als auch in der Praxis gibt es hier kein Problem.
Das ist eine Aussage ohne Beweis/untermauernde Argumente. Du solltest
wirklich dazu übergehen, deine Aussagen argumentativ zu untermauern.
> Wie gesagt, der Compiler machts es hier richtig und this ist dann
> eigentlich
> nur für Leute, die es gerne noch deutlicher sehen wollen.
Dass der Compiler die Regeln kennt (Verdeckung gleichnamiger Bezeichner)
steht ausser Zweifel.
Das Problem ist hier vielmehr der Mensch, der beim Lesen des Quellcodes
entscheiden muss, ob es sich bei 'userName' um eine private oder eine lokale
Variable handelt. Diese Unterscheidung ist sehr wichtig, um Code
nachvollziehen und verstehen zu können. Deshalb ist es naheliegend, optisch
eine Möglichkeit zur Unterscheidung einzuräumen.
Die Option, Zugriffe auf private Variablen durch ein vorangestelltes 'this.'
zu markieren, ist unzureichend, da 'this.' optional ist und das Mischen von
'userName' und 'this.userName' irrtümlich dazu verleiten könnte, anzunehmen,
bei 'userName' handle es sich um eine lokale Variable oder einen
Methodenparameter.
Die einzige Möglichkeit einer Lösung stellt die Wahl (optisch)
unterschiedlicher Bezeichner für private und lokale Variablen dar, z.B.
durch Voranstellen eines Präfixes wie '_' oder 'm_' (oder wie auch immer).
> Ich selber mach es in Konstruktoren auch mit this.
... und einmal versehentlich das 'this.' vergessen und der Fehler ist kaum
aufspürbar.
> Aber mal angenommen, es gäbe eine "Fehler-Möglichkeit"
Warum es die gibt, habe ich oben dargelegt.
> so wäre normal dessen Wahrscheinlich multipliziert mit dem Ausmass gegen
> die Auswirkungen
> schlechterer Lesbarkeite
Definiere "schlechtere Lesbarkeit" in diesem Zusammenhang. Wenn zwei
unterschiedliche Variablen unterschieden werden sollen, dann ist die Wahl
des gleichen Bezeichners wohl die für die Lesbarkeit/Unterscheidbarkeit
schlechtestmögliche Wahl.
> Verstoss gegen C# Spezifikations-Empfehlungen
Das ist m.E. überhaupt kein Kriterium, wenn sich die
"Spezifikations-Empfehlungen" (die es in diesem Fall gar nicht gibt) als
praktisch untauglich und gefährlich erwiesen haben.
>> MS-Leute, obwohl exzellente Fachleute, kommen manchmal zu nicht
>> nachvollziehbaren Erkenntnissen.
>
> Nachvollziehbar bedeutet meist "über Doku zur Verfügung gestellt".
> Manchmal ist da nicht genügend dokumentiert - mag sein.
> Aber wenn man tiefere Einblicke hat, versteht man das
> meistens.
Microsoft-Mitarbeiter sind keine Götter. Mit ein bisschen Einsatz des
eigenen Gehirns kann man über die Entscheidungen reflektieren. Wenn einem
dabei gravierende Nachteile der Entscheidungen Microsofts auffallen, dann
kann man davon ausgehen, dass Microsoft-Mitarbeiter nicht weit genug gedacht
haben. Auch das kommt vor.
Wie bereits Immanuel Kant sagte: "Habe Mut, dich deines eigenen Verstandes
zu bedienen!".
>> Das ging los damals mit ungarischer Notation, geht
>
> Vorsicht, Du musst unterscheiden. Unverwaltetes C++ ist halt
> da nicht so einfach wie verwaltetes behandelbar mit der
> Namenskonvention. Ich sprach es an.
Ich nehme an, das war nicht der Punkt von Pauls Aussage (du hast schon
wieder unzulässigerweise weggestrichen).
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
Frank Dzaebel
hattest Du Dir hier verscherzt. Aber mit den anderen
rede ich hier gerne, da hier keine so unqualifizierten
Ausdrücke herauskommen (siehe andere Postings).
ciao Frank
Paul Werkowitz
Hallo Frank,
> Hallo Paul,
>
>> Was jedoch viel schlimmer ist, dass es bei Verwendung dieser Notation oft
>> zu Situationen kommen kann, in denen sowohl die Ausdrücke
>> foo
>> als auch
>> this.foo
>> syntaktisch korrekt sind. Das ist eine Fehlerquelle! Das wäre nicht weiter
>> schlimm - Fehler sind unvermeidlich. Was mich daran aber ärgert, ist die
>> Tatsache, dass man diese Fehlerklasse durch eine andere Namenskonvention
>> vollständig vermeiden könnte. Hier sollte Frank als Verfechter des
>> "Standards" aus theoretischer Sicht mal was zu sagen.
>
> Sowohl in der Theorie als auch in der Praxis gibt es hier kein Problem.
Ich weiß nicht.... das ist Ansichtssache. Ich möchte nunmal nicht, dass
this.foo und foo was anderes ist oder auch nur sein kann. Zu leicht kann
man da durcheinander geraten. Wenn das für dich OK ist - einige deiner
Ansichten kann ich eben nicht nachvollziehen (siehe das Thema über
databinding) - aber das ist selbstverständlich OK.
> Wie gesagt, der Compiler machts es hier richtig und this ist dann eigentlich
> nur für Leute, die es gerne noch deutlicher sehen wollen.
Der Compiler machts immer richtig - die Kunst ist aber, das er auch das
Offensichtliche (und damit meist das Gewünschte) tut. Es ist einfach
unschön, dass ich mir erst die Parameter der Funktion ansehen muss sowie
alle lokalen Variablen über mir, bis ich weiß, was foo gerade bedeutet.
Wenn foo und this.foo zwei unterschiedliche Dinge sind, hat die Notation
mit "deutlicher sehen" nichts zu tun, sondern mit Semantikänderung.
> Ich selber mach es in Konstruktoren auch mit this.
Und in setter/getter? In Funktionen mit Parametern?
>
> Aber mal angenommen, es gäbe eine "Fehler-Möglichkeit", so wäre normal
> dessen Wahrscheinlich multipliziert mit dem Ausmass gegen die Auswirkungen
> schlechterer Lesbarkeite, Verstoss gegen C# Spezifikations-Empfehlungen,
> etc.
> gegenüberzustellen.
>
Absolut korrekt. Dies muss man gegenüberstellen, und offensichtlich kommen
unterschiedliche Leute zu unterschiedlichen Ergebnissen. Hier gibt es wohl
noch keinen state of the art oder best practice. Nur weil MS das so macht,
muss das nicht gut sein. Die "C# Spezifikations-Empfehlungen" haben so ihre
Probleme.
>
>> MS-Leute, obwohl exzellente Fachleute, kommen manchmal zu nicht
>> nachvollziehbaren Erkenntnissen.
>
> Nachvollziehbar bedeutet meist "über Doku zur Verfügung gestellt".
> Manchmal ist da nicht genügend dokumentiert - mag sein.
Wenn jemand Mist macht und dies gut dokumentiert, ist das nachvollziehbar.
Richtig. Ich meinte hier was Anderes (vielleicht fehlt mir der richtige
Begriff): Ich wollte sagen: Bei gegebener Problemstellung komme ich zu ganz
anderen Ergebnissen, dann ist die Denke meines Vordenkers für mich nicht
nachvollziehbar.
> Aber wenn man tiefere Einblicke hat, versteht man das
> meistens. Vielleicht könnten einmal mehr Artikel über
> die Entwurfsentscheidungen von MS kommen - sicher.
>
In der Tat, da dürfte man gespannt sein. Ich frage mich wirklich, wie man
diese "this." - Konvention dann begründet.
>
>> Das ging los damals mit ungarischer Notation, geht
>
> Vorsicht, Du musst unterscheiden. Unverwaltetes C++ ist halt
> da nicht so einfach wie verwaltetes behandelbar mit der
> Namenskonvention. Ich sprach es an.
Jo, ich erinnere mich. Ich bat aber auch darum, hier mal ein Beispiel zu
nennen. Du gibst die Meinung von
http://www.microsoft.com/germany/msdn/library/net/QualitaetssicherungFuerVerwaltetenSourcecode.mspx
wieder. Dort steht aber auch nicht, warum man zwischen verwaltetem und
unverwaltetem Code Unterschiede machen sollte (die Allgemeinplätze bzgl.
Reflection etc. lassen wir mal weg).
> Vorsicht, Du musst unterscheiden. Unverwaltetes C++ ist halt
> da nicht so einfach wie verwaltetes behandelbar mit der
Was muss ich da unterscheiden? Sags halt, aber ich verstehe schon: In dem
MS-Artikel steht es eben *nicht* drin....
Grüße - Paule
Herfried K. Wagner [MVP]
Kein Problem, du bist eben diskursunfähig.
Marc Weichhold
> Jo, aber das ist auch nicht gefordert. Für Branchenfremde erscheint unser
> Code weitgehend sinnfrei. Wer in einem Flugleitplansystem an Code etwas
> ändert, wo ETA vorkommt, sollte wissen, was er tut....
>
Ich bin mir nicht sicher, ob Consulting-Firmen, die beauftragt werden, ein
externes Code-Review zu machen, tatsächlich branchennah sein müssen bzw.
vorher geschult werden. Eine wesentliche Vorraussetzung wäre da eine Doku IM
Code, die sagt, was eine Funktion machen soll usw.
> Wenn du alles ausschreiben möchtest, dann hälst du sicher auch
>
> void f()
> BEGIN_FUNCTION_BODY
> return;
> END_FUNCTION_BODY
>
> für aussagekräftiger als
>
> void f()
> {
> return;
> }
>
> (So eine Syntax gibts in der Tat!)
> Die geschweiften Klammern sind nichts als Abkürzungen.... Klarer wäre es
> schon, wenn man hinschreiben würde, was die gerade bedeuten.
>
Ja, und die Klammern (die ich allerdings trotz des folgenden Problems
bevorzuge) führen zu Code-Schnipseln wie:
...
} // end of if(...)
} // end of for(...)
} // end of wasweißich
also doch wieder dazu, dass diese Abkürzungen ausführlich beschrieben werden
(müssen).
Im Übrigen finde ich es ziemlich "unfair" von Dir, Abkürzungen von
Variablennamen mit derartigen "Abkürzungen" aus der Syntax der Sprache zu
vergleichen. Geschweifte Klammern versteht eben jeder C/C++/C#
Programmierer, ETA, PTU, u.ä. eben nicht. Das ist also schon ein
Unterschied.
Marc
Paul Werkowitz
Hallo Marc,
> Ich bin mir nicht sicher, ob Consulting-Firmen, die beauftragt werden, ein
> externes Code-Review zu machen, tatsächlich branchennah sein müssen bzw.
> vorher geschult werden. Eine wesentliche Vorraussetzung wäre da eine Doku IM
> Code, die sagt, was eine Funktion machen soll usw.
Was soll den eine Firma machen, die vom Business keine Ahnung hat? Die kann
höchstens markern, dass Variablen public sind und besser als Properties
ausgeführt werden sollten (eh fragwürdig). Solche formalen Dinge können
besser von Prüfprogrammen erledigt werden, sofern man dem eine Bedeutung
beimisst (was mir bei einem Auftraggeber suspekt wäre).
Habe in meinem Consulting-Leben bisher erst einmal eine Firma gehabt
(Siemens), bei der ein externes Codereview durchgeführt wurde. Das war aber
15 Jahre her, und damals floss das Geld üppiger als heute. Wer macht sowas?
Höchstens sicherheitskritische Bereiche (Militär, Kernkraftwerk), und da
gelten eh andere Vorschriften.
>
>> Wenn du alles ausschreiben möchtest, dann hälst du sicher auch
>>
>> void f()
>> BEGIN_FUNCTION_BODY
>> return;
>> END_FUNCTION_BODY
>>
>> für aussagekräftiger als
>>
>> void f()
>> {
>> return;
>> }
>>
>> (So eine Syntax gibts in der Tat!)
>> Die geschweiften Klammern sind nichts als Abkürzungen.... Klarer wäre es
>> schon, wenn man hinschreiben würde, was die gerade bedeuten.
>>
> Ja, und die Klammern (die ich allerdings trotz des folgenden Problems
> bevorzuge) führen zu Code-Schnipseln wie:
>
> ...
> } // end of if(...)
> } // end of for(...)
> } // end of wasweißich
>
> also doch wieder dazu, dass diese Abkürzungen ausführlich beschrieben werden
> (müssen).
>
> Im Übrigen finde ich es ziemlich "unfair" von Dir, Abkürzungen von
> Variablennamen mit derartigen "Abkürzungen" aus der Syntax der Sprache zu
> vergleichen. Geschweifte Klammern versteht eben jeder C/C++/C#
> Programmierer, ETA, PTU, u.ä. eben nicht. Das ist also schon ein
> Unterschied.
Du bringst es auf den Punkt. Unfair ist es nicht, denn wir reden von
Abkürzungen, und ob man diese nehmen soll, oder nicht. Ich habe ein
Extrembeispiel gebracht, um die Argumentation glasklar zu machen.
Wenn man genauer darüber nachdenkt, ist es kein Unterschied ob ich
Sprachelemente abkürze, oder häufig gebrauchte Bezeichner. Genau so wie
BEGIN/END aus Pascal in den C-Sprachen durch geschweifte Klammern abgekürzt
werden, kann man ohne Bedeutungsverlust auch "number" zu "nbr", "offset" zu
"ofs" und "index" zu "idx" abkürzen. Eine genauere Überlegung liefert
sofort das Ergebnis, das man dann auch "Kundennummer" zu "KdnNr" abkürzen
darf.
Einige Regeln sind weitehin zu beachten, z.B. gilt, dass die
Möglichkeit/Notwendigkeit zur Benutzung einer Abkürzung mit der Häufigkeit
des Auftretens korreliert sein sollte. D.H. selten verwendete Namen
sollen/brauchen oder sogar dürfen nicht abgekürzt werden.
Ähnliches gilt für den Gültigkeitsbereich (bzw. Sichtbarkeitsbereich).
Hier mal ein Beispiel einer Sprache, in der Syntaxelemete im Klartest
ausgedrückt werden (Cobol, Quelle: Wikipedia):
Identification Division.
Program-ID. HALLOPGM.
Procedure Division.
Display "Hallo Wikipedianer!"
STOP RUN.
Ziel war es einmal, auch nicht-Programmierern die Erstellung von
Cobol-Programmen zu ermöglichen, und zwar dadurch, dass man sich beim
Quelltext möglichst an die Aussageform (Subjekt-Prädikat-Objekt) der
englischen Sprache hält: Cobol sollte man wie Englisch lesen (und
schreiben) können......
Ich denke nicht, dass das eine gute Idee war.
Kleine Anmerkung:
> ...
> } // end of if(...)
> } // end of for(...)
> } // end of wasweißich
Mache ich auch so, und halte das für äußerst nützlich.
Leider sehen das die vielgepriesenen Fachleute bei MS anders, denn sonst
hätten sie das automatische Generieren von Methondenrümpfen wie z.B.
Interfaceimplementierungen in VS2005 anders gelöst: Hat man nämlich etwa
als letzte Funktion
void f()
{
} // f
und lässt g einfügen, erhält man
void f()
{
}
void g()
{
} // f
d.h. der Einfügepunkt ist direkt hinter dem Ende der letzten Funktion *vor
dem Zeilenkommentar* .....
Noch was: "end of" ist redundant. Die schließende Klammer sagt das bereits.
Wir sollten in Kommentaren nicht die Syntax erklären.
Grüße - Paule