C# Namensmuster bei Namespaces

[Ghost_Rider_R]

Hallo zusammen,

ich tu mich aktuell noch schwer geeignete Namensräume für meine Projekte zu finden.
Wie macht Ihr das denn so? Im Regelfall würde bei mir der Namensraum immer gleich
wie die Klasse heißen, aber das sollte man ja vermeiden, also mache ich z.B. immer sowas:

Namensraum / Ordner:
Taschenrechner_NS

Klasse:
Taschenrechner.cs

Schnittstelle:
ITaschenrechner.cs

Gerade wenn es nur eine Klasse gibt, welche in einem eigenen Unterordner liegt, dann würde
ich den instinktiv immer wie die Klasse und Schnittstelle nennen, welche in diesem Verzeichnis liegt,
aber dann hat man immer Konflikte. Irgendwann bin ich hingegangen und habe einfach _NS dahinter
gehängt, aber Microsoft macht sowas ja nicht, also gehe ich mal davon aus, dass dies ein schlechter
Stil ist.

Vielen Dank schon mal für eure Herangehensweisen.

LG Ghost Rider

 

[Tornhoof]

Wenn bei dir der Namensraum so heißt wie deine Klasse, ist der Namensraum überflüssig, d.h. der Versuch deiner Granularität ist zu hoch.

Eine klassische Systematik ist nach Projekt zu benennen, bei einem Projekt ist das also trivial.

Allgemein, übertreibe es nicht mit der Strukturierung in Projekten, das ist noch aus einer Zeit als es keine einfachen Mechanismen gab eine Klasse in der Solution zu finden, das ist aber schon seit mehr ls 10 Jahren nicht mehr so.

Das beinhaltet also insbesondere auch so Themen wie eine Klasse pro Unterordner oder ähnliche Konstrukte.

Alles andere ist in den Framework Guidelines beschrieben, also u.A. https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/names-of-namespaces

 

[Digitalzombie]

Üblicherweise habe ich pro Projekt nur ein Namespace und der ist benannt wie das Programm selbst. Klassen werden nach ihrer Funktion benannt.

Persönliche Präferenz. Prinzipiell keine Meinung über andere Stile.

Aber Tornhoof hat recht, bei so einem kleinen Ding brauchst du keine Namespaces. Das wird erst interessant wenn andere Devs dein Programm in Ihrem referenzieren um dessen Funktionen zu nutzen.

 

[Nero1]

Ich benutz gern Basisordner, also sowas wie "Interfaces" für alle Interfaces, die in der Assembly anfallen. Sollten das absehbar viele werden ggf. mit thematischen Unterordnern. Für visuelle Komponenten (Sub Controls usw.) gibts ebenso einen Ordner (Unterordner vice versa) und für Klassen wie deine Taschenrechner.cs ebenso weitere Ordner.
Aber alles dabei als ne Art Überbegriff. Wenn dein ganzes Programm nur aus ein paar wenigen Klassen besteht reicht eine sehr einfache Struktur locker aus, da sagen dir Unterordner, die du genauso benennen willst wie die Klasse, ja auch nicht mehr. Dann brauchst du auch keinen Ordner, wo nur eine "Taschenrechner.cs" drin liegt (oder du nennst ihn halt einfach "Utils"/"Utilities)". Bei großen Projekten sollte man schon mehr drauf achten und sich mehr Gedanken drum machen.

Deine Namespaces hast du ja eh per default "Projektname.Klasse", mit Unterordnern dann eben "Projektname.Unterordner.Klasse". Würde da Ordner nur verwenden, wenn sie dir auch einen Benefit geben, sei es um mehrere Sachen zusammenzufassen oder den Überblick zu verbessern.

 

[Ghost_Rider_R]

Ich benenne mein Root-Namespace auch gerne wie das Projekt (ist ja default so), aber wenn ich jetzt ein kleines Miniprojekt habe, wie einen einfachen Konsolen-Taschenrechner, welcher einfach nur zwei Zahlen addieren kann, dann würde bei mir die einzige Klasse inkl. Main-Methode z.B. Class Taschenrechner heißen. Aber wie was mache ich da dann beim Namespace? Das Projekt heißt bei mir dann ja auch Taschenrechner und Taschenrechner als Namespace wäre bei mir dann Taschenrechner_NS.

 

[Tornhoof]

eh, die main methode sollte eigentlich aus konventionsgründen immer in Program.cs liegen
Wenn du nur eine einzelne Klasse drin hast, dann pack alles in Program.cs.

 

[Nero1]

Das Projekt heißt bei mir dann ja auch Taschenrechner und Taschenrechner als Namespace wäre bei mir dann Taschenrechner_NS.

Dann nenn dein Projekt halt "Taschenrechner" und deine Klasse als das, was sie macht, "MathHelper" oder sowas, dessen Funktionen du dann in der Main aufrufst. Der Taschenrechner ist dein Projekt, deine Klasse nur eine Hilfsklasse für dessen Funktionalität.

Aufbau dann z. B.:

MathHelper.cs
-> Add(a, b)
-> Subtract(a, b)
-> ...

Program.cs
-> Main(args) mit Programmlogik und Verwendungen von MathHelper.Add(), etc.
-> ggf. weitere Hilfsmethoden

 

[Ghost_Rider_R]

...mach ich ja auch, aber ich nenne die Program.cs dann immer um.

 

[Tornhoof]

Nicht machen.

 

[Ghost_Rider_R]

Hatte damit bislang noch die Schwierigkeiten.

 

[Nero1]

Bekommst du aber, sobald du in größeren Projekten arbeitest, weil niemand mehr den Programmeinstieg findet. Standardkonstrukte sind nicht umsonst Standard. Klar geht das, aber es ist echt kein guter Stil. Und bringt dir auch keine Vorteile.

 

[Tornhoof]

Hatte damit bislang noch die Schwierigkeiten.

Das mag ja sein, ist trotzdem bad practice. MS hat ja mittlerweile mit top level statements angefangen um den ganzen Overhead da drin zu reduzieren. Bleib einfach bei Program.cs

 

[Ghost_Rider_R]

Bekommst du aber, sobald du in größeren Projekten arbeitest, weil niemand mehr den Programmeinstieg findet.

Bis jetzt fungiere ich nur als Ein-Mann Armee, da geht das noch 😄.

 

[Raijin]

Trotzdem: Gewöhn dir sowas gar nicht erst an. Nur weil man alleine an etwas arbeitet, heißt das noch lange nicht, dass man alle best practices komplett über Bord wirft. Zum einen weißt du das in ein paar Jahren selbst nicht mehr und zum anderen kann es ja auch sein, dass du mal NICHT allein daran arbeitest.

Program.cs einfach Program.cs sein lassen, Punkt, Aus, MickyMaus.


Was die Namespaces angeht mache ich das immer so:


FirmenName.ProjektName.OrdnerName


Der FirmenName bleibt immer konstant, sei es nun eine tatsächliche Firma oder ein beliebig selbst gewählter Name, sowas wie "GhostRiderTools" oder was weiß ich.

ProjektName ist selbsterklärend.

OrdnerName bezieht sich auf die Strukturierung der Files. Interfaces liegen beispielsweise im Ordner Interfaces und der Namespace dazu ist dann eben GhostRiderTools.Taschenrechner.Interfaces


Auf diese Art vermeidest du so ziemlich alle erdenklichen Konflikte, weil selbst importierte DLLs, o.ä. wohl eher selten "GhostRiderTools.*" als Namespace verwenden, selbst wenn da ebenfalls "Taschenrechner.Interfaces" dabei sind.

 

[sandreas]

Programmierst du eigentlich nur so vor dich hin oder liest du auch mal was? (Code von anderen, Dokumentation, etc.)
Das soll kein Vorwurf sein, aber deine letzten Fragen suggerieren irgendwie, das du mehr Zeit in deinen Projekten verbringst, als dich mit grundlegenden Konzepten oder Dokumentation lesen zu beschäftigen...

Mein Rat: Schnapp dir mal ein größeres Open Source Projekt in C# (ich weiß nicht, ob das ein gutes Beispiel ist, aber https://github.com/jellyfin/jellyfin ist recht groß) und guck dich einfach mal 2 - 3 tage in deren Code um. Du wirst dabei ne Menge lernen, wenn du versuchst, dass, was du nicht verstehst zu recherchieren und in der Doku nachzulesen.

 

[Ghost_Rider_R]

Ich programmiere nur vor mich hin, lese aber recht viel darüber. Andere Quellcodes schau ich mir bislang nicht an, auf diese Idee bin ich aber auch noch nicht gekommen 🤓

 

[sandreas]

Ich kann es nur empfehlen. Insbesondere, wenn du z.B. eine kleine bis mittlere Open Source library verwendest, lohnt es sich, mal drüber nachzudenken: Wie würde ich so was eigentlich programmieren? Und anschließend schaust du dir an, wie es gemacht wurde.

Super Beispiele dafür sind:

• https://github.com/gnaeus/OperationResult
• https://github.com/Tyrrrz/CliWrap
• https://github.com/Tyrrrz/CliFx
• https://github.com/Marusyk/grok.net
• https://github.com/serilog/serilog