Laden...

Coding Standard und Code Design

Erstellt von TOM_MUE vor 18 Jahren Letzter Beitrag vor 17 Jahren 13.495 Views
TOM_MUE Themenstarter:in
200 Beiträge seit 2004
vor 18 Jahren
Coding Standard und Code Design

Hallo,

mich würde mal interssieren wer von Euch die "IDesign C# Coding Standards" von Juval Lowy kennt und selbst auch anwendet.

Als zweites würde ich gerne wissen ob es dann auch noch von Euch Programmierer gibt, die zu diesen Coding Standards die Code- Guidelines aus dem Buch "Practical Guidelines and best Practices For Microsoft Visual Basic and Visual C# Developers" anwendet und für praktikabel hält. Das sind übrigens die Macher des Blogs: .Net2TheMax.

Als drittes würde mich noch interessieren wem diese Code-Formen nicht unbekannt sind (natürlich unter C#)


string m_Name = string.Empty;

string const c_Name = "TOM";

private void GetGreetingFrom(string a_Name)
{
   string l_MethodName = a_Name;

   return string.Format("Greetings from {0}",l_MethodName);
}

...

foreach(string f_Drive in Environment.GetLogicalDrives())
{
      ....
}

**:::

dabei geht es mir um die:

l_
m_
c_
f_

Danke für Antworten 😉

TOM_MUE

354 Beiträge seit 2004
vor 18 Jahren

Ist mir nicht unbekannt. Allerdings stehe ich nicht besonders darauf, meine Member-Variablen mit m_ zu kennzeichnen. Ist mir auf Dauer einfach zuviel Schreibarbeit. Da sehe ich es schon als sinnvoller an, den Typ der Variable mit in den Namen zu packen.

.NET GUI - Die Community für grafische Oberflächen unter .NET
Jetzt kostenlos besorgen: .NET BlogBook
Norbert Eder
DasBackup

1.549 Beiträge seit 2004
vor 18 Jahren

Mir ist auch:

string Name_str = "";

lieber

Wir Arbeiten eigendlich nicht wir nehmen nur das geld

W
799 Beiträge seit 2004
vor 18 Jahren

Wozu? Maus in der IDE über die Variable, und der Typ wird doch angezeigt ... oder für den häufigen Fall, dass man doch mal mit Notepad ran muss?

354 Beiträge seit 2004
vor 18 Jahren

Ich programmiere meistens an Frameworks rum, daher ists es für mich nur nervig, wenn ich die Maus benutzen muss. Der Typ im Namen ist daher schon recht praktisch - mach ich aber auch nicht immer.

Und nein, ich verwende definitiv keine Unterstriche. Dadurch geht beim Tippen nur Zeit verloren und ich finds sehr unübersichtlich.

.NET GUI - Die Community für grafische Oberflächen unter .NET
Jetzt kostenlos besorgen: .NET BlogBook
Norbert Eder
DasBackup

TOM_MUE Themenstarter:in
200 Beiträge seit 2004
vor 18 Jahren

Hallo,

schön das ich ein paar in die Diskussion eingeklingt ahben. Finde gerade diesen Themenbereich sehr interessant da es da doch sehr viele unterschiedliche Ansprüche zu geben scheint.

Also das mit den m_ oder a_ oder l_ habe ich auch nicht sofort gemocht. Aber man gewöhnt sich sehr schnell daran. Und ich will es nun auch nicht mehr missen.

Für mich ist es von der Schreibgewohnheit einfach schneller, wenn ich m_ eintippe und in der automatischen Codevervollständigung gleich allle Member- Fields untereinander stehen. Will ich nun auf eine Variable aus der Methode zugreifen in der ich mich befinde brauche ich nur l_ eingeben und schon stehen alle Variablen mit l_ untereinander. Und das ist dann auch so mit den Methodenparametern bei a_. ALso für mich ist der Typ im Namen nicht so wichtig. Da gehe ich einfach mal nach dem Intellisense des Studios. Da brauch ich ja nicht mal ne Maus 😉 CTRL + K, CTRL + I zeigt mir die Informationen an die ich brauche. Mir ist es auch noch nie passiert das ich bei einer Zuweisung eines Strings ein falsches Field oder eine falsche Variable genommen hätte (also den falschen Typ). darum finde ich wiederum den Typ in .NET überflüssig. Anders ist das bei Script. Also JScript oder VBScript. Da habe ich ja nun mal ein var und dem kann ich ja alles andrehen. Bei uns sind solche Dinge auch in den Firmen- Coding Guidelines verankert an die sich jeder zu halten hat. Zum Glück durfte ich sie mitschreiben (he he).

Vielleicht kommen ja noch ein paar Meinungen zusammen oder vielleicht auch Erfahrungsberichte? Wäre cool.

Gruß

TOM_MUE

4.221 Beiträge seit 2005
vor 18 Jahren

ich verwende

_ für Variablen auf Klassenebene
p für Parameter

nix für lokale (Methode) Variablen

Zudem heissen bei mir Fields imm gleich (aber mit _) wie die Properties.

Früher war ich unentschlossen, heute bin ich mir da nicht mehr so sicher...

354 Beiträge seit 2004
vor 18 Jahren

Ich habe mich sehr lange mit diversen Coding-Styles befasst - vor allem weil ich in einem Team arbeite und daher der Sourcecode auch entsprechend lesbar sein sollte. Dabei einigt sich man auf einen Style mit dem jeder leben kann - immerhin hat jeder bestimmte Vorlieben bzw. Aversionen.

Persönlich hab ich mir aus mehreren Styleguides die Dinge rausgesucht, die mir als sinnvoll erscheinen und so verwende ich sie.

.NET GUI - Die Community für grafische Oberflächen unter .NET
Jetzt kostenlos besorgen: .NET BlogBook
Norbert Eder
DasBackup

S
709 Beiträge seit 2005
vor 18 Jahren

Original von Programmierhans
ich verwende

_ für Variablen auf Klassenebene

Ich auch. Was mit gar nicht gefällt ist z.B. sowas:

 
ArrayList arrlstItems = new ArrayList();
bool bIsValid = false;

Ich mein, ich programmiere keine richtig großen Programme aber das mit dem Typenkürzel vor dem Variablennamen gefällt mir nicht. Das stört meiner Meinung nach die Lesbarkeit des Codes.

Gruß,
SimonKnight6600

I
1.739 Beiträge seit 2005
vor 18 Jahren

CodingGuideLines und so:
Man kannsich darüber vortrefflich streiten.
IMHO besteht darüber keine Übereinstimmiung zw. mir und Programmierhans(bzw die Guidelines des Lib-Projects dieses Forums, was wohl eh nie die Realität erreicht) im wirklichen Leben sind diese Unterschiede eh irrelevant...

ikaros

4.221 Beiträge seit 2005
vor 18 Jahren

Original von SimonKnight6600

Ich mein, ich programmiere keine richtig großen Programme aber das mit dem Typenkürzel vor dem Variablennamen gefällt mir nicht. Das stört meiner Meinung nach die Lesbarkeit des Codes.

Ich schreibe grosse Programme .... und vorallem warte/debugge ich auch code von anderen Leuten.... und eine minimale Kennzeichnung ist Gold wert.... anderenfalls kriegst Du den Krampf in der Maushand 🙁 dies vorallem da solche Programme oft unkommentiert und undokumentiert sind.

Aus meiner Sicht tragen korrekte Kürzel (sofern der Typ der Variable nicht schon aus dem Namen ableitbar ist) zur Lesbarkeit bei (man sieht auf den ersten Blick was es ist).

Edit: Nachtrag: bool bIsValid = false; halte ich auch für Schlecht ... weil

isValid an und für sich schon angibt dass es nur 2 Zustände gibt... zudem weiss man ja nicht was Valid ist... diese Info fehlt vollständig

isDateStartValid halte ich für Sinnvoller

oder:

_isDateValid auf Klassenebene.

Früher war ich unentschlossen, heute bin ich mir da nicht mehr so sicher...

I
1.739 Beiträge seit 2005
vor 18 Jahren

Da kann man sich ausschliesslich nur mit weinenden Auge anschliessen(ist Realität).
Das mit den Kürzeln...(naja, je nach undso....).

3.728 Beiträge seit 2005
vor 18 Jahren
Coding Richtlinien

Wenn man im Team arbeitet sind Coding Richtlinien sehr sinnvoll. Wichtig ist nicht welche man verwendet, sondern dass sich alle im Team daran halten. In den größeren Visual Studio Editionen lassen Code Richtlinie auch per Policy erzwingen. Der Compiler wirft solange Fehler, bis der Entwickler die Richtlinien vollständig erfüllt hat (Manche verweigern auch das einchekcen in die Quellcodeverwaltung).

Leider ist das erstellen solcher Policies umständlich. Alles muss per Hand in eine XML-Datei getippt werden. Ich schätzte, dass fast niemand dieses Feature von VS verwendet. Weiß jemand, ob es in VS 2005 einen grafischen Editor dafür gibt?

Wir verwenden übrigens weitestgehend die von Microsoft vorgeschlagenen Coding Richtlinien für C#. Die stehen übrigens auch in der Online-Hilfe von Visual Studio.

Ich habe auch schon leute gesehn die Java Coding-Richtlinien für C# einsetzen. Besonders lustig dabei ist, dass keine Properties verwendet werden (Die gibt es ja in Java nicht). Stattdessen werden immer zwei Methoden geschrieben (z.B. GetName und SetName).

TOM_MUE Themenstarter:in
200 Beiträge seit 2004
vor 18 Jahren

Hallo Rainbird,

so weit ich Frank Fischer in einem seiner Vorträge zu TEam Foundation Server verstanden habe, sind ganau solche Schnittstellen für die Eingabe von Coding Guidelines für third party Anbieter offen gelassen worde. Soll heißen wer sich da reinfummelt und einen guten Designer dafür entwickelt kann Geld damit verdienen 😉
Bisher kenne ich aber noch keinen der es angegangen ist. Meiner Meinung nach wird sicher nach der Fertigstellung des Team Foundation Servers ein rudimenterer Designer dabei sein.

Der Team Foundation Server hat auch ein Extensibility- Object- Model. Es gibt sogar schon WebCasts dazu.

Gruß
TOM_MUE

1.130 Beiträge seit 2005
vor 18 Jahren

Original von Rainbird
Wir verwenden übrigens weitestgehend die von Microsoft vorgeschlagenen Coding Richtlinien für C#. Die stehen übrigens auch in der Online-Hilfe von Visual Studio.

Tatsächlich? hmm... vielleicht habe ich in der Hilfe falsch gesucht, aber ich finde nix.

Bisher habe ich mich immer an die Coding Guidelines von #Develop gehalten:
www.icsharpcode.net/TechNotes/SharpDevelopCodingStyle03.pdf

Dazu gibt es dann noch "The fine Art of Commenting"
http://www.icsharpcode.net/TechNotes/Commenting20020413.pdf

3.728 Beiträge seit 2005
vor 18 Jahren
Pascal-Schreibweise

Bitteschön:

ms-help://MS.VSExpressCC.v80/MS.NETFramework.v20.de/dv_fxdesignguide/html/4c4ea526-9203-486f-b72d-29d61c5b3c6d.htm

(Dieser Link wurde aus der Visual C# 2005 Express Hilfe kopiert)

Falls der Link nicht passt, such einfach nach "Pascal-Schreibweise".

1.130 Beiträge seit 2005
vor 18 Jahren

Original von Rainbird
Bitteschön:
ms-help://MS.VSExpressCC.v80/MS.NETFramework.v20.de/dv_fxdesignguide/html/4c4ea526-9203-486f-b72d-29d61c5b3c6d.htm

ah, hab' vielen Dank.

1.274 Beiträge seit 2005
vor 18 Jahren

Ich verwende genau dieser Art der Auszeichnung für Namen

c...Konstanten
l...Lokale Variablen
p...Funktionsparameter
m...Modulglobale Variablen
g...Globale Variablen (ich möchte darüber keine Posts sehen 😉)

"Das Problem kennen ist wichtiger, als die Lösung zu finden, denn die genaue Darstellung des Problems führt automatisch zur richtigen Lösung." Albert Einstein

S
8.746 Beiträge seit 2005
vor 18 Jahren

Ich verwende ich den MS-Coding-Style (im Prinzip genauso wie #develop). MS hat ja auch lange eine Auszeichnung von Typen u.ä. progagiert, ist aber nun davon abgekommen und setzt nur noch auf Groß/Kleinschreibung und sprechende Namen.

Ich persönlich finde das sehr angenehm, weil alles andere in Zeiten von Intellisense & Klassenbrowsern doch ein wenig antiquiert erscheint und m.E. schlechter lesbar ist (die Präfixe machen den eigentlichen Namen schlecht lesbar).

Aber das Thema von Namen für Patterns sind mir eigentlich wichtiger. Bestimmte Muster sollten auch korrekt benannt werden.

195 Beiträge seit 2004
vor 18 Jahren

Original von TOM_MUE
Hallo,

mich würde mal interssieren wer von Euch die "IDesign C# Coding Standards" von Juval Lowy kennt und selbst auch anwendet.

...

dabei geht es mir um die:

l_
m_
c_
f_

Ich kenne das nicht unter dem Begriff. Habe aber bei meinem Einstieg in die Programmierung Quellcode in dieser Formatierung vorgefunden und das übernommen.

Ich mag den Unterstrich, weil ich dann immer auf den ersten Blick sehe, welche Member, Methoden, Properties eines Objektes etc. von mir kommen und welche vom System "ererbt" wurden.

Umwege erhöhen die Ortskenntnis.

I
1.739 Beiträge seit 2005
vor 18 Jahren

btw:
um Rainbird zu ergänzen.
Es lassen sich auch Coderichtlinien erstellen, die ein Einchecken in VS-Sourcesafe verhindern...

L
254 Beiträge seit 2005
vor 17 Jahren

Hmm interessant;

Ich verwende eigentlich diese Kürzel nur dann wenn der zu einem Property gehörende Member gleich heisst und ich ihn durchs casing unterscheiden müsste.

Bei den Kürzeln gibt es ein Problem, man muss wissen was der Entwickler mit dem Kürzel gemeint hat und das verwirrt mich persönlich viel mehr als es wegzulassen;

z.B. msCatalogIconImageUrl

steht jetzt m für Member? wahrscheinlich schon...
und s? steht jetzt s für string oder für sealed?
Das ist n bischen mein Problem das ich im Moment habe...

Wenn 5 Entwickler an einem Projekt arbeiten und du hast keine 100% Rchtilinie kann das schonmal schwerer lesbar werden.

Vielleicht steht das Kürzel auch für was ganz anderes...

Auf jedenFall verwende ich für meine member ab jetzt den "_" find das garnicht so mies für meinen Stil, da ich ja nur Member von Properties so nenne kann ich mir die mithilfe des Intellisense anzeigen lassen.
Thx

If you can't make it, fake it.

3.511 Beiträge seit 2005
vor 17 Jahren

Also ich verwende Grundsätzlich immer nur m_ für meine Member. Zudem gebe ich diesen Member auch aussagekräftige Namen. Namen wie m_Name sagen an sich nichts aus, darum z.B. m_BestellerName. Das mache ich allerdings auch, wenn die Klasse schon Besteller heißen sollte und es in der ganzen Klasse nur ein Name gibt.
Es kommt gut vor, das ich Member habe mit weit über 20 Zeichen als Namen. Ist auf den ersten Blick im Editor etwas ungewöhnlich, aber dadurch steige ich durch den Code wesentlich besser durch. Hauptsächlich, wenn ich mir ältere Sourcen anschaue und ich nicht mehr auf den ersten Blick sehe, was denn da genau passiert. Da helfen gute aussagekräftige Namen sehr viel.

Prefixe für den Typ des Members, also m_iWarenAnzahl, oder m_sBestellerName halte ich für absolut überflüssig, da man ja anhand der Variable erkennen sollte, was dahinter steckt.

Es gibt nur ein Ausnahmefall, nämlich Schleifen. Da benutze ich immer noch die guten alten Bezeichner i, j, k, l.

"Jedes Ding hat drei Seiten, eine positive, eine negative und eine komische." (Karl Valentin)

K
71 Beiträge seit 2005
vor 17 Jahren

Hallo alle

Wir verdenden auch die gängigen MSDN Richtlinen (Pascal case & Camel case, so wie sie auch im Framework vorhanden sind).
Prefixe für Membervariablen benutzen wir nicht.

Allerdings gilt eine Richtlinie welche besagt, dass kein Bezeichner sich nur durch Gross/Kleinschreibung unterscheiden darf (C# -> VB.NET).

Beispiel:

class MyClass
{
  private bool isValid;

  public bool Valid
  {
    get { return isValid; }
  }

  public int Add(int someInt, int anotherInt)
  {
    ...
  }
}

@Rainbird: Die erzwingung der Konventionen per XML File klingt interessant.
Kann man eine solche Definition nicht einmal erstellen und dann "wiederverwenden"?
Wenn der Aufwand nicht zu riesig ist, würde sich das IMHO lohnen.

Gruss Fellmer

S
8.746 Beiträge seit 2005
vor 17 Jahren

Original von Fellmer Lloyd
Allerdings gilt eine Richtlinie welche besagt, dass kein Bezeichner sich nur durch Gross/Kleinschreibung unterscheiden darf (C# -> VB.NET).

Dieser Regel macht aber nur dann Sinn, sofern beide (!) mindestens protected sind. Bei der üblichen private field und public property isses Wurscht. Die Refactoring Funktion von VS (encapsulate field) macht es ja auch so.

W
799 Beiträge seit 2004
vor 17 Jahren
namespace Project.Common.Bla
{
	public class Auto
	{

		public Auto(AutoMotor _motor)
		{
			motor = _motor;
		}

		private AutoMotor motor;
		public AutoMotor Motor
		{
			get { return motor; }
			set { motor = value; }
		}

	}
}

Zum Konstrutkor: das ist eigentlich das einzige Dilemma ... wie macht ihr das? Sinnigerweise würde ich in der Signatur auch motor und nicht _motor verwenden wollen, vom Gefühl her.

484 Beiträge seit 2006
vor 17 Jahren
namespace Project.Common.Bla
{
	public class Auto
	{

		public Auto(AutoMotor motor)
		{
			_Motor = motor;
		}

		private AutoMotor _Motor;
		public AutoMotor Motor
		{
			get { return _Motor; }
			set { _Motor = value; }
		}

	}
}

So 🙂

S
1.047 Beiträge seit 2005
vor 17 Jahren

so hat ich das bisher auch immer, nur das ich die attribute auch klein benenne, also in dem fall _motor

aber ich muß sagen das mir solch variante doch schon bissl besser gefällt

namespace Project.Common.Bla {
    public class Auto {

        public Auto(AutoMotor p_motor) {
            m_motor = p_motor;
        }

        private AutoMotor m_motor;

        public AutoMotor Motor {
            get { return m_motor; }
            set { m_motor = value; }
        }

    }
}

zudem find ich prefixe die den typ angeben garnicht mal so unsinnig, denn was ist mit ausdrucken? da ist nichts mit intellisense und co. 😉

W
799 Beiträge seit 2004
vor 17 Jahren

Meistens erschließt es sich dennoch aus dem Kontext heraus, sowas gewöhne ich mir gar nicht erst an, nicht nur weils nervt, sondern weil es auch nicht cool aussieht 😉

Jörgs Variante gefällt mir auch nicht, dann eher verzichte ich ganz auf _ und verwendete in der Konstruktor-Signatur logische Bezeichnungen wie newAuto.

564 Beiträge seit 2005
vor 17 Jahren

namespace Project.Common.Bla 
{
    public class Auto 
    {
        public Auto(AutoMotor autoMotor) 
        {
            this.autoMotor = autoMotor;
        }

        private brumBrum()
        {
        }

        private AutoMotor autoMotor;

        public AutoMotor AutoMotor 
        {
            get { return autoMotor; }
            set { autoMotor = value; }
        }

    }
}
484 Beiträge seit 2006
vor 17 Jahren

Das wäre dann MS Konform 🙂

W
799 Beiträge seit 2004
vor 17 Jahren

Original von ZiMD

  
namespace Project.Common.Bla   
{  
    public class Auto   
    {  
        public Auto(AutoMotor autoMotor)   
        {  
            this.autoMotor = autoMotor;  
        }  
  
        private brumBrum()  
        {  
        }  
  
        private AutoMotor autoMotor;  
  
        public AutoMotor AutoMotor   
        {  
            get { return autoMotor; }  
            set { autoMotor = value; }  
        }  
  
    }  
}  

👍

Soweit hab ich natürlich nicht gedacht ... das macht Sinn

564 Beiträge seit 2005
vor 17 Jahren

Ups da hab ich ja ein "void" vergessen 😁

W
799 Beiträge seit 2004
vor 17 Jahren

Fetter Motorschaden 😉