Namenskonventionen für Variablen, was benutzt ihr, was macht Sinn in c#
Michael Brockhoff
ich habe bisher für member Variablen immer den Präfix
m_ benutzt.
Jetzt hab ich z.B. das Petzold Buch da wird mein spezieller Präfix für
Member variablen benutzt nur Variablen Typ spezifisch wie z.B. str für
string usw.
In anderen Büchern hab ich schon öfter nur so etwas gesehen z.B: _strTest.
Das find ich auch nicht schlecht was mich dabei stört ist das das
Visual Studio für member Variablen nicht auch etwas voranstellt ( wie m_ im
alten 6 Studio bei C++)
Was benutzt ihr, bzw. was haltet ihr für sinnvoll? Das man sich in einer
Firma möglichst an
eine Konvention halten sollte ist außer Frage
Gruß
Michael
Matthias Rusche
alles ziemlich obsolet. Siehe
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/ht
ml/cpconcapitalizationstyles.asp
Grüße, Matthias
"Michael Brockhoff" <bro...@gmx.net> schrieb im Newsbeitrag
news:#4MdIXddCHA.1540@tkmsftngp10...
Sam Jost
meine ganz persönliche Meinung dazu:
- Ich find einen Member Prefix sinnvoll (ich benutz d_, aber m_ ist auch
schick)
- einen static-prefix (s_) find ich auch gut für die Übersicht
- ich benutz ausserdem einen Parameter Prefix (P, ohne _). In get/set konnte
ich damit in C++ immer schön unterscheiden, zB:
void MeineFunktion( String PDateiname)
{
d_Dateiname= PDateiname;
}
(ich kenn aber sonst niemand der das macht)
mit den prefixes kann man immer schön sehen ob etwas eine lokale Variable,
eine globale (statische) Variable, ein Parameter oder ein Member ist was ich
recht hilfreich finde.
Bei C++ hab ich ausserdem Pointer kenntlich gemacht, mit kleinem p (zB
pMyPtr, d_pMyPtr oder PpMyPtr).
Das war aber eher unwichtig und ist aber mit .net wohl hinfällig.
Typ-Prefix wie es im Petzold vorgeschlagen wird find ich eher
nebensächlich - meist geht der Typ aus der Variable schon hervor
("Dateiname" wird kaum ein double sein), und zum anderen kann der Compiler
die prüfen, tippfehler werden also sehr wahrscheinlich gefunden.
Bei Verwechslungen und "nested scope-"Überdeclarierung von Member,
Parameter, statisch und lokal dagegen kann der Compiler nur wenig prüfen,
und da helfen Prefixes die zeigen wo der Kram herkam.
Daher versteh ich nicht warum Petzold die nicht mag (ich les das Buch auch
grad).
Den Form Designer hab ich bisher noch nicht benutzt, daher kann ich zu dem
nichts sagen. Wär natürlich schön wenn man dem Prefixes beipulen könnte.
Oder man schreibt sich doch mal einen Sourceparser der diese Dinge
entsprechend den eigenen vorlieben umwandeln und formatieren kann ;)
Ach ja, die Ideen für meine Prefixes kamen aus "Large Scale C++ Programming"
von John Lakos.
Gruss,
Sam
Joachim Fuchs
> alles ziemlich obsolet. Siehe
sehe ich genauso. Viel wichtiger ist es, aussagekräftige Name zu verwenden.
Den Definitionsort eines Symbols kann man in der Regel ganz gut über VS
erfahren.
Will man Membervariablen kennzeichnen, dann ist es meiner Meinung nach
sinnvoller, konsequent "this" bzw. "me" zu verwenden, als irgendwelche
Kürzel davor zu schreiben.
Eine Ausnahme mache ich allerdings dennoch: bei Steuerelementen verwende ich
gelegentlich doch einen Präfix. Aber auch das kann man durch geschickte
Namensvergabe umgehen.
Gruß
Joachim
Franz Knauseder
endlich jemand, der mir aus der Seele spricht!
Ich verwende ein kleines Präfix für den Scope und ja nichts für den Typ
(keine hungarian notation).
m Membervariablen,
l lokale Variablen (Laufindizes sind ausgenommen und dürfen durchaus i
heißen)
i Inputparameter (eigentlich a für Argument, will ich aber ändern)
o Outputparameter
r Referenzparameter
In C++ habe ich die zweite Stelle für
p Pointer
r Referenz
h Handle
verwendet, ist aber in C# obsolet.
In meiner letzten Firma hat das ziemlich gut funktioniert, in meiner
jetzigen werde ich bestenfalls belächelt, meistens ...
Die Notation "this.var" für Membervariablen wird nicht geprüft (Compiler).
Ein Variable var kann also sehr sowohl eine Membervariable sein.
Die Präfixes sollen/können "aussagekräftige Namen" nicht ersetzen.
Frage: Sollten aussagekräftige Namen auch den Scope/Verwendung beinhalten?
Warum liest man in Büchern so wenig darüber? Weil es heiß oder unwichtig
ist?
Franz
"Sam Jost" <sam....@b-soft.de> schrieb im Newsbeitrag
news:3daeb258$1...@olaf.komtel.net...
Thomas Scheidegger [MVP] NETMaster
[Da wird doch mehr geprüft als bei z.B. 'm_var' ]
> Frage: Sollten aussagekräftige Namen auch den Scope/Verwendung beinhalten?
Evtl. im Namen selber, aber nicht als Prefix.
Der MS Vorschlag ist eigentlich eindeutig, z.B.:
http://msdn.microsoft.com/library/en-us/cpgenref/html/cpconfieldusageguidelines.asp
"Do not apply a prefix to field names or static field names.
Specifically, do not apply a prefix to a field name to distinguish
between static and nonstatic fields.
For example, applying a g_ or s_ prefix is incorrect."
=> generell keine Prefixe (ausser I-Interface)
Hilfreich ist auch die Tabelle aus dem ECMA C# Std:
http://msdn.microsoft.com/net/ECMA/
Appendix C. Naming guidelines
Class PascalCase
Attribute Class PascalCase Has a suffix of Attribute
Exception Class PascalCase Has a suffix of Exception
Constant PascalCase
Enum type PascalCase
Enum values PascalCase
Event PascalCase
Interface PascalCase Has a prefix of I
Local variable camelCase
Method PascalCase
Namespace PascalCase
Property PascalCase
Public Inst.Field PascalCase Rarely used (use a property instead)
Prot. Inst.Field camelCase Rarely used (use a property instead)
Parameter camelCase
Mindestens wenn man eigene Komponenten
weiterverkaufen will, so sollte man wenigstens alle
sichtbaren Schnittstellen/Typen nach Guideline benennen.
--
Thomas Scheidegger - MVP .NET - 'NETMaster'
http://www.cetus-links.org/oo_dotnet.html - http://dnetmaster.net/
Kai-Uwe Klavei
"Michael Brockhoff" <bro...@gmx.net> schrieb im Newsbeitrag
news:#4MdIXddCHA.1540@tkmsftngp10...
> Hallo,
>
Hallo Michael.
> ich habe bisher für member Variablen immer den Präfix
> m_ benutzt.
>
m_Das m_sieht m_aber m_häßlich m_aus :-)
> Jetzt hab ich z.B. das Petzold Buch da wird mein spezieller Präfix für
> Member variablen benutzt nur Variablen Typ spezifisch wie z.B. str für
> string usw.
>
Dann doch lieber obj für object :-)
> In anderen Büchern hab ich schon öfter nur so etwas gesehen z.B: _strTest.
> Das find ich auch nicht schlecht was mich dabei stört ist das das
> Visual Studio für member Variablen nicht auch etwas voranstellt ( wie m_
im
> alten 6 Studio bei C++)
>
> Was benutzt ihr, bzw. was haltet ihr für sinnvoll? Das man sich in einer
> Firma möglichst an
> eine Konvention halten sollte ist außer Frage
>
Persönlich benutze ich keine Präfixe.
In der .NET SDK-Doku finden sich einige Seiten zu Benennung unter:
Referenz -
Entwurfsrichtlinien für die Entwicklung von Klassenbibliotheken -
Richtlinien für die Benennung
> Gruß
>
> Michael
>
Gruß Kai-Uwe
Franz Knauseder
(Compiler).
> Wie meinst Du dies?
Ich kann sowohl var als auch this.var schreiben. Schön wäre es, wenn der
Compiler bei var (als Membervariable) ein warning bringen würde.
> > Frage: Sollten aussagekräftige Namen auch den Scope/Verwendung
beinhalten?
>
> Evtl. im Namen selber, aber nicht als Prefix.
> Der MS Vorschlag ist eigentlich eindeutig, z.B.:
>
http://msdn.microsoft.com/library/en-us/cpgenref/html/cpconfieldusageguideli
nes.asp
>
> "Do not apply a prefix to field names or static field names.
> Specifically, do not apply a prefix to a field name to distinguish
> between static and nonstatic fields.
> For example, applying a g_ or s_ prefix is incorrect."
>
> => generell keine Prefixe (ausser I-Interface)
Der Vorschlag ist eindeutig, aber was sind die Überlegungen dahinter. Oder
einfacher gesagt, warum?
Franz
Stephan-Frank Henry
>
> "Michael Brockhoff" <schrieb im Newsbeitrag...
> > Hallo,
>
> Hallo Michael.
>
> > ich habe bisher für member Variablen immer den Präfix
> > m_ benutzt.
>
> m_Das m_sieht m_aber m_häßlich m_aus :-)
>
> > Jetzt hab ich z.B. das Petzold Buch da wird mein spezieller Präfix für
> > Member variablen benutzt nur Variablen Typ spezifisch wie z.B. str für
> > string usw.
>
> Dann doch lieber obj für object :-)
>
> > In anderen Büchern hab ich schon öfter nur so etwas gesehen z.B:
_strTest.
> > Das find ich auch nicht schlecht was mich dabei stört ist das das
> > Visual Studio für member Variablen nicht auch etwas voranstellt ( wie m_
> im
> > alten 6 Studio bei C++)
> >
> > Was benutzt ihr, bzw. was haltet ihr für sinnvoll? Das man sich in einer
> > Firma möglichst an
> > eine Konvention halten sollte ist außer Frage
> >
>
> Persönlich benutze ich keine Präfixe.
>
> In der .NET SDK-Doku finden sich einige Seiten zu Benennung unter:
> Referenz -
> Entwurfsrichtlinien für die Entwicklung von Klassenbibliotheken -
> Richtlinien für die Benennung
als alter Delphi & C/C++ programmierer finde ich es wichtig für
den Leser/Programmierer den Code verstehen zu können.
C#
Person person = new Person ();
Person person = Person (leiter);
da gefällt mir die Borland convention besser:
TPerson Person = new TPerson ();
TPerson Person = TPerson (Leiter);
imho:
Datentypen entsprechend kennzeichnen.
Klassen mit C
Enums mit E
Structs mit S
Members m
ect.
dann ist doch eher klar was Person ist odda?
im 2. C#-Beispiel, würde man den rechten Teil für sich ansehen, ist es total
unklar
was Person für ein Datentyp ist. Klar, fährt man mit der Maus drüber, sagts
einem die Ide.
Aber wer möchte schon mit seiner Maus alle vars abklappern nur um einen
Codeblock lesen zu können?
Auch finde ich das eine Mischung aus Camel und Pascal case zum unsauberen
Code verleitet und
ist es nicht immer klar wann was benutzt werden soll.
Wer kann jetzt sofort ohne nachzuschauen sagen wann was zu nehmen ist?
Ehrlich!
Im Grunde sollte der gesunde Menschenverstand entscheiden.
Der Code muss leserlich sein.
Die Namen selbsterklärend.
cu
frank
Joerg Jooss
"Franz Knauseder" <f...@etm.at> schrieb im Newsbeitrag
news:10349163...@newsmaster-03.atnet.at...
>
http://msdn.microsoft.com/library/en-us/cpgenref/html/cpconfieldusageguideli
> nes.asp
> >
> > "Do not apply a prefix to field names or static field names.
> > Specifically, do not apply a prefix to a field name to distinguish
> > between static and nonstatic fields.
> > For example, applying a g_ or s_ prefix is incorrect."
> >
> > => generell keine Prefixe (ausser I-Interface)
>
> Der Vorschlag ist eindeutig, aber was sind die Überlegungen dahinter. Oder
> einfacher gesagt, warum?
Weil es einfach nicht relevant ist. Man hat immer durch die (C#-)Syntax die
Möglichkeit, so etwas ohne Präfix auszudrücken:
g_X entfällt sowieso ;-)
s_ X MyClass.X
m_x this.x
In der Praxis mache ich aber auch eine Außnahme: private Felder erhalten
immer einen "_" als Präfix. Private Felder sind die
Implementierungsinnereien einer Klasse und diese (sowie Methoden, die darin
wurschteln) schnell zu erkennen, hat sich IMO als vorteilhaft erwiesen.
Cheers,
--
Joerg Jooss
joerg...@gmx.net
Sam Jost
> endlich jemand, der mir aus der Seele spricht!
>
> Ich verwende ein kleines Präfix für den Scope und ja nichts für den Typ
> (keine hungarian notation).
>
> m Membervariablen,
> l lokale Variablen (Laufindizes sind ausgenommen und dürfen durchaus i
> heißen)
> i Inputparameter (eigentlich a für Argument, will ich aber ändern)
> o Outputparameter
> r Referenzparameter
i/o/r find ich gut, werd ich mir auch mal für Parameter überlegen.
> In meiner letzten Firma hat das ziemlich gut funktioniert, in meiner
> jetzigen werde ich bestenfalls belächelt, meistens ...
Source-Formatierung wird eh in vielen Firmen belächelt. Da gibts
meist regeln für wenn der Leiter selber programmiert und es leid
ist sich die Formatierungen anderer anschauen zu müssen ;)
> Die Notation "this.var" für Membervariablen wird nicht geprüft (Compiler).
> Ein Variable var kann also sehr sowohl eine Membervariable sein.
Huh? Ich versteh jetzt nicht was Du damit meinst.
> Die Präfixes sollen/können "aussagekräftige Namen" nicht ersetzen.
Jupp! Tippfaulheit ist aller Programmiererlaster Anfang!!
Vernünftige Namen für Methoden/Variablen zu finden ist meist eines
der grössten Probleme! ;)
> Frage: Sollten aussagekräftige Namen auch den Scope/Verwendung beinhalten?
Was für Namen? Was für ein Scope? Hier fehlt mir ein Beispiel um zu wissen
worauf Du hinaus willst.
Gruss,
Sam
Thomas Scheidegger [MVP] NETMaster
> Datentypen entsprechend kennzeichnen.
> Klassen mit C
> Enums mit E
> Structs mit S
> Members m
> ect.
Alle diese 'Prefixe' sind doch ausdrücklich unerwünscht, z.B.:
http://msdn.microsoft.com/library/en-us/cpgenref/html/cpconclassnamingguidelines.asp
"Do not use a type prefix, such as C for class,..."
(exkl. I-.Interface)
> ist es nicht immer klar wann was benutzt werden soll.
> Wer kann jetzt sofort ohne nachzuschauen sagen wann was zu nehmen ist
Einfach:
es ist immer PascalCase, ausser bei lokal/param und nonPublicInstField,
und dort von Vorteil die Schreibweise:
this.firstValue
Hilfreich ist diese Tabelle aus dem ECMA C# Std:
http://msdn.microsoft.com/net/ECMA/
Appendix C. Naming guidelines
Class PascalCase
Attribute Class PascalCase Has a suffix of Attribute
Exception Class PascalCase Has a suffix of Exception
Constant PascalCase
Enum type PascalCase
Enum values PascalCase
Event PascalCase
Interface PascalCase Has a prefix of I
Method PascalCase
Namespace PascalCase
Property PascalCase
Public Inst.Field PascalCase Rarely used (use a property instead)
Prot. Inst.Field camelCase Rarely used (use a property instead)
Parameter camelCase
Local variable camelCase
Man beachte, es gibt das 'FxCop' Tool von MS
http://www.gotdotnet.com/team/libraries/
das viele dieser Guides prüft!
Wie schon gesagt:
Mindestens wenn man eigene Komponenten
weiterverkaufen will, so sollte man wenigstens alle
sichtbaren Schnittstellen/Typen nach Guideline benennen.
Und in einer Firma sollte man auch daran denken,
dass neue Mitarbeiter wahrscheinlich nach MS-Guideline
arbeiten werden ...
Sam Jost
schrieb:
> Der MS Vorschlag ist eigentlich eindeutig, z.B.:
>
http://msdn.microsoft.com/library/en-us/cpgenref/html/cpconfieldusageguideli
nes.asp
>
> "Do not apply a prefix to field names or static field names.
> Specifically, do not apply a prefix to a field name to distinguish
> between static and nonstatic fields.
> For example, applying a g_ or s_ prefix is incorrect."
>
> => generell keine Prefixe (ausser I-Interface)
Jau, auch Typ-Prefixe a la Petzold werden in dem Text deutlich
ausgeschlossen.
Für die Schnittstelle siehts auch besser aus keine Prefixe zu benutzen, seh
ich ein:
MyForm.Icon= MyIcon
vs
MyForm.m_Icon= MyIcon
Sprich: bei allem was public ist kann ich das akzeptieren, sowas sorgt für
einheitliche Form etwaiger Bibliotheken. Schick dass man sich bei MS
gedanken um sowas gemacht hat.
Bei Privaten Member Variablen würd ich prefixe gut finden, da spricht sich
MS gegen aus, leider ohne Begründung.
Über Parameter wird gesagt dass sie keinen typprefix haben sollen, und
camelCase.
Wobei da aber ein Grund angegeben wird, nämlich dass man sich die Typinfo
von der IDE anzeigen lassen kann. (und ich vermute mal in/out/ref zeigt
diese auch an, also wird der gleiche Grund gegen prefixes gelten).
> Mindestens wenn man eigene Komponenten
> weiterverkaufen will, so sollte man wenigstens alle
> sichtbaren Schnittstellen/Typen nach Guideline benennen.
Klingt vernünftig.
Ich werd mir die MS-Sachen mal durchlesen, zusammenfassen was auf uns
zutrifft, ausprobieren wie sich das macht und dann darauf aufbauend
überlegen ob/welche Abweichungen von deren Vorschlägen hier intern angewandt
werden sollen.
Das heisst nicht dass ich meine Erfahrungen dazu über den Haufen werfe, aber
ich bin durchaus im Sinne einer Standarisierung gewillt mir Vorschläge genau
anzuschauen.
Danke für den Link!
Sam
Sam Jost
> "Michael Brockhoff" <bro...@gmx.net> schrieb:
>
> Hallo Michael.
>
> > ich habe bisher für member Variablen immer den Präfix
> > m_ benutzt.
>
> m_Das m_sieht m_aber m_häßlich m_aus :-)
Du hast den ja auch voll falsch angewandt, die Wörter sind lokal und keine
Member ;*)
Gruss,
Sam
Sam Jost
> als alter Delphi & C/C++ programmierer finde ich es wichtig für
> den Leser/Programmierer den Code verstehen zu können.
>
> C#
> Person person = new Person ();
> Person person = Person (leiter);
Und das geht noch deutlich schlimmer, zB wenn auch noch
gleichnamige Member ins Spiel kommen, zB Form.Icon.
Im Petzold sind da ein paar Beispiele für sehr verwirrende
wasistwas Spielchen.
> Im Grunde sollte der gesunde Menschenverstand entscheiden.
> Der Code muss leserlich sein.
> Die Namen selbsterklärend.
Jupp. Bei c# stand bei MS 'der Code muss schick aussehen'
etwas zu sehr im Vordergrund ;)
Sam
Thomas Scheidegger [MVP] NETMaster
> zutrifft, ausprobieren wie sich das macht und dann darauf aufbauend
> überlegen ob/welche Abweichungen von deren Vorschlägen hier intern angewandt
> werden sollen.
> Das heisst nicht dass ich meine Erfahrungen dazu über den Haufen werfe, aber
> ich bin durchaus im Sinne einer Standarisierung gewillt mir Vorschläge genau
> anzuschauen.
Man beachte, es gibt das 'FxCop' Tool von MS
http://www.gotdotnet.com/team/libraries/
das viele dieser Guides prüft!
Sam Jost
> > Datentypen entsprechend kennzeichnen.
> > Klassen mit C
> > Enums mit E
> > Structs mit S
> > Members m
> > ect.
>
> Alle diese 'Prefixe' sind doch ausdrücklich unerwünscht, z.B.:
Jaaaa, aber wenn man mal etwas genauer schaut heisst die Doku in
der das steht:
"Design Guidelines for Class Library Developers"
Und im vorwort wird deutlich erklärt dass man wenn man Lib's
macht die man veröffentlichen will es doch besser wäre wenn
man sich an einen gemeinsamen standard (nämlich diesen) hält.
Es gibt ja Firmen die Bibliotheken verkaufen, für die gelten diese
Regeln.
Und es gibt Firmen die Programme verkaufen, da sind diese Regeln
eigentlich egal aber sicher eine gute Grundlage.
> Und in einer Firma sollte man auch daran denken,
> dass neue Mitarbeiter wahrscheinlich nach MS-Guideline
> arbeiten werden ...
Ich finds normal das man als neuer Programmierer eine Einführung
oder besser einen Styleguide bekommt wie der Source in dieser
Firma auszusehen hat. Klar kann man eher davon ausgehen dass
ein neuer die MS-Grundlagen als irgendwelche exotischen kennt,
die sind also IMHO eine gute Grundlage. Und sei es nur um
daran deutlich zu machen was man anders machen möchte ;)
Ein Traum wär doch eigentlich eine IDE die beim laden eines
Sources die ganzen Member und Formatierung schön lesbar
für den Entwickler der grad dransitzt aufbereitet - er kann ja
in MS-Form gespeichert werden, es geht doch nur darum
wie man ihn lesen und tippen möchte. Und eigentlich muss
das automatisierbar sein.
Gruss,
Sam
Sam Jost
> "Franz Knauseder" <f...@etm.at> schrieb:
> > > => generell keine Prefixe (ausser I-Interface)
> >
> > Der Vorschlag ist eindeutig, aber was sind die Überlegungen dahinter.
Oder
> > einfacher gesagt, warum?
>
> Weil es einfach nicht relevant ist. Man hat immer durch die (C#-)Syntax
die
> Möglichkeit, so etwas ohne Präfix auszudrücken:
>
> g_X entfällt sowieso ;-)
> s_ X MyClass.X
> m_x this.x
>
> In der Praxis mache ich aber auch eine Außnahme: private Felder erhalten
> immer einen "_" als Präfix. Private Felder sind die
> Implementierungsinnereien einer Klasse und diese (sowie Methoden, die
darin
> wurschteln) schnell zu erkennen, hat sich IMO als vorteilhaft erwiesen.
Also benutzt Du bei privaten Felder eine sozusagen m_ als prefix, nur heisst
es
bei dir _.
s_ scheint in c# auch nicht mehr so wichtig. In C++ kann man statische
Felder ja
auch über Instanzen eines Typs aufrufen, da ist s_ ganz nett um manch
Verwechslung vorzubeugen.
this.x find ich optisch nicht hübsch, aber man kann sich ja umgewöhnen wenn
es sein muss ;)
Sam
Sam Jost
> > zutrifft, ausprobieren wie sich das macht und dann darauf aufbauend
> > überlegen ob/welche Abweichungen von deren Vorschlägen hier intern
angewandt
> > werden sollen.
> > Das heisst nicht dass ich meine Erfahrungen dazu über den Haufen werfe,
aber
> > ich bin durchaus im Sinne einer Standarisierung gewillt mir Vorschläge
genau
> > anzuschauen.
>
> Man beachte, es gibt das 'FxCop' Tool von MS
> http://www.gotdotnet.com/team/libraries/
> das viele dieser Guides prüft!
Gute idee, so kann man Schnittstellen zu einer Lib mit dem prädikat 'geht
fehlerfrei durch FxCop' ausstatten ohne als Entwickler für einen Test und
Prüfstempel (.net approved) viel Geld ausgeben zu müssen.
Btw, auch hier steht wieder bei 'to develop reusable libs', die nehmen also
auch sehr stark Bezug auf Leute die ihren Quellcode vermarkten.
Gruss,
Sam
Thomas Scheidegger [MVP] NETMaster
> auch sehr stark Bezug auf Leute die ihren Quellcode vermarkten.
Es gäbe auch Leute, die Code so entwicklen, dass er Firmen-intern
als Komponente wiederverwertbar (=reusable) ist ;-)
Franz Knauseder
> > Die Notation "this.var" für Membervariablen wird nicht geprüft
(Compiler).
> > Ein Variable var kann also sehr sowohl eine Membervariable sein.
>
> Huh? Ich versteh jetzt nicht was Du damit meinst.
class Hugo
{
int name;
void method(int ...)
{
int ...
name = 7;
}
}
"name" ist hier eine Membervariable;
Der Compiler oder FxCop könnten ja melden "Bitte Mebervariablen über this."
ansprechen.
Läuft dann die Compilation oder Prüfung warnigfrei ab, kann ich mich darauf
verlassen, daß alle Memebervariablen mit this. notiert sind.
> > Die Präfixes sollen/können "aussagekräftige Namen" nicht ersetzen.
>
> Jupp! Tippfaulheit ist aller Programmiererlaster Anfang!!
> Vernünftige Namen für Methoden/Variablen zu finden ist meist eines
> der grössten Probleme! ;)
>
> > Frage: Sollten aussagekräftige Namen auch den Scope/Verwendung
beinhalten?
>
> Was für Namen? Was für ein Scope? Hier fehlt mir ein Beispiel um zu wissen
> worauf Du hinaus willst.
Unter Scope habe ich gemeint ob es sich um eine Membervariable, eine lokale
Variable, einen Parameter etc. handelt. Das, was ich eigentlich durch den
Präfix ausdrücke.
Wenn ich ohne Präfixes arbeiten soll, soll dann diese Information direkt in
den Namen?
Franz
Sam Jost
also
> > auch sehr stark Bezug auf Leute die ihren Quellcode vermarkten.
>
> Es gäbe auch Leute, die Code so entwicklen, dass er Firmen-intern
> als Komponente wiederverwertbar (=reusable) ist ;-)
Jau, darauf hatte ich vorhin auch mehrfach Bezug genommen (stur sei):
In Softwarefirmen sollte es eigentlich üblich sein dass man intern
richtlinien hat nach denen Source formatiert wird damit er intern
wiederbenutzt werden kann. Diese können, müssen sich aber nicht mit den
Vorstellungen die MS hat decken. Und wer in einer Firma neu anfängt sollte
solche Richtlinien natürlich lernen, genau wie er lernen muss wo das Klo ist
und was er mit seinem schmutzigen Geschirr macht :)
Wir sind uns da doch eigentlich voll einig:
- einheitliche Formatierung ist gut.
Nur schränk ich halt ein dass die Formatierung die MS vorschlägt nicht
unbedingt für jede Gruppe von Programmierern der Weisheit letzter Schluss
sein muss. Es gibt sicher durchaus sinnvolle Erweiterungen zu den
MS-Vorschlägen die einem Entwickler das Leben einfacher machen können, man
muss dabei aber auch das umfeld, also was programmiert wird, mit betrachten
und es wird auch sicherlich nicht für alle das gleiche gelten.
können wir uns da drauf einigen?
Sam
--
PS: Eine eigene Form der Formatierung durch die Quelltext wartbarer ist kann
durchaus auch ein Wettbewerbsvorteil gegenüber Mitbewerbern sein (genau wie
eine eigene Sprache oder x-beliebige andere inhouse tools und Libs ein
Vorteil sein kann den andere halt nicht haben). allerdings wohl kein
besonders grosser ;)
Sam Jost
>
> > > Die Notation "this.var" für Membervariablen wird nicht geprüft
> (Compiler).
> > > Ein Variable var kann also sehr sowohl eine Membervariable sein.
> >
> > Huh? Ich versteh jetzt nicht was Du damit meinst.
> class Hugo
> {
> int name;
>
> void method(int ...)
> {
> int ...
> name = 7;
> }
> }
> "name" ist hier eine Membervariable;
>
> Der Compiler oder FxCop könnten ja melden "Bitte Mebervariablen über
this."
> ansprechen.
> Läuft dann die Compilation oder Prüfung warnigfrei ab, kann ich mich
darauf
> verlassen, daß alle Memebervariablen mit this. notiert sind.
Ach so, klar. Wär vielleicht eine sinnige optionale Warnung. (optional weil
nicht jedem wird das gefallen immer this dazu schreiben zu müssen).
> > > Frage: Sollten aussagekräftige Namen auch den Scope/Verwendung
> > > beinhalten?
> >
> > Was für Namen? Was für ein Scope? Hier fehlt mir ein Beispiel um zu
wissen
> > worauf Du hinaus willst.
> Unter Scope habe ich gemeint ob es sich um eine Membervariable, eine
lokale
> Variable, einen Parameter etc. handelt. Das, was ich eigentlich durch den
> Präfix ausdrücke.
Ach so, ich dachte Du meinst mit Scope vielleicht ob es zu einer Lib gehört,
wie
zB gdi vor alle Windows-GDI-Befehle zu schreiben. Und diesen Lib-Scope
halte ich durch die umfassende Unterstützung von Namespaces und Klassen
in c# für hinfällig, der war eher um einen haufen freier API-Funktionen
zu gruppieren als namespaces es noch nicht gab/taten.
> Wenn ich ohne Präfixes arbeiten soll, soll dann diese Information direkt
in
> den Namen?
Das wär doch auch nur ein Prefix. ob ich nun m_EinWert oder MemberEinWert
oder auch EinWertMember schreib bleibt sich gleich: entweder markier ich es
oder nicht. Und wenn markieren dann wär ich für eine kurze Markierung.
Ich muss mich erstmal wieder hinsetzen und ein paar c#-Quelltexte
umformatieren um zu gucken was mir persönlich nun für c# am besten
gefällt, bzw um zu testen welche meiner c++-regeln für prefixes jetzt
vielleicht hinfällig sind.
Fortsetzung folgt ;)
Gruss,
Sam
Sam Jost
[...]
> Was benutzt ihr, bzw. was haltet ihr für sinnvoll? Das man sich in einer
> Firma möglichst an
> eine Konvention halten sollte ist außer Frage
Die Frage nach der Formatierung und Diskussion drüber ist auch nicht weiter
unüblich. Bei Joel on Software (lesenswert) läuft auch grad eine:
http://discuss.fogcreek.com/dotnetquestions/default.asp?cmd=show&ixPost=515&
ixReplies=19
Und die Gründe und Argumente sind auch immer wieder ähnlich...
schönes Wochenende noch!
Sam
Mayken
Franz Knauseder <f...@etm.at> schrubste in
news:10348674...@newsmaster-03.atnet.at:
> Ich verwende ein kleines Präfix für den Scope und ja nichts für den
> Typ (keine hungarian notation).
irgendwo in MSDN oder MS-Press-Untiefen gab es dazu eine "offizielle"
Äußerung:
Nie und nimmer nicht hungarian, da dies unter VS.NET nicht mehr nötig
sei, weil ja die IntelliSense-Funktion alle Informationen anzeigt.
Ob dies nun nur in Onkel Bills oder auch in eines Entwicklers Interesse
liegt, mag jeder selbst entscheiden ;-)
Ciao
Mayken
--
[Disclaimer: Weder verwandt noch verschwägert, nix desto gut: ;->]
Heilung für beide MS-Outpfusch
http://jump.to/oe-quotefix + http://jump.to/outlook-quotefix