În cazul în care folderele dintr-o soluție se potrivesc cu spațiul de nume?

În cazul în care folderele dintr-o soluție se potrivesc cu spațiul de nume?

Într-una dintre proiectele echipelor mele, avem o bibliotecă de clasă care are multe sub-dosare în proiect.

Numele proiectului și spațiul de nume: MyCompany.Project.Section .

În cadrul acestui proiect, există mai multe dosare care se potrivesc cu secțiunea spațiu de nume:

  • Folderul Vehicles are clase în spațiul de nume MyCompany.Project.Section.Vehicles
  • Folderul Clothing are clase în spațiul de nume MyCompany.Project.Section.Clothing
  • etc.

În cadrul aceluiași proiect, este un alt dosar necinstit

  • Folderul BusinessObjects are clase în spațiul de nume MyCompany.Project.Section

Există câteva cazuri ca acest lucru în cazul în care folderele sunt făcute pentru "confort organizațional".

Întrebarea mea este: Care este standardul? În bibliotecile de clasă, dosarele se potrivesc, de obicei, cu structura spațiului de nume sau este un sac mixt?

0
fr hi bn
Notă: ReSharper se va plânge dacă spațiile de nume nu se potrivesc cu ierarhia dosarelor.
adăugat autor Fred, sursa

6 răspunsuri

Da, ar trebui să conducă la confuzie altfel.

0
adăugat

Aș spune că da.

În primul rând, va fi mai ușor să găsiți fișierele de coduri curente urmând în jos zonele de nume (de exemplu, atunci când cineva vă trimite prin e-mail o stivă de apel excepțional). Dacă lăsați dosarele să nu se sincronizeze cu spațiile de nume, găsirea de fișiere în baze de coduri mari devine obositoare.

În al doilea rând, VS va genera noi clase pe care le creați în foldere cu același spațiu de nume al structurii folderului părinte. Dacă vă decideți să înotați împotriva acestui lucru, va fi doar un nou loc de muncă de instalare de a face zilnic atunci când adăugați fișiere noi.

Bineînțeles, este de la sine înțeles că trebuie să fii conservator cu privire la cât de profundă este ierarhia directorului xis / namespace.

0
adăugat

Cred că standardul, în .NET, este de a încerca să o facă atunci când este posibil, dar nu de a crea structuri inutile adânc doar pentru a adera la ea ca o regulă greu. Niciunul dintre proiectele mele nu urmărește 100% din spațiul de nume == structura de structură, uneori chiar mai curată / mai bună pentru a ieși din astfel de reguli.

În Java nu ai de ales. Aș spune că un caz clasic de ceea ce funcționează în teorie față de ceea ce funcționează în practică.

0
adăugat
Aș spune "fa-o când vrei cu adevărat ceva în propriul său spațiu de nume". Ar trebui să fie o decizie conștientă. Dacă proiectele dvs. sunt izolate corespunzător, ar trebui să fie un spațiu de nume pentru fiecare proiect. Dacă clasa se află într-un spațiu de nume, ar trebui să fie într-un dosar cu acel spațiu de nume sau o locație de subfolder care este cel puțin la fel de specifică ca spațiu de nume. O clasă ca Car.Ford.Fusion (dacă Car.Ford este unicul dvs. spațiu de nume) ar trebui să fie într-un folder ca Car / Ford sau mai adânc ca Car / Ford / Sedans, astfel încât folderul să fi
adăugat autor Triynko, sursa
De ce nu este răspunsul acceptat? Ar trebui să fie.
adăugat autor Luty, sursa

De asemenea, rețineți că dacă utilizați șabloanele încorporate pentru a adăuga clase într-un dosar, acesta va fi în mod implicit pus într-un spațiu de nume care să reflecte ierarhia dosarelor.

Clasele vor fi mai ușor de găsit și numai acestea ar trebui să fie destul de bune.

Regulile pe care le respectăm sunt:

  • Numele proiectului / ansamblului este același cu spațiul de nume rădăcină, cu excepția terminării .dll
  • Numai excepția de la regula de mai sus este un proiect cu un capăt ".Core", ".Core este dezbrăcat"
  • Dosarele sunt egale cu spațiile de nume
  • Un tip pe fișier (clasă, struct, enum, delegat etc.) facilitează găsirea fișierului potrivit
0
adăugat
+1 pentru "Numai excepția de la regula de mai sus este un proiect cu un capăt" .Core "," .Core este dezbrăcat " singur. Am un ansamblu MyProject.Core.dll și toate clasele încep cu MyProject.Core . Eliminarea sufixului .Core face mult mai multă sens.
adăugat autor Luiz Damim, sursa
O altă excepție pe care aș putea să o adaug este Excepții. Excepțiile sunt deja sufixate cu "Excepție", astfel încât un spațiu de nume suplimentar este redundant. Se poate, de asemenea, obține dezordonat având o parte din spațiul de nume cu cuvântul Excepție (poate duce la confuzie System.Exception). Cu toate acestea, organizarea lor în dosare este destul de utilă.
adăugat autor phillipwei, sursa

@lassevk: Sunt de acord cu aceste reguli și mai am încă de adăugat.

Când am învățat cursuri, le-am despărțit, câte unul pe dosar. Asa:

// ----- Foo.cs
partial class Foo
{
    // Foo implementation here
}

și

// ----- Foo.Bar.cs
partial class Foo
{
    class Bar
    {
        // Foo.Bar implementation here
    }
}
0
adăugat

Nu.

Am incercat ambele metode pe proiecte mici si mari, atat cu single (eu) cat si cu o echipa de dezvoltatori.

Am descoperit că calea cea mai simplă și cea mai productivă a fost aceea de a avea un singur spațiu de nume pe proiect și toate clasele să intre în acel spațiu de nume. Sunteți liberi să puneți fișierele de clasă în folderul de proiect dorit. Nu există nici o problemă cu privire la adăugarea de declarații în partea de sus a fișierelor tot timpul, deoarece există doar un singur spațiu de nume.

Este important să organizați fișierele sursă în foldere și, după părerea mea, că toate folderele ar trebui folosite. Solicitarea ca aceste foldere să fie de asemenea hărțuită în spațiile de nume nu este necesară, creează mai multă muncă și am constatat că este într-adevăr dăunătoare pentru organizare, deoarece povara adăugată încurajează dezorganizarea.

Luați acest avertisment FxCop, de exemplu:

CA1020: Evitați spațiile de nume cu câteva tipuri
  Cauza: Un spațiu de nume, altul decât spațiul de nume global, conține mai puțin de cinci tipuri    https://msdn.microsoft.com/en-gb/library/ms182130.aspx

Acest avertisment încurajează eliminarea de noi fișiere într-un director generic de proiect, general sau chiar rădăcina proiectului până când aveți patru clase similare pentru a justifica crearea unui nou folder. Se va întâmpla asta vreodată?

Găsirea fișierelor

Răspunsul acceptat spune că "clasele vor fi mai ușor de găsit și că singurele ar trebui să fie motive suficiente".

Bănuiesc că răspunsul se referă la existența mai multor spații de nume într-un proiect care nu se referă la structura de directoare, mai degrabă decât ceea ce sugerez, care este un proiect cu un singur spațiu de nume.

În orice caz, în timp ce nu puteți determina care folder este un fișier de clasă din spațiul de nume, îl puteți găsi utilizând Go To Definition sau caseta de explorare a soluției de căutare din Visual Studio. De asemenea, acest lucru nu este într-adevăr o problemă importantă în opinia mea. Nu cheltuiesc nici măcar 0,1% din timpul meu de dezvoltare pentru a găsi fișiere pentru a justifica optimizarea.

Condamnările cu nume

Sigur creând mai multe spații de nume permite proiectului să aibă două clase cu același nume. Dar este chiar un lucru bun? Poate este mai ușor să renunți la această posibilitate? Permiterea a două clase cu același nume creează o situație mai complexă în care 90% din timp lucrurile funcționează într-un anumit mod și apoi dintr-o dată găsiți că aveți un caz special. Spuneți că aveți două clase de Rectangle definite în spații de nume separate:

  • clasa Project1.Image.Rectangle
  • clasa Project1.Window.Rectangle

Este posibil să apară o problemă pe care un fișier sursă trebuie să includă ambele spații de nume. Acum trebuie să scrieți spațiul de nume complet peste tot în fișierul respectiv:

var rectangle = new Project1.Window.Rectangle();

Sau mizerie cu unele declarație urât folosind:

using Rectangle = Project1.Window.Rectangle;

Cu un singur spațiu de nume în proiectul dvs. sunteți obligat să veniți cu alții și aș susține nume mai descriptive, cum ar fi:

  • clasa Project1.ImageRectangle
  • clasa Project1.WindowRectangle

Și utilizarea este aceeași peste tot, nu trebuie să vă ocupați de un caz special atunci când un fișier utilizează ambele tipuri.

using statements

using Project1.General;  
using Project1.Image;  
using Project1.Window;  
using Project1.Window.Controls;  
using Project1.Shapes;  
using Project1.Input;  
using Project1.Data;  

vs

using Project1;

Usurinta de a nu trebui sa adaugati spatiu de nume in timp ce scrieti codul. Nu este timpul să dureze într-adevăr, este pauza în fluxul de a avea de a face acest lucru și doar umplerea fișierelor cu o mulțime de declarații folosind - pentru ce? Merita?

Changing project folder structure

Dacă folderele sunt mapate în spațiile de nume, calea directorului de proiect este codificată în mod eficient în fiecare fișier sursă. Aceasta înseamnă că orice redenumire sau mutare a unui fișier sau a unui dosar în proiect necesită schimbarea conținutului fișierului real. Atât declarația spațiului de nume al fișierelor din acel dosar, cât și folosirea instrucțiunilor într-o grămadă de alte fișiere care fac referire la clasele din acel dosar. În timp ce schimbările în sine sunt banale cu scule, rezultă de obicei o comitet mare constând din multe fișiere ale căror clase nu s-au schimbat nici măcar.

Cu un singur spațiu de nume în proiect puteți schimba structura folderului de proiect oricum doriți fără ca fișierele sursă să fie modificate.

Visual Studio automatically maps the namespace of a new file to the project folder it's created in

Unfortunate, but I find the hassle of correcting the namespace is less than the hassle of dealing with them. Also I've got into the habit of copy pasting an existing file rather than using Add->New.

Intellisense and Object Browser

Cel mai mare beneficiu, în opinia mea, de a folosi mai multe spații de nume în proiecte mari este organizarea suplimentară atunci când vizionează clase în orice unealtă care afișează clase într-o ierarhie a denumirilor. Chiar și documentația. Evident, având doar un singur spațiu de nume în rezultatele proiectului, toate clasele se afișează într-o singură listă și nu se clasifică în categorii. Cu toate acestea personal nu am fost niciodată lovit sau întârziat din cauza lipsei acestui lucru, așa că nu-i găsesc un beneficiu destul de mare pentru a justifica mai multe spații de nume.

Deși dacă scriam o bibliotecă de clasă publică mare, atunci probabil că ar folosi mai multe spații de nume în proiect, astfel încât ansamblul să părea îngrijit în scule și documentație.

0
adăugat
Aceasta este una dintre cele mai bune sfaturi pe care le-am văzut. Spațiile de nume sunt doar pentru rezolvarea conflictelor, nu pentru organizarea de cursuri. Utilizați spațiile de nume numai acolo unde este logic să le utilizați, cum ar fi cazul în care vă așteptați să aveți conflicte de denumire cu alte proiecte care pot utiliza proiectul dvs., permițând includerea sau excluderea anumitor spații de nume cu ajutorul instrucțiunilor. Este groaznic să aveți un proiect cu 3 sau 4 sau mai multe spații de nume care sunt frecvent utilizate, deoarece întotdeauna rezultă un număr ridicol de utilizăr
adăugat autor Triynko, sursa
Cel mai important punct al spațiilor de nume este de a evita coliziunile și ambiguitățile numelor, corect? Sunt de acord cu 100% despre punctul de utilizare a declarațiilor. Uneori este doar o nebunie pură să aduci în mașini noi când ai un număr de ziduri de zillion / usings. Metodele de extindere reprezintă un exemplu de loc în care IDE este, în general, mai puțin util decât acest lucru. Este la fel de nebun să vă puneți toate fișierele (sau chiar prea multe) într-un singur dosar pentru a evita ruperea regulii spațiului de nume / al dosarului.
adăugat autor jocull, sursa
Sunt de acord cu @BentOnCoding. Un alt lucru pe care postul dvs. îl sugerează, de asemenea, că scrierea spațiilor de nume este, în general, necesară o verbozitate cu clase care au același nume în diferite spații de nume, totuși C# poate grațios cu o folosind directiva Foo as Bar
adăugat autor Evin Ugur, sursa
Este sincer una dintre cele mai multe soluții de coșmar pe care le-am auzit sugerate. Dacă lucrați la proiectele lumii mici hello atunci acest sfat funcționează, dar imaginați-vă că aveți 1000 + .cs fișiere. Ar provoca atât de multe probleme, încât nu știu de unde să încep.
adăugat autor BentOnCoding, sursa
@WeylandYutani Știu că am întârziat, dar trebuie să menționez că această teză: îl puteți găsi utilizând Go To Definition sau caseta de explorare a soluției de căutare din Visual Studio nu este întotdeauna adevărată. Încearcă-o cu multă moștenire și Interfețe ... noroc în găsirea dosarului potrivit.
adăugat autor Emmanuel M., sursa
+1 pentru gândire. Nu cred că sunt gata să-mi reduc spațiile de nume la câte unul pe proiect, dar după ce lucrez pe un cadru amplu, explorez reducerea numărului de spații de nume pentru a reduce numărul de utilizări ale declarațiilor și pentru a ajuta la descoperirea metodelor de extensie. Cred că acest răspuns oferă ceva bun pentru gândire. Mulțumiri.
adăugat autor Lee Gunn, sursa
"dar imaginați-vă că aveți 1000 + .cs fișiere". Am lucrat în proiecte de această dimensiune cu un singur spațiu de nume. Este bine. Ce dezastru crezi că se va întâmpla?
adăugat autor Weyland Yutani, sursa
Am menționat asta, nu consider că este grațios, cred că este un hack
adăugat autor Weyland Yutani, sursa
În ciuda tuturor punctelor valide pe care le pierdeți, deoarece Visual stupid a ales un model și un default. Chiar și mai rău urmează o structură de fișiere virtuale, astfel încât nici chiar dosarul real nu este spațiul de nume care este doar oribil pentru ambele puncte de vedere.
adăugat autor Tommy Holman, sursa