Conventii generale de denumire – Ghid de proiectare a cadrelor

• 22/10/2008
• 3 minute de citit

• • K

  • t

  • n

  • B

  • D

In acest articol

Aceasta sectiune descrie conventiile generale de denumire care se refera la alegerea cuvintelor, liniile directoare privind utilizarea abrevierilor si acronimelor si recomandari despre cum sa evitati utilizarea denumirilor specifice limbii.

Alegerea cuvantului

✔️ Alegeti nume identificatoare usor de citit.

De exemplu, o proprietate numita HorizontalAlignment este mai lizibila in limba engleza decat AlignmentHorizontal.

✔️ FACETI mai usor lizibilitatea decat concizia.

Numele proprietatii CanScrollHorizontally este mai bun decat ScrollableX (o referinta obscura la axa X).

❌ NU utilizati linii de subliniere, cratime sau orice alte caractere nonalfanumerice.

❌ NU folositi notatia maghiara.

❌ EVITATI utilizarea de identificatori care intra in conflict cu cuvintele cheie ale limbajelor de programare utilizate pe scara larga.

Conform Regulii 4 din Specificatia limbii comune (CLS), toate limbile conforme trebuie sa furnizeze un mecanism care sa permita accesul la elemente denumite care utilizeaza un cuvant cheie din limba respectiva ca identificator. C #, de exemplu, foloseste semnul @ ca mecanism de evacuare in acest caz. Cu toate acestea, este inca o idee buna sa evitati cuvintele cheie obisnuite, deoarece este mult mai dificil sa utilizati o metoda cu secventa de evacuare decat una fara ea.

Utilizarea abrevierilor si acronimelor

❌ NU utilizati abrevieri sau contractii ca parte a numelor identificatorilor.

De exemplu, utilizati GetWindow mai degraba decat GetWin.

❌ NU folositi acronime care nu sunt acceptate pe scara larga si chiar daca sunt, numai atunci cand este necesar.

Evitarea denumirilor specifice limbii

✔️ Folositi nume interesante din punct de vedere semantic, mai degraba decat cuvinte cheie specifice limbii pentru numele tipurilor.

De exemplu, GetLength este un nume mai bun decat GetInt.

✔️ Folositi un nume generic de tip CLR, mai degraba decat un nume specific limbii, in cazurile rare in care un identificator nu are o semnificatie semantica dincolo de tipul sau.

De exemplu, o metoda de conversie in Int64 ar trebui sa fie numita ToInt64, nu ToLong (deoarece Int64 este un nume CLR pentru aliasul C-specific lung). Urmatorul tabel prezinta mai multe tipuri de date de baza folosind numele de tip CLR (precum si numele de tip corespunzatoare pentru C #, Visual Basic si C ++).

C # Visual Basic C ++ CRJ sbyte SByte char SByte octet octet nesemnate char octet scurt scurt scurt Int16 ushort UInt16 nesemnate scurt UInt16 int Integer int int32 uint UInt32 nesemnate int UInt32 lung lung __int64 Int64 ulong UInt64 nesemnate __int64 UInt64 float Single float Single dublu dublu dublu dublu bool Boolean bool Boolean char Char wchar_t Char string String String String obiect Obiect Obiect Obiect

✔️ Folositi un nume comun, cum ar fi valoarea sau elementul, mai degraba decat sa repetati numele tipului, in cazurile rare cand un identificator nu are semnificatie semantica si tipul parametrului nu este important.

Denumirea noilor versiuni ale API-urilor existente

✔️ Folositi un nume similar cu vechiul API atunci cand creati versiuni noi ale unui API existent.

Acest lucru ajuta la evidentierea relatiei dintre API-uri.

✔️ NU preferati sa adaugati un sufix decat un prefix pentru a indica o noua versiune a unui API existent.

Acest lucru va va ajuta sa descoperiti cand rasfoiti documentatie sau cand utilizati IntelliSense. Vechea versiune a API-ului va fi organizata aproape de noile API-uri, deoarece majoritatea browserelor si IntelliSense prezinta identificatori in ordine alfabetica.

✔️ Luati in considerare utilizarea unui identificator nou, dar semnificativ, in loc sa adaugati un sufix sau un prefix.

✔️ Folositi un sufix numeric pentru a indica o noua versiune a unui API existent, mai ales daca numele existent al API-ului este singurul nume care are sens (de exemplu, daca este un standard industrial) si daca adaugati orice sufix semnificativ (sau modificati numele) nu este o optiune adecvata.

❌ NU utilizati sufixul „Ex” (sau un similar) pentru un identificator pentru al distinge de o versiune anterioara a aceluiasi API.

✔️ Folositi sufixul „64” atunci cand introduceti versiuni de API-uri care functioneaza pe un numar intreg pe 64 de biti (un intreg lung) in locul unui numar intreg pe 32 de biti. Trebuie sa luati aceasta abordare numai atunci cand exista API-ul existent pe 32 de biti; nu o faceti pentru API-uri noi, cu doar o versiune pe 64 de biti.

Portiuni © 2005, 2009 Microsoft Corporation. Toate drepturile rezervate.

Reimprimata cu permisiunea Pearson Education, Inc. din Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, editia a II-a de Krzysztof Cwalina si Brad Abrams, publicata pe 22 octombrie 2008 de Addison-Wesley Professional ca parte a Microsoft Windows Development Series.

Vezi si

• Linii directoare de proiectare cadru
• Ghiduri de numire
• Conventii de denumire .NET pentru EditorConfig