Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Uwaga / Notatka
Ta treść jest przedrukowana za zgodą Pearson Education, Inc. z Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2. wydanie. Wydanie to zostało opublikowane w 2008 roku, a książka została w pełni zmieniona w trzecim wydaniu. Niektóre informacje na tej stronie mogą być nieaktualne.
W tej sekcji opisano ogólne konwencje nazewnictwa odnoszące się do wyboru wyrazów, wytyczne dotyczące używania skrótów i akronimów oraz zalecenia dotyczące unikania używania nazw specyficznych dla języka.
Dobór słów
✔️ Wybierz łatwo czytelne nazwy identyfikatorów.
Na przykład właściwość o nazwie HorizontalAlignment jest bardziej czytelna w języku angielskim niż AlignmentHorizontal.
Zdecydowanie stawiaj na czytelność, nawet kosztem zwięzłości.
Nazwa właściwości CanScrollHorizontally jest lepsza niż ScrollableX (niejasne odwołanie do osi X).
❌ NIE należy używać podkreśleń, łączników ani innych znaków nieliczbowych.
❌ NIE należy używać notacji węgierskiej.
❌ UNIKAJ używania identyfikatorów, które powodują konflikt ze słowami kluczowymi powszechnie używanych języków programowania.
Zgodnie z regułą 4 specyfikacji języka wspólnego (CLS) wszystkie zgodne języki muszą zapewnić mechanizm umożliwiający dostęp do nazwanych elementów, które używają słowa kluczowego tego języka jako identyfikatora. Na przykład język C#używa znaku @ jako mechanizmu ucieczki w tym przypadku. Jednak nadal dobrym pomysłem jest unikanie typowych słów kluczowych, ponieważ znacznie trudniej jest użyć metody z sekwencją ucieczki niż jedna bez niej.
Używanie skrótów i akronimów
❌ NIE należy używać skrótów ani skurczów w ramach nazw identyfikatorów.
Na przykład użyj polecenia GetWindow zamiast GetWin.
❌ NIE używaj żadnych akronimów, które nie są powszechnie akceptowane, a nawet jeśli są, tylko w razie potrzeby.
Unikanie nazw Language-Specific
✔️ używać semantycznie interesujących nazw zamiast słów kluczowych specyficznych dla języka przy nazwach typów.
Na przykład GetLength jest to lepsza nazwa niż GetInt.
✔️ Należy użyć ogólnej nazwy typu CLR, a nie nazwy specyficznej dla języka, w rzadkich przypadkach, gdy identyfikator nie ma znaczenia semantycznego poza jego typem.
Na przykład metoda konwertując na Int64 powinna mieć nazwę ToInt64, a nie ToLong (ponieważ Int64 jest nazwą CLR dla aliasu longspecyficznego dla języka C#). W poniższej tabeli przedstawiono kilka podstawowych typów danych przy użyciu nazw typów CLR (a także odpowiadających im nazw typów dla języków C#, Visual Basic i C++).
| C# | Visual Basic | C++ | CLR (Wspólne Środowisko Uruchomieniowe) |
|---|---|---|---|
| sbyte | SByte | Char | SByte |
| bajtów | bajt | bez znaku | bajt |
| krótkie | krótki | krótkie | Int16 |
| UInt16 | niepodpisane krótkie | UInt16 | |
| Int | Liczba całkowita | Int | Int32 |
| uint | UInt32 | niepodpisane | UInt32 |
| długi | Długi | __int64 | Int64 |
| ulong | UInt64 | niepodpisane __int64 | UInt64 |
| spławik | Pojedynczy | spławik | Pojedynczy |
| podwójny | Podwójne | podwójny | Podwójne |
| Bool | Boolowski | Bool | Boolowski |
| Char | char | wchar_t | char |
| ciąg | Ciąg | Ciąg | Ciąg |
| obiekt | Obiekt | Obiekt | Obiekt |
✔️ Należy użyć nazwy pospolitej, takiej jak value lub item, zamiast powtarzać nazwę typu, w rzadkich przypadkach, gdy identyfikator nie ma znaczenia semantycznego, a typ parametru nie jest ważny.
Nazywanie nowych wersji istniejących interfejsów API
Zawsze używaj nazwy podobnej do nazwy starego interfejsu API podczas tworzenia nowych wersji istniejącego interfejsu API.
Pomaga to wyróżnić relację między interfejsami API.
✔️ Preferuj dodawanie sufiksu, a nie prefiksu, aby wskazać nową wersję istniejącego interfejsu API.
Ułatwi to odnajdywanie podczas przeglądania dokumentacji lub przy użyciu funkcji IntelliSense. Stary interfejs API zostanie zorganizowany w pobliżu nowych interfejsów API, aby większość przeglądarek i funkcji IntelliSense mogła wyświetlać identyfikatory w kolejności alfabetycznej.
✔️ ROZWAŻ użycie zupełnie nowego, ale znaczącego identyfikatora zamiast dodawania sufiksu lub prefiksu.
✔️ Należy użyć sufiksu liczbowego, aby wskazać nową wersję istniejącego interfejsu API, szczególnie jeśli istniejąca nazwa interfejsu API jest jedyną nazwą, która ma sens (tj. jeśli jest standardem branżowym) i czy dodanie znaczącego sufiksu (lub zmiany nazwy) nie jest odpowiednią opcją.
❌ Nie używaj sufiksu "Ex" (lub podobnego) dla identyfikatora, aby odróżnić go od starszej wersji tego samego interfejsu API.
✔️ Użyj sufiksu "64" podczas wprowadzania wersji interfejsów API, które działają na 64-bitowej liczbie całkowitej (długiej liczby całkowitej) zamiast 32-bitowej liczby całkowitej. To podejście należy stosować tylko wtedy, gdy istnieje istniejący 32-bitowy interfejs API; Nie rób tego w przypadku zupełnie nowych interfejsów API z tylko 64-bitową wersją.
© Części 2005, 2009 Microsoft Corporation. Wszelkie prawa zastrzeżone.
Przedrukowane za zgodą Pearson Education, Inc. z Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition przez Krzysztofa Cwalinę i Brada Abramsa, opublikowane 22 października 2008 przez Addison-Wesley Professional w ramach serii Microsoft Windows Development.