Sauberes C#
Ich bemühe mich natürlich einen ordentlichen und übersichtlichen Programmierstil zu verwenden, doch manchmal gelingt mir das nicht. Deshalb würd ich gern mal wissen wie so eine Durchschnittliche Klasse bei euch aussieht, wo ihr z.B. die Members und Methoden anordnet.
Das ist einfach nur ne stilistische Frage, hat nichts mit der optimierung des Codes zu tun 😉
bei mir siehts in etwa so aus
public class BRP : IDisposable
{
#region Felder
#endregion
#region Eigenschaften
#endregion
#region Konstruktoren
#endregion
#region Funktionen
#endregion
#region Ereignisse
#endregion
#region Behandelte Ereignisse
#endregion
#region IDisposable Member
public void Dispose()
{
}
#endregion
}
komm damit ganz gut klar, gab bis jetzt keine Probleme. Und zurnot STRG+F gibt es ja auch noch...
Es gibt 3 Arten von Menschen, die die bis 3 zählen können und die, die es nicht können...
Ich versuch auch immer bissle zu trennen mit Regions. Aber eher logisch als streng nach Zuordnung obs jetzt ne Funktion oder nen Property ist etc. Des kommt aber auch daher das ich eh kleine Klassen schreibe mit übersichtlichen Funktionen.
@ kleines_eichhörnchen
Kleiner Verbesserungsvorschlag: Dein Dispose folgt nicht dem von MS vorgeschlagenen Pattern für .Net wenn du keinen Finalizer implementierst.
Baka wa shinanakya naoranai.
Mein XING Profil.
Hallo zusammen
Bei mir sieht es ähnlich aus wie bei kleines_eichhoernchen.
Ich verwende aber die äquivalenten Ausdrücke im Englischen.
Gruss Peter
--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011
- https://peterbucher.ch/ - Meine persönliche Seite
- https://fpvspots.net/ - Spots für FPV Dronenflüge
Original von talla
@ kleines_eichhörnchen
Kleiner Verbesserungsvorschlag: Dein Dispose folgt nicht dem von MS vorgeschlagenen Pattern für .Net wenn du keinen Finalizer implementierst.
kannst du mal nen Beispiel geben, wie es hätte richtig heißen sollen, damit ich dir folgen kann?
oder meinst du
~BRP()
{
GC.Irgandwas(this);
}
damit der Finalizer nicht nocheinmal aufgerufen wird?
@Peter Bucher
Ich bin Deutscher, nein schlimmer Vogtländer. Ich meide (etwas) das englische
Es gibt 3 Arten von Menschen, die die bis 3 zählen können und die, die es nicht können...
Hallo zusammen,
auch ich verwende Regions in folgender Anordnung:
#region Variable Definitions
#endregion
#region Properties
#endregion
#region Constructor
#endregion
#region Events
#endregion
#region Private Methods
#endregion
#region Public/Protected Methods
#endregion
Das habe ich mir als Code-Fragment in die Toolbox gehängt, damit ich jede neue Klasse damit ausstatten kann.
Für ganz große Klassen (z.B. Hammermäßige GUI-Klasse mit 1000 Event-Behandlungen), richte ich meine Regions komplett nach Funktionalität, z.B. nach (Scroll-Events, Mouse-Events, Helper-Methoden etc...)
Gruß
Norman-Timo
A: “Wie ist denn das Wetter bei euch?”
B: “Caps Lock.”
A: “Hä?”
B: “Na ja, Shift ohne Ende!”
Original von talla
@ kleines_eichhörnchen
Kleiner Verbesserungsvorschlag: Dein Dispose folgt nicht dem von MS vorgeschlagenen Pattern für .Net wenn du keinen Finalizer implementierst. Etwas OffTopic...
Sehr oft, eigentlich fast immer, impementiert man IDisposable um dem Konsumenten ein determinstisches Freigeben von direkt und indirekt benutzten unmanaged Resources zu ermöglichen. Der zweite Grund ist, dass man keine Finalizer in einem GC Sweep haben möchte.
Wenn ich also ein Feld habe, dass IDisposable implementiert bin ich gut beraten selbst IDisposable zu implementieren damit der Konsument meiner Klasse den Finalizer dieses Feldes umgehen kann. Die Klasse selbst braucht natürlich keinen, wenn die Klasse hinter dem Feld schon einen hat.
Es ist eher good practice so wenig wie möglich Finalizer zu benutzen, wenn überhaupt, IMHO.
@ Robert G
Schau dir mal Herbivores Link an. So empfiehlt es auch Microsoft als Common Practice in .Net. Was nützt ein schönes Dispose wenn niemand es aufruft? Genau dafür ist dieses Pattern gedacht.
Nen Finalizer nur um managed Referenzen zu Nullen das der GC die Objekte aufräumen kann ist unnötig, da stimm ich mit dir überein. Aber wenn man unmanaged Resourcen hat, muss man auch irgendwie garantieren dass man die freigibt - und genau das ist nur durch Implementation von nem Dispose das der User aufrufen "könnte" nicht gegeben. So kann man selbst in .Net Speicherleaks verursachen.
Baka wa shinanakya naoranai.
Mein XING Profil.
Original von talla
@ Robert G
Schau dir mal Herbivores Link an. So empfiehlt es auch Microsoft als Common Practice in .Net. Was nützt ein schönes Dispose wenn niemand es aufruft? Genau dafür ist dieses Pattern gedacht.
Sorry, habe mich (mal wieder) nicht genau genug ausgedrückt.
Ich meinte sowas:
class Miep : IDisposable
{
SomeIDisposableImplementation mööp;
public void Dispose()
{
mööp.Dispose();
}
}
Es macht hier absolut gar keinen Sinn noch einen Finalizer zu haben, wenn SomeIDisposableImplementation schon einen mitbringt.
Und das dürfte hauptsächlich der Fall sein. Unmanaged resources, die nicht bereits in BCL/3rd-Party Klassen gekapselt sind, habe ich selbst fast nur in unsafe code. Oder ich habe sie selbst schon soweit gekapselt damit man sie an mehreren Stellen sicher benutzen kann.
Das solltest du aber nur bei sealed Klassen machen. Sonst setzt du implizit Anforderungen an die abgeleiteten Klassen, die man nicht sofort sieht.
e.f.q.
Aus Falschem folgt Beliebiges
Original von Traumzauberbaum
Das solltest du aber nur bei sealed Klassen machen. Sonst setzt du implizit Anforderungen an die abgeleiteten Klassen, die man nicht sofort sieht. Naja, es spricht eigentlich fast nix dagegen Kassen zu versiegeln, wenn eine Ableitung keinen wirklichen Nutzen bringt. 😉
Und ja, du hast Recht. Das abweichen von den MS-Normen bzw. den geläufigen Normen (müssen ja nicht ewig die von MS bleiben 😉 ) sollte sich einen Hinweis in den Docs verdienen...
Hallo Robert G,
Kassen zu versiegeln ABER NUR WENNS MEINE SIND, andere sollen immer blechen können! 😁 😁
Gruß
Norman-Timo
A: “Wie ist denn das Wetter bei euch?”
B: “Caps Lock.”
A: “Hä?”
B: “Na ja, Shift ohne Ende!”
Eine Frage zu den Regions in VS2005:
Ich bevorzuge es optisch, wenn die Regions immer komplett linksbündig stehen.
Leider lässt sich das nicht konfigurieren.
VS rückt die immer wieder ein, so dass ich immer wieder selber die führenden Whitespaces entfernen muss.
Oder weiß evtl. jemand wie man es doch konfigurieren kann?
Hallo!
@AtzeX:
Das ist doch bestimmt im Optionen-Dialog machbar, da kann man unter Quellcodeeditor so ziemlich alles einstellen.
Nobody is perfect. I'm sad, i'm not nobody 🙁
Original von norman_timo
#region Private Methods #endregion #region Public/Protected Methods #endregionDas habe ich mir als Code-Fragment in die Toolbox gehängt, damit ich jede neue Klasse damit ausstatten kann.
Hi Norman.
Darf ich fragen, warum du Public und Protected Methods zusammenfasst?
Ich hätte eher Private und Protected zusammengefasst oder aber alle drei einzeln.
Aber vielleicht hast du ja einen guten Grund dafür?
Und was für eine Toolbox meinst du?
Gruß,
AtzeX
Hallo AtzeX,
sorry für die späte Antwort, war im Urlaub.
Ich fasse public und protected Methoden deshalb zusammen, da mein Code auch für andere einsehbar ist. Wenn nun jemand "meine" Klasse verwenden/davon ableiten möchte, und will dazu Code sehen, dann interessiert ihn primär alles was public, bzw. protected ist.
Deshalb fasse ich das in der Art zusammen. Alle 3 Bereiche (inkl. private) in einzelne regions zu packen wäre wieder zu umständlich für denjenigen, der schauen will, was die Klasse macht.
Mit der Toolbox meine ich die Code-Snippet Ablage. Du kannst die Toolbox in Visual-Studio nicht nur für den grafischen Designer, sondern auch für Code-Files (eben mit Snippets) benutzen.
Gruß
Norman-Timo
A: “Wie ist denn das Wetter bei euch?”
B: “Caps Lock.”
A: “Hä?”
B: “Na ja, Shift ohne Ende!”