Konwencje kapitalizacji

• 10/22/2008
• 2 minuty na przeczytanie
• • K
  • n

  .

  • B
  • D
  • n
  • +10

Wskazówki zawarte w tym rozdziale określają prostą metodę stosowania przypadków, które, gdy są konsekwentnie stosowane, sprawiają, że identyfikatory typów, członków i parametrów są łatwe do odczytania.

Reguły kapitalizacji dla identyfikatorów

Aby rozróżnić słowa w identyfikatorze, skapitalizuj pierwszą literę każdego słowa w identyfikatorze. Nie używaj podkreśleń do rozróżniania słów, ani w żadnym innym miejscu w identyfikatorach. Istnieją dwa odpowiednie sposoby kapitalizacji identyfikatorów, w zależności od zastosowania identyfikatora:

• PascalCasing

• camelCasing

Konwencja PascalCasing, używana dla wszystkich identyfikatorów z wyjątkiem nazw parametrów, kapitalizuje pierwszy znak każdego słowa (w tym akronimy o długości ponad dwóch liter), jak pokazano w następujących przykładach:

PropertyDescriptorHtmlTag

Specjalnym przypadkiem są akronimy dwuliterowe, w których obie litery są kapitalizowane, jak pokazano na poniższym identyfikatorze:

IOStream

Konwencja camelCasing, stosowana tylko dla nazw parametrów, kapitalizuje pierwszy znak każdego słowa z wyjątkiem pierwszego słowa, jak pokazano na poniższych przykładach. Jak pokazano w przykładzie, dwuliterowe akronimy, które rozpoczynają identyfikator w konwencji camelCasing, są pisane małymi literami.

propertyDescriptorioStreamhtmlTag

✔️ DO użycia PascalCasing dla wszystkich publicznych nazw członków, typów i przestrzeni nazw składających się z wielu słów.

✔️ DO use camelCasing for parameter names.

Następująca tabela opisuje zasady kapitalizacji dla różnych typów identyfikatorów.

.

.

.

Identyfikator	Obudowa	Przykład
Namespace	Pascal	namespace System.Security { ... }
Type	Pascal	public class StreamReader { ... }
Interfejs	Pascal	public interface IEnumerable { ... }
Method	Pascal	public class Object { public virtual string ToString(); }
Właściwość	Pascal	public class String { public int Length { get; } }
Event	Pascal		. public class Process { public event EventHandler Exited; }
Field	Pascal	public class MessageQueue { public static readonly TimeSpan InfiniteTimeout; }. public struct UInt32 { public const Min = 0; }
Wartość enum	Pascal	public enum FileMode { Append, .... }
Parametr	Kamel	public class Convert { public static int ToInt32(string value); }

Kapitalizacja słów złożonych i terminów potocznych

Większość terminów złożonych jest traktowana jako pojedyncze słowa dla celów kapitalizacji.

❌ NIE NALEŻY pisać wielkimi literami każdego słowa w tak zwanych zamkniętych słowach złożonych.

Są to słowa złożone zapisane jako pojedyncze słowo, takie jak endpoint. Dla celów wytycznych dotyczących pisowni należy traktować wyrazy złożone w formie zamkniętej jako pojedyncze słowo. Użyj aktualnego słownika, aby określić, czy słowo złożone jest napisane w formie zamkniętej.

.

Pascal	Kamel	Nie
BitFlag	bitFlag	Bitflag
Callback	callback	CallBack
Canceled	canceled	Cancelled
DoNot	doNot	Don't
Email	email	EMail
Endpoint	endpoint	EndPoint
FileName	fileName	Filename
Gridline	gridline	GridLine
Hashtable	hashtable	HashTable
Id	id	ID
Indexes	indexes	Indices
LogOff	logOff	LogOut
LogOn	logOn	LogIn
Metadata	metadata	MetaData, metaData
Multipanel	multipanel	MultiPanel
Multiview	multiview	MultiView
Namespace	namespace	NameSpace
Ok	ok	OK
Pi	pi	PI
Placeholder	placeholder	PlaceHolder
SignIn	signIn	SignOn
SignOut	signOut	SignOff
UserName	userName	Username
WhiteSpace	whiteSpace	Whitespace
Writable	writable	Writeable

Czułość na wielkość liter

Języki, które mogą działać na CLR nie muszą wspierać czułości na wielkość liter.sensitivity, chociaż niektóre tak. Nawet jeśli twój język go obsługuje, inne języki, które mogą uzyskać dostęp do twojego frameworka, nie obsługują go. Wszelkie interfejsy API, które są dostępne z zewnątrz, nie mogą zatem polegać wyłącznie na wielkości liter w celu rozróżnienia dwóch nazw w tym samym kontekście.

❌ NIE zakładaj, że wszystkie języki programowania uwzględniają wielkość liter. Nie są. Nazwy nie mogą się różnić tylko wielkością liter.

Porcje © 2005, 2009 Microsoft Corporation. Wszelkie prawa zastrzeżone.

Przedrukowano za zgodą Pearson Education, Inc. z dokumentu Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition by Krzysztof Cwalina and Brad Abrams, published Oct 22, 2008 by Addison-Wesley Professional as part of the Microsoft Windows Development Series.

Zobacz także

• Framework Design Guidelines
• Naming Guidelines

.