Zasady Nazewnictwa

1 Wstp .............................................................................................................................................................
3
2 Interpretacja zapisw konwencji ................................................................................................................... 4
3 Konwencje nazewnictwa ............................................................................................................................... 5
3.1 Konwencje wielkoci liter ....................................................................................................................... 5
3.1.1 Zasady wielkoci liter dla identyfikatorw ........................................................................................ 5
3.1.2 Wyrnianie zoonych sw............................................................................................................. 6
3.1.3 Wielko liter .................................................................................................................................... 7
3.2 Oglne zasady nazewnictwa ................................................................................................................... 7
3.2.1 Wybr sw ....................................................................................................................................... 7
3.2.2 Uywanie skrtw i akronimw........................................................................................................ 8
3.2.3 Uywanie nazw specyficznych dla jzyka.......................................................................................... 8
3.2.4 Nazywanie nowych wersji istniejcych API ....................................................................................... 9
3.3 Nazwy komponentw ............................................................................................................................. 9
3.4 Nazwy przestrzeni nazw ......................................................................................................................... 9
3.4.1 Przestrzenie nazw i konflikty nazw ................................................................................................. 10
3.5 Nazwy klas, struktur i interfejsw ........................................................................................................ 10
3.6 Nazwy parametrw typw szablonowych ............................................................................................ 11
3.7 Nazwy typw podstawowych ............................................................................................................... 11
3.8 Nazywanie typw wyliczeniowych ....................................................................................................... 12
3.9 Nazywanie typw skadowych .............................................................................................................. 12
3.9.1 Nazwy metod .................................................................................................................................. 12
3.9.2 Nazewnictwo waciwoci............................................................................................................... 12
3.9.3 Nazewnictwo zdarze ..................................................................................................................... 13
3.9.4 Nazewnictwo pl ............................................................................................................................ 13
3.10 Nazewnictwo parametrw ................................................................................................................... 13
3.10.1 Nazewnictwo parametrw przeadowany ................................................................................. 13
3.11 Nazewnictwo zasobw ......................................................................................................................... 13
4 Reguy StyleCop weryfikujce polityk jakoci kodu ................................................................................... 14
4.1 Zasady dokumentacji ............................................................................................................................ 14
4.1.1 SA1611: ElementParametersMustBeDocumented......................................................................... 14
4.1.2 SA1612: ElementParameterDocumentationMustMatchElementParameters ................................ 14
4.1.3 SA1613: ElementParameterDocumentationMustDeclareParameterName ................................... 14
4.1.4 SA1614: ElementParameterDocumentationMustHaveText ........................................................... 15
4.1.5 SA1615: ElementReturnValueMustBeDocumented ....................................................................... 15
4.1.6 SA1616: ElementReturnValueDocumentationMustHaveText ........................................................ 15
4.1.7 SA1617: VoidReturnValueMustNotBeDocumented ....................................................................... 16
4.1.8 SA1619: GenericTypeParametersMustBeDocumentedPartialClass ............................................... 16
4.1.9 SA1620: GenericTypeParameterDocumentationMustMatchTypeParameters .............................. 17
4.1.10 SA1621: GenericTypeParameterDocumentationMustDeclareParameterName ........................ 17
4.1.11 SA1622: GenericTypeParameterDocumentationMustHaveText ................................................ 17
4.1.12 SA1624: PropertySummaryDocumentationMustOmitSetAccessorWithRestrictedAccess ........ 18
4.1.13 SA1625: ElementDocumentationMustNotBeCopiedAndPasted ................................................ 18
4.1.14 SA1627: DocumentationTextMustNotBeEmpty ......................................................................... 18
4.1.15 SA1631: DocumentationMustMeetCharacterPercentage ......................................................... 19
4.1.16 SA1643: DestructorSummaryDocumentationMustBeginWithStandardText ............................. 19
4.1.17 SA1646: IncludedDocumentationXPathDoesNotExist ................................................................ 20
4.1.18 SA1647: IncludeNodeDoesNotContainValidFileAndPath ........................................................... 20
4.1.19 SA1648: InheritDocMustBeUsedWithInheritingClass ................................................................ 21
4.2 Reguy dotyczce utrzymania kodu ...................................................................................................... 21
4.2.1 SA1400: AccessModifierMustBeDeclared ...................................................................................... 21
4.2.2 SA1401: FieldsMustBePrivate ......................................................................................................... 21
4.2.3 SA1402: FileMayOnlyContainASingleType ...................................................................................... 22
4.2.4 SA1403: FileMayOnlyContainASingleNamespace ........................................................................... 22
4.2.5 SA1404: CodeAnalysisSuppressionMustHaveJustification ............................................................. 22
4.2.6 SA1405: DebugAssertMustProvideMessageText ............................................................................ 23
4.2.7 SA1406: DebugFailMustProvideMessageText ................................................................................ 23
4.2.8 SA1407: ArithmeticExpressionsMustDeclarePrecedence ............................................................... 23
4.2.9 SA1408: ConditionalExpressionsMustDeclarePrecedence ............................................................. 24
4.2.10 SA1409: RemoveUnnecessaryCode ............................................................................................ 25
4.2.11 SA1410: RemoveDelegateParenthesisWhenPossible ................................................................ 25
4.2.12 SA1411: AttributeConstructorMustNotUseUnnecessaryParenthesis ........................................ 26
4.3 Reguy nazewnictwa ............................................................................................................................. 26
4.3.1 SA1300: ElementMustBeginWithUpperCaseLetter ........................................................................ 26
4.3.2 SA1301: ElementMustBeginWithLowerCaseLetter ........................................................................ 26
4.3.3 SA1302: InterfaceNamesMustBeginWithI ...................................................................................... 27
4.3.4 SA1303: ConstFieldNamesMustBeginWithUpperCaseLetter.......................................................... 27
4.3.5 SA1304: NonPrivateReadonlyFieldsMustBeginWithUpperCaseLetter ........................................... 27
4.3.6 SA1305: FieldNamesMustNotUseHungarianNotation .................................................................... 28
4.3.7 SA1306: FieldNamesMustBeginWithLowerCaseLetter ................................................................... 29
4.3.8 SA1307: AccessibleFieldsMustBeginWithUpperCaseLetter ............................................................ 30
4.3.9 SA1308: VariableNamesMustNotBePrefixed .................................................................................. 30
4.3.10 SA1310: FieldNamesMustNotContainUnderscore ..................................................................... 30
Strona 1 z 38
4.3.11 SA1311: StaticReadonlyFieldsMustBeginWithUpperCaseLetter ................................................ 31
4.4 Reguy dotyczce porzdku .................................................................................................................. 31
4.4.1 SA1216: UsingStaticDirectivesMustBePlacedAtTheCorrectLocation .............................................. 31
4.5 Reguy dotyczce czytelnoci ................................................................................................................ 32
4.5.1 SA1100: DoNotPrefixCallsWithBaseUnlessLocalImplementationExists.......................................... 32
4.5.2 SA1102: QueryClauseShouldFollowPreviousClause ....................................................................... 32
4.5.3 SA1103: QueryClausesShouldBeOnSeparateLinesOrAllOnOneLine ............................................... 32
4.5.4 SA1104: QueryClauseShouldBeginOnNewLineWhenPreviousClauseSpansMultipleLines ............. 33
4.5.5 SA1105: QueryClausesSpanningMultipleLinesShouldBeginOnOwnLine ........................................ 33
4.5.6 SA1106: CodeMustNotContainEmptyStatements .......................................................................... 33
4.5.7 SA1107: CodeMustNotContainMultipleStatementsOnOneLine ..................................................... 34
4.5.8 SA1108: BlockStatementsMustNotContainEmbeddedComments ................................................. 34
4.5.9 SA1109: BlockStatementsMustNotContainEmbeddedRegions ...................................................... 34
4.5.10 SA1112: ClosingParenthesisMustBeOnLineOfOpeningParenthesis ........................................... 35
4.5.11 SA1113: CommaMustBeOnSameLineAsPreviousParameter ...................................................... 35
4.5.12 SA1114: ParameterListMustFollowDeclaration ......................................................................... 35
4.5.13 SA1120: CommentsMustContainText ........................................................................................ 36
4.5.14 SA1125: UseShorthandForNullableTypes ................................................................................... 36
4.5.15 SA1131: UseReadableConditions ............................................................................................... 36
4.6 Reguy odstpw .................................................................................................................................. 37
4.6.1 SA1029: DoNotSplitNullConditionalOperators ............................................................................... 37
Strona 2 z 38
1 Wstp
Niniejszy dokument stanowi zbir regu oraz wytycznych decydujcych o strukturze kodu rdowego, pisanego
na platform .NET Framework w jzyku C#, oraz zawiera zalecenia dotyczce stosowania dobrych praktyk
programistycznych, ktre powinny by stosowane podczas wytwarzania kodu rdowego. Standard okrela
zalecany sposb nazywania plikw klas oraz interfejsw, metod, zmiennych i staych. Wskazwki zawarte
w dokumencie maj na celu wytworzenie przejrzystego, czytelnego i zrozumiaego kodu rdowego.
Strona 3 z 38
2 Interpretacja zapisw konwencji
Uyte w konwencji zwroty maj nastpujce znaczenie:

MUSI kryterium bezwarunkowo musi by przyjte/wdroone;
POWINIEN kryterium musi by przyjte/wdroone, chyba e jego naruszenie zwikszy czytelno kodu;
MOE - zalecane jest dostosowanie si do kryterium;
NIE POWINIEN opisane kryterium naley zrealizowa, chyba e jego naruszenie zwikszy czytelno kodu (np.
NIE POWINNO by klas bez metod dopuszczone jest uycie klasy bez metod jeeli dziki temu (utworzeniu
takiej klasy) kod bdzie bardziej czytelny);
NIE MOE bezwarunkowo naley zrealizowa kryterium;
UYWAJ jest rwnoznaczne kryterium POWINIEN;
NIE UYWAJ jest rwnoznaczne kryterium NIE POWINIEN;
UNIKAJ jest rwnoznaczne kryterium NIE POWINIEN;
WYBIERAJ jest rwnoznaczne POWINIEN.
Strona 4 z 38
3 Konwencje nazewnictwa
Zwarty zbir konwencji nazewnictwa w programowaniu moe mie istotny wkad w uyteczno kodu. Pozwala
to na uywanie frameworku przez wielu programistw w rnych projektach. Poza zwiz form, nazwy musz
by atwe do zrozumienia i opisywa funkcjonalno elementu.
3.1 Konwencje wielkoci liter
Konsekwentne stosowanie przedstawionych w tym rozdziale rokumentu wytycznych, pozwala znaczco uatwi
analiz identyfikatorw dla typw, ich skadowych i parametrw.
3.1.1 Zasady wielkoci liter dla identyfikatorw
eby wyrni sowa w stosowanych w kodzie nazwach, programista musi uy wielkiej litery do oznaczenia
pocztku kolejnych wyrazw. Nie mona uywa podkrelenia do wyrnienia sowa, ani nigdzie w nazwie
identyfikatora. S dwa waciwe sposoby pisania du liter nazw identyfikatorw, zalenie od uywanych
identyfikatorw:
PascalCasing
camelCasing
Konwencja PascalCasing uywana jest dla wszystkich identyfikatorw oprcz nazw parametrw, pierwszy znak
kadego sowa pisany jest du liter (wczajc akronimy powyej dwch znakw), tak jak pokazane jest
w poniszym przykadzie:
PropertyDescriptor
HtmlTag
Wyjtkiem s akronimy skadajce si z dwch znakw, dla nich oba pierwsze znaki pisze si du liter, jak
pokazano w przykadzie:
IOStream
Konwencja camelCasing uywana jest tylko dla nazw parametrw. Pierwszy znak kadego sowa pisany jest du
liter oprcz pierwszego, jak pokazano w przykadzie. Przykad pokazuje rwnie dwu-znakowy akronim
zaczynajcy si zgodnie z konwencj camelCased dwoma maymi znakami.
propertyDescriptor
ioStream
htmlTag
Nazwy pl prywatnych w klasach powinny by zapisane w konwencji camelCase z dodaniem podkrelnika _
na pocztku. Jest to dobra praktyka uatwiajca odrnienie pl od lokalnych zmiennych podczas analizy kodu
metod. Przykady:
_propertyDescriptor
_ioStream
_htmlTag
Uywaj PascalCasing dla wszystkich publicznych funkcji, typw i przestrzeni nazw skadajcych si z wielu
sw.
Uywaj camelCasing dla nazw parametrw, zmiennych lokalnych.
Uywaj camelCasing z podkrelnikiem przed nazw dla nazw pl prywatnych w klasach.
Ponisza tabela opisuje zasady pisanie du liter dla rnych typw identyfikatorw.
Identyfikator Konwencja Przykad
wyrniania
Przestrze nazw Pascal namespace System.Security { ... }
Typ Pascal public class StreamReader { ... }
Strona 5 z 38
Interfejs Pascal public interface IEnumerable { ... }
Metoda Pascal public class Object

{
public virtual string ToString();
}
Waciwo Pascal public class String
{
public int Length { get; }
}
Zdarzenie Pascal public class Process
{
public event EventHandler Exited;
}
Pole publiczne Pascal public class MessageQueue
{
public static readonly TimeSpan InfiniteTimeout;
}
public struct UInt32
{
public const Min = 0;
}
Pole prywatne Camel z public class MyClass
podkrelnikiem {
private string _myField;
}
Warto Pascal public enum FileMode
wyliczeniowa {
Append,
...
}
Parametr Camel public class Convert
{
public static int ToInt32(string value);
}
3.1.2 Wyrnianie zoonych sw
Zoone sowa naley pisa jako pojedyncze sowa, tak jakby byy jednym. Dla celw zasad wyrniania naley
traktowa zoone sowa jako pojedyncze. Aby zweryfikowa, czy sowo jest sowem zoonym pisanym razem
czy oddzielnie, naley w przypadku wtpliwoci skorzysta ze sownika.
Nie wyrniaj kadego sowa wielk liter w tak zwanej zamknitej formie zoonych sw.
Przykad nazewnictwa:
Pascal Camel Niepoprawne
nazewnictwo
BitFlag bitFlag Bitflag
Callback callback CallBack
Canceled canceled Cancelled
DoNot doNot Don't
Strona 6 z 38
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
3.1.3 Wielko liter

Jzyki uruchamiane na CRL (ang. Common Language Runtime) nie musz rozrnia wielkoci znakw, cho
niektre to robi. Nawet jeli jzyk, ktrego uywasz, rozrnia wielko liter, inny jzyk uywajcy Twojego
framework-u nie musi. Jakiekolwiek API, ktre jest dostpne z zewntrz nie moe bazowa na rozrnianiu
wielkoci liter, w celu rozrniania dwch nazw w tym samym kontekcie.
Nie zakadaj, e wszystkie jzyki programowania rozrniaj wielko liter. Nazwy nie mog rni si tylko
wielkoci liter.
3.2 Oglne zasady nazewnictwa

Ten rozdzia opisuje oglne konwencje nazewnictwa, ktra mog by zalene od wybranych sw, zasad dla
uywanych skrtw i akronimw oraz zalecenia jak unikn nazw specyficznych dla jzyka.
3.2.1 Wybr sw
Strona 7 z 38
Wybieraj nazwy identyfikatorw atwe do odczytania. Dla przykadu waciwo nazwana
HorizontalAlignment jest bardziej czytelna ni AlignmentHorizontal.
Wybieraj czytelno zamiast zwizoci. Waciwo nazwana CanScrollHorizontally jest lepsza, ni
ScrollableX (niejasne odniesienie do osi X).
Nie uywaj podkrele, mylnikw ani adnych innych niealfanumerycznych znakw.
Nie uywaj Wgierskiej notacji.
Unikaj uywania identyfikatorw, ktre wchodz w konflikt ze sowami kluczowymi uywanymi
w popularnych jzykach programowania.
3.2.2 Uywanie skrtw i akronimw
Nie uywaj skrtw lub skrce, jako czci nazw identyfikatorw. Przykadowo uyj GetWindow zamiast
GetWin.
Nie uywaj adnych akronimw, ktre nie s szeroko akceptowalne i nawet jeli s, tylko, kiedy s
konieczne.
3.2.3 Uywanie nazw specyficznych dla jzyka
Uywaj semantycznie interesujcych nazw zamiast sw kluczowych specyficznych dla nazw typw.
Przykadowo GetLenght jest lepsz nazw ni GetInt.
Uywaj nazw typw specyficznych dla CLR, zamiast nazw specyficznych dla jzyka, w rzadkich przypadkach
kiedy identyfikator nie ma semantycznego znaczenia poza swoim typem. Przykadowo metoda
konwertujca do Int64 powinna nazywa si ToInt64, a nie ToLong, (poniewa Int64 jest nazw z CLR dla
aliasu long specyficznego w C#),
Poniej tabela typw i ich mapowania na odpowiednie typy CLR:
C# Visual Basic C++ CLR
sbyte SByte char SByte
byte Byte unsigned char Byte
short Short short Int16
ushort UInt16 unsigned short UInt16
int Integer int Int32
uint UInt32 unsigned int UInt32
long Long __int64 Int64
ulong UInt64 unsigned __int64 UInt64
float Single float Single
double Double double Double
bool Boolean bool Boolean
char Char wchar_t Char
Strona 8 z 38
string String String String
object Object Object Object
Uywaj powszechnych nazw takich jak value lub item zamiast powtarza nazw typu, tylko w rzadkich
przypadkach, kiedy identyfikator nie ma semantycznego znaczenia i typ parametru nie jest wany.
3.2.4 Nazywanie nowych wersji istniejcych API
Uywaj nazw podobnych do dotychczasowych, kiedy tworzysz nowe wersje istniejcego API. Jest to
pomocne podczas uwydatniania powizania midzy wersjami API.
Preferowane jest dodawanie sufiksw zamiast prefiksw do oznaczenia nowej wersji istniejcego API.
Uatwia to przegldanie dokumentacji lub uywanie podpowiedzi. Stare wersje API bd reprezentowane
blisko nowych, poniewa wikszo przegldarek i podpowiedzi pokazuje identyfikatory w porzdku
alfabetycznym.
Rozwa uycie nowego, ale wyrazistego identyfikatora zamiast dodawania sufiksu albo prefiksu.
Uyj numerycznego sufiksu do zaznaczenia nowej wersji istniejcego API, szczeglnie, jeeli istniejca
nazwa API jest tylko nazw majc sens (tzn., jeli jest standardem przemysowym) i jeeli dodanie
jakiegokolwiek znaczcego sufiksu (lub zmiana nazwy) nie jest waciw opcj.
Nie uywaj sufiksu Ex (lub podobnego) do rozrnienia identyfikatora od wczeniejszej wersji tego
samego API.
Uywaj sufiksu, 64 kiedy wprowadzasz wersje API operujcego na 64-bitowym integer zamiast 32-
bitowym integer. Zastosujesz ten sposb jedynie do istniejcego 32-bitowego istniejcego API; nie uywaj
go do nowego jedynie 64-bitowego API.
3.3 Nazwy komponentw
W aspekcie zarzdzania kodem programu assembly (podzesp) jest jednostk rozlokowania i identyfikacji.
Wybieraj nazwy dla Twojego assembly ktre sugeruj due zakresy funkcjonalnoci, jak System.Data.
Nazwy assembly i bibliotek nie musz odpowiada nazw przestrzeni nazw, ale rozsdnie jest uywanie
podobnych nazw. Dobr praktyk jest nadawanie bibliotek nazw opartych na prefiksie zawartym w nazwie
zawierajcego assembly. Przykadowo assembly z dwoma przestrzeniami nazw
MyCompany.MyTechnology.FirstFeature and MyCompany.MyTechnology.SecondFeature moe by nazwany
MyCompany.MyTechnology.dll.
Rozwa nazywanie bibliotek wedug nastpujcego wzorca:
<company>.<Component>.dll, gdzie <Component> zawiera jedne lub wicej czonw oddzielonych kropk.
Przykadowo Litware.Controls.dll.
3.4 Nazwy przestrzeni nazw
Tak jak z innymi wytycznymi nazewnictwa, celem jest stworzenie wystarczajco klarownej nazwy przestrzeni
nazw, tak eby programista uywajcy mechanizmw mg natychmiast domyli si, do czego suy zawarto
przestrzeni nazw. Poniszy szablon specyfikuje oglne zasady nazywania przestrzeni nazw:
<Company>.(<Product>|<technology>)[<Feature>][.<Subnamespace>]
Przykad:
Fabrikam.Math
Litware.Secutiry
Uywaj staej, niezalenej od wersji produktu nazwy na kolejnych poziomach przestrzeni nazw.
Strona 9 z 38
Nie uywaj hierarchii organizacji, jako podstawy dla nazw w hierarchii przestrzeni nazw, poniewa grupa
nazw z uywana przez korporacje maj skonno do krtkiego istnienia. Organizuj hierarch przestrzeni
nazw wok grup powizanych technologii.
Rozwa uywanie wielu przestrzeni nazw tam gdzie jest to waciwe. Przykadowo uywaj
System.Collections zamiast System.Collection. Nazwy firmowe i akronimy s wyjtkiem od rej reguy.
Niektre kompilatory wymagaj cakowicie zdefiniowanej nazwy typu.
3.4.1 Przestrzenie nazw i konflikty nazw
Nie nadawaj gwnym typom nazw takich jak Elelement, Node, Log i Message. Jest bardzo due
prawdopodobiestwo wystpienia konfliktu nazw w przypadku zastosowania tych sw. Powiniene
ogranicza gwne nazwy typw (FormElement, XmlNode, EventLog, SoapMessage).
S specjalne wytyczne opisujce jak unikn konfliktw nazw dla rnych kategorii przestrzeni nazw.
Model przestrzeni nazw aplikacji
Przestrzenie nazw nalece do pojedynczych modelw aplikacji czsto uywane s razem, ale prawie nigdy
nie s uywane z przestrzeniami nazw innego modelu aplikacji. Przykadowo przestrze nazw
SystemWindows.Forms jest bardzo rzadko uywana z System.Web.UI. Poniej przedstawiono list dobrze
znanych grup przestrzeni nazw modelu aplikacji:
System.Windows*
Sustem.Web.UI*
Nie pozwalaj nadawa tylko samych nazw typom w przestrzeni nazw w tym samym modelu aplikacji.
Przykadowo nie dodawaj typu nazwanego Page do przestrzeni nazw System.Web.Us.Adapters,
poniewa zawiera ju typ tak nazwany.
Infrastruktura przestrzeni nazw
Ta grupa zawiera przestrzenie nazw, ktra s rzadko importowane podczas tworzenia wikszoci aplikacji.
Przykadowo przestrze nazw .Design jest uywana gwnie podczas programowania narzdzi dla
programistw. Unikanie konfliktw z typami w tej przestrzeni nazw nie jest istotne.
Gwne przestrzenie nazw
Gwne przestrzenie nazw zawieraj wszystkie systemowe (System) przestrzenie nazw, wyczajc
przestrzenie modelu aplikacji i infrastruktur przestrzeni nazw. Gwne przestrzenie nazw zawieraj
wszystkie inne System, System.IO, System.Xml iSystem.Net.
Nie nadawaj typom nazw mogcych wej w konflikt z jakkolwiek gwn przestrzeni nazw.
Przykadowo nigdy nie uywaj Stream, jako nazwy typu. Mogoby to wej w konflikt z
System.IO.Stream, ktra jest czsto uywana.
Technologia grup przestrzeni nazw
Ta kategoria zawiera wszystkie przestrzenie nazw z pierwszymi dwoma takimi samymi wzami przestrzeni
nazw (<Company>.<Technology>), takie jak Microsoft.Build.Utilities i Microsoft.Build.Tasks. Jest wane
eby typy nalece do tej samej technologii nie powodoway konfliktu pomidzy sob.
Nie przydzielaj nazw typw, ktre mgby by wywoa konflikt z innymi typami tej samej technologii.
Nie wprowadzaj nazw typw mogcych stworzy konflikt pomidzy typami w technologii i modelu
przestrzeni nazw aplikacji (chyba, e technologia nie jest przeznaczona do uytku z modelem aplikacji).
3.5 Nazwy klas, struktur i interfejsw
Wytyczne nazewnictwa, ktre moesz powszechnie stosowa do nazywania typw.

Nazywaj klasy i struktury rzeczownikw lub wyrae rzeczownikowych, uywajc PascalCasing.
Rozrnia to nazwy typw od metod, ktre s nazwane frazami czasownikowymi.
Nazywaj interfejsy zwrotami przymiotnikowymi, okazjonalnie rzeczownikami lub wyraeniami
czasownikowymi.
Rzeczowniki i zwroty rzeczownikowe powinny by rzadko uywane, mog one wskazywa, e powinna
zosta uyta klasa abstrakcyjna zamiast interfejsu.
Nie uywaj prefiksw na nazwach klas (np. C)
Strona 10 z 38
Rozwa zakoczenie nazwy klasy pochodnej nazw klasy bazowej
Jest to bardzo atwo czytelne i wyjania jasno relacje. Przykady tego s w kodzie:
ArgumentOutOfRangeException, jest rodzajem Exception, drugi przykad SerializableAttribute jest
rodzajem Attribute. Jednake wane jest uywanie rozwane stosowanie tej wytycznej; Przykadowo klasa
Button jest rodzajem zdarzenia Control, aczkolwiek Control nie pojawia si w jej nazwie.
Uywaj prefiksu I w nazwach interfejsw do zaznaczenia, e typ jest interfejsem.
Przykadowo IComponent (rzeczownik opisujcy), ICustomAttributeProvider (wyraenie rzeczownikowe) i
IPersistable (Przymiotnik) s waciwymi nazwami interfejsw. Podobnie jak w przypadku innych nazw,
naley unika skrtw.
Zagwarantuj eby nazwy interfejsu i klasy go definiujcej rniy si jedynie prefiksem I, w przypadku,
kiedy klasa jest standardow implementacj interfejsu.
3.6 Nazwy parametrw typw szablonowych

Uywaj oglnej, opisujcej nazwy typu parametru chyba, e jedno-znakowa nazwa jest cakowicie
oczywista i dodatkowy opis nie doda wicej informacji.
Rozwa uycie T jako nazwy typu parametru dla typw z jedno znakowym parametrem.
public int IComparer<T> { ... }

public delegate bool Predicate<T>(T item);
public struct Nullable<T> where T:struct { ... }
Uywaj prefiksu opisujcego typ parametru nazywanego z T.
public interface ISessionChannel<TSession> where TSession : ISession

{
TSession Session { get; }
}
Rozwa wskazanie ograniczenia dotyczcego typu parametru w nazwie parametru.
Przykadowo parametr ograniczony do ISession moe by nazwany TSession.
3.7 Nazwy typw podstawowych
Przestrzegaj wytycznych opisanych w poniszej tabeli, kiedy nadajesz nazwy typom pochodnym lub
implementujcym pewne typy nalece do Framework-u .Net
Podstawowy Typ Wytyczne typw poczodnych/implementujcych
Dodawaj sufiks Attribute do nazw niestandardowych klas atrybutu.

System.Attribute
Dodawaj sufiks EventHandler do nazw delegat uywanych w
zdarzeniu.
System.Delegate Dodawaj sufiks Callback do nazw delegat innych ni uywane do
obsugi zdarze.
Nie dodawaj sufiksu Delegate do delegat.
Dodawaj sufiks EventArgs.
System.EventArgs
Nie rozbudowuj tej klasy; uyj sowa kluczowego wspieranego przez
System.Enum Twj jzyk; Przykadowo w C# uyj sowa kluczowego enum.
Nie dodawaj sufiksu Enum lub Flag.
Dodaj sufiks Exception.
System.Exception
Dodaj sufiks Disctionary. Zauwa e IDictionary jest specyficznym
IDictionary
typem kolekcji, ale ta wytyczna stanowi precedens w stosunku do
IDictionary<TKey,TValue>
oglnych wytycznych dotyczcych kolekcji.
IEnumerable Dodaj sufiks Collection
ICollection
IList
Strona 11 z 38
IEnumerable<T>
ICollection<T>
IList<T>
Dodaj sufiks Stream.
System.IO.Stream
CodeAccessPermission Dodaj sufiks Permission.
IPermission
3.8 Nazywanie typw wyliczeniowych
Nazwy typw wyliczeniowych (nazywanych take enumeracjami) powinny przestrzega standardowych zasad
nazywania typw (PascalCasing itp.). Jednake jest kilka dodatkowych wytycznych majcych zastosowania do
typw wyliczeniowych.
Uywaj liczby pojedynczej nazwy typu dla enumeracji chyba, e jej wartoci s polami bitowymi.
Uywaj liczby mnogiej nazwy typu dla enumeracji zawierajcej pola bitowe, take zwanymi flagami
enumeracji.
Nie uywaj sufiksu Enum w nazwie typu wyliczeniowego.
Nie uywaj sufiksu Flag lub Flags w nazwie typu wyliczeniowego.
Nie uywaj prefiksw dla nazw wartoci enumeracji (np. ad dla enumeracji ADO, rft dla enumeracji
rich text itd.).
3.9 Nazywanie typw skadowych

Na typy skadaj si skadowe: metody, waciwoci, zdarzenia, konstruktory i pola. Poniszy rozdzia opisuje
wytyczne nazywania typw skadowych.
3.9.1 Nazwy metod
Poniewa metody maj moliwo podejmowania dziaania, wytyczne konstrukcji wymagaj eby nazwy metod
byy czasownikami lub wyraeniami czasownikowymi. Przestrzegajc tej zasady suy take rozrnianiu nazw
metod od waciwoci i nazw typw, ktre s rzeczownikami lub zwrotami przymiotnikowymi.
Nadawaj metod nazwy, ktre s czasownikami lub wyraeniami rzeczownikowymi.
public class String {

public int CompareTo(...);
public string[] Split(...);
public string Trim();
}
3.9.2 Nazewnictwo waciwoci
W odrnienie od innych skadowych, waciwoci powinny by nazywane za pomoc zwrotu
rzeczownikowego lub przymiotnika. Jest tak, poniewa waciwo odwouje si do danych, a nazwa
waciwoci to odzwierciedla. PascalCasing jest zawsze uywany do nazw waciwoci.
Nazywaj waciwoci uywajc rzeczownika, zwrotu rzeczownikowego lub przymiotnika.
Nie uywaj waciwoci, ktre zawieraj nazw metody Get jak w poniszym przykadzie:
public string TextWriter { get {...} set {...} }
public string GetTextWriter(int value) { ... }
Ten szablon wskazuje, e ta waciwo powinna by metod.
Nazywaj waciwoci kolekcji uywajc liczby mnogiej zamiast pojedynczej formy List lub Is, Can,
Has, opisuje to pozycje w kolekcji, ale tylko tam gdzie warto jest dodawana.
Rozwa nadanie waciwoci tej samej nazwy co typowi.
Przykadowo poprawne jest nazwanie waciwoci Color, ktra pobiera i ustawia warto typu
wyliczeniowego nazwanego Color:
public enum Color {...}
public class Control {
public Color Color { get {...} set {...} }
}
Strona 12 z 38
3.9.3 Nazewnictwo zdarze
Zdarzenia zawsze odpowiadaj wykonaniu jakiej akcji, w obu przypadkach wydarzenia lub wystpienia.
Jednake tak jak z metodami, zdarzenia nazywane s czasownikami i czasami czasownikw eby zaznaczy czas
w ktrym zdarzenie jest osigane.
Nazywaj zdarzenia za pomoc czasownikw lub zwrotw czasownikowych. Przykadowo Clicked, Painting,
DroppedDown i tak dalej.
Nadawaj zdarzeniom nazwy z pojciem przed i po, uywajc czasu teraniejszego i przeszego
Przykadowo zdarzenie zamknicia, ktre jest osigane przed zamkniciem okna moe zosta nazwane
Closing oraz takie, ktre jest osigane po zamkniciu moe nosi nazw Closed.
Nie uywaj prefiksw lub postfiksw Before i After do zaznaczenia zdarze wystpujcych przed i po.
Uyj czasu teraniejszego i przeszego jak opisano.
Nazywaj uchwyty zdarze (delegaty uywane, jako typy zdarze) z sufiksem EventHandler, jak pokazano
w poniszym przykadzie:
public delegate void ClickedEventHandler(object sender, ClickedEventArgs e);
Uyj dwch parametrw nazwanych sender i e w uchwycie zdarzenia. Parametr sender reprezentuje
obiekt, ktry osign zdarzenie, jest on typu Object nawet jeli moliwe jest uycie dokadniejszego typu.
Nazwij klas argumentu zdarzenia z pomoc sufiksu EventArgs.
3.9.4 Nazewnictwo pl
Wytyczne dotyczce nazywania pl dotycz tylko statycznych publicznych i chronionych pl. Wewntrzne i
prywatne pola nie s objte wytycznymi. W przypadku publicznych lub chronionych pl wytyczne
projektowania skadowych nie s dopuszczalne.
Uywaj PascalCasing w nazwach pl.
Nazywaj pola uywajc rzeczownikw, zwrotw rzeczownikowych lub przymiotnikw.
Nie uywaj prefiksu dla nazw pl. Przykadowo nie uywaj g_ lub s_ do zaznaczenia pola statycznego.
3.10 Nazewnictwo parametrw

Poza oczywistymi wzgldami czytelnoci, wane jest przestrzeganie wytycznych nazywania parametrw,
poniewa s one wywietlane w dokumentacji oraz w designerze, kiedy wspiera on podpowiedzi i przegldanie
funkcjonalnoci klas.
Uywaj camelCasing w nazwach parametrw.
Uywaj opisowych nazw parametrw.
Rozwa uywanie nazw opartych na znaczeniu parametru, zamiast na jego typie.
3.10.1 Nazewnictwo parametrw przeadowany

Uyj nazw left i right, jeli parametry dwuargumentowego operatora nie maj znaczenia.
Uyj nazwy value dla parametrw operatorw unarnych, ktre nie maj znaczenia.
Rozwa znaczenie nazw parametrw przeadowanych operatorw, jeli jakie maj nadaj im wymowne
wartoci.
3.11 Nazewnictwo zasobw

Poniewa lokalizowane zasoby mog odwoywa si do ustalonych obiektw, tak jakby byy waciwociami,
wytyczne nazywania zasobw s podobne do wytycznych nazywania waciwoci.
Uywaj PascalCasing w identyfikatorach zasobw.
Uyj opisowych zamiast krtkich identyfikatorw.
Nie uywaj specyficznych dla jzyka sw kluczowych gwnego jzyka CLR.
Uywaj tylko alfanumerycznych znakw i podkrelenia w nazwach zasobw.
Uywaj poniszej konwencji nazywania zasobw komunikatw wyjtkw.
Identyfikator zasobu powinien zawiera nazw typu wyjtku i krtki identyfikator wyjtku:
ArgumentExceptionIllegalCharacters
ArgumentExceptionInvalidName
ArgumentExceptionFileNameIsMalformed
Strona 13 z 38
4 Reguy StyleCop weryfikujce polityk jakoci kodu
4.1 Zasady dokumentacji
4.1.1 SA1611: ElementParametersMustBeDocumented
TypeName FieldNamesMustNotContainUnderscore
CheckId SA1611
Category Documentation Rules
Przyczyna
Przynajmniej jeden parametr metody, konstruktora, delegaty lub indeksera nie zosta
udokumentowany.
Opis reguy
Skadnia C# pozwala na dokumentowanie klas i jej elementw bezporednio w kodzie za pomoc
znacznikw XML wewntrz komentarzy znajdujcych si przed opisywanymi elementami. Regua
zostanie zamana, jeli taka dokumentacja nie bdzie zawiera opisw wszystkich parametrw.
Jak skorygowa bd
Uzupeni opis korzystajc ze znacznika <param> dla kadego z parametrw.
/// <summary>
/// Joins a first name and a last name together into a single string.
/// </summary>
/// <param name="firstName">The first name to join.</param>
/// <param name="lastName">The last name to join.</param>
/// <returns>The joined names.</returns>
public string JoinNames(string firstName, string lastName)
{
return firstName + " " + lastName;
}
4.1.2 SA1612: ElementParameterDocumentationMustMatchElementParameters
TypeName ElementParameterDocumentationMustMatchElementParameters
CheckId SA1612
Przyczyna
Dokumentacja opisujca parametry metody, konstruktora, delegaty lub indeksera nie odpowiada
faktycznym parametrom elementu.
Opis reguy
zostanie zamana, jeli dokumentacja parametrw nie bdzie spenia tej samej kolejnoci, co
parametry elementu.
Jak skorygowa bd
Naley poprawi dokumentacj parametrw w znacznikach <param> tak, aby opisy parametrw miay
kolejno ich wystpowania, a take aby na kady parametr przypada jeden opis w znaczniku
<param>.
4.1.3 SA1613: ElementParameterDocumentationMustDeclareParameterName

TypeName ElementParameterDocumentationMustDeclareParameterName
CheckId SA1613
Strona 14 z 38
Przyczyna
Tag <param> dokumentacji elementu nie zawiera atrybutu z nazw opisywanego parametru.
Opis reguy
zostanie zamana, jeli dokumentacja przynajmniej jednego z parametrw nie bdzie zawiera
atrybutu z nazw opisywanego parametru.
Jak skorygowa bd
Naley poprawi dokumentacj parametrw w znacznikach <param> tak, aby kady z nich posiada
parametr name z nazw opisywanego parametru.
4.1.4 SA1614: ElementParameterDocumentationMustHaveText

TypeName ElementParameterDocumentationMustHaveText
CheckId SA1614
Przyczyna
Tag <param> dokumentacji elementu jest pusty.
Opis reguy
zostanie zamana, jeli dokumentacja przynajmniej jednego z parametrw bdzie pusta.
Jak skorygowa bd
Naley uzupeni brakujcy opis parametru w znaczniku <param>.
4.1.5 SA1615: ElementReturnValueMustBeDocumented
TypeName ElementReturnValueMustBeDocumented
CheckId SA1615
Przyczyna
W dokumentacji elementu C# brakuje opisu dla wartoci zwracanej.
Opis reguy
zostanie zamana, jeli dokumentacja nie bdzie zawiera opisu wartoci zwracanej (jeli metoda nie
jest typu void).
Jak skorygowa bd
Naley uzupeni brakujcy opis wartoci zwracanej w znaczniku <returns>.
4.1.6 SA1616: ElementReturnValueDocumentationMustHaveText
TypeName ElementReturnValueDocumentationMustHaveText
CheckId SA1616
Strona 15 z 38
Przyczyna
W dokumentacji elementu C# tag <returns> jest pusty.
Opis reguy
zostanie zamana, jeli w dokumentacji opis wartoci zwracanej bdzie pusty (jeli metoda nie jest
typu void).
Jak skorygowa bd
Naley uzupeni brakujcy opis wartoci zwracanej w znaczniku <returns>.
4.1.7 SA1617: VoidReturnValueMustNotBeDocumented
TypeName ElementReturnValueDocumentationMustHaveText
CheckId SA1617
Przyczyna
Element C# nie zwraca wartoci, lecz w dokumentacja zawiera jej opis w znaczniku <returns>.
Opis reguy
zostanie zamana, jeli w dokumentacji zostaa opisana warto zwracana, ale metoda jest typu void.
Jak skorygowa bd
Naley usun tag <returns> z dokumentacji.
4.1.8 SA1619: GenericTypeParametersMustBeDocumentedPartialClass

TypeName GenericTypeParametersMustBeDocumentedPartialClass
CheckId SA1619
Przyczyna
Dokumentacja generycznego, czciowego (partial) elementu C# nie zawiera dokumentacji dla
jednego z generycznych parametrw.
Opis reguy
zostanie zamana, jeli w dokumentacji nie zostay opisane wszystkie parametry generyczne.
Opisywanie generycznych parametrw nie jest konieczne, jeli nie jest dokumentowana gwna cz
klasy. Wtedy naley zamieni znacznik <summary> na <content>.
Jak skorygowa bd
Naley uzupeni dokumentacj wewntrz znacznika <typeparam> dla kadego z generycznych
parametrw elementu lub zmieni znacznych <summary> na <content>, jeli nie jest to gwna cz
klasy.
Strona 16 z 38
4.1.9 SA1620: GenericTypeParameterDocumentationMustMatchTypeParameters
TypeName GenericTypeParameterDocumentationMustMatchTypeParameters
CheckId SA1620
Przyczyna
Tag <typeparam> w dokumentacji generycznego elementu C# nie odpowiada generycznemu typowi
parametrw tego elementu.
Opis reguy
zostanie zamana, jeli w dokumentacji wymienione znaczniki <typeparam> nie odpowiadaj
kolejnoci wystpowania parametrw generycznych.
Jak skorygowa bd
Naley uzupeni dokumentacj wewntrz znacznika <typeparam> dla kadego z generycznych
parametrw elementu i upewni si, e znaczniki <typeparam> wystpuj w tej samej kolejnoci, co
parametry.
/// <summary>
/// A sample generic class.
/// </summary>
/// <typeparam name="S">The first generic type parameter.</typeparam>
/// <typeparam name="T">The second generic type parameter.</typeparam>
public class Class1<S, T>
{
}
4.1.10 SA1621: GenericTypeParameterDocumentationMustDeclareParameterName

TypeName GenericTypeParameterDocumentationMustDeclareParameterName
CheckId SA1621
Przyczyna
Tag <typeparam> w dokumentacji generycznego elementu C# nie zawiera atrybutu z prawidow
nazw opisywanego elementu.
Opis reguy
zostanie zamana, jeli w dokumentacji wymienione znaczniki <typeparam> nie posiadaj prawidowo
uzupenionych atrybutw z nazw opisywanych parametrw generycznych.
Jak skorygowa bd
Naley uzupeni atrybut name znacznika <typeparam> ktrego dotyczy zamanie reguy.
4.1.11 SA1622: GenericTypeParameterDocumentationMustHaveText
TypeName GenericTypeParameterDocumentationMustHaveText
CheckId SA1622
Strona 17 z 38
Przyczyna
Tag <typeparam> w dokumentacji generycznego elementu C# jest pusty.
Opis reguy
zostanie zamana, jeli w dokumentacji przynajmniej jeden ze znacznikw <typeparam> jest pusty.
Jak skorygowa bd
Naley uzupeni pusty znacznik <typeparam>.
4.1.12 SA1624: PropertySummaryDocumentationMustOmitSetAccessorWithRestrictedAccess
TypeName PropertySummaryDocumentationMustOmitSetAccessorWithRestrictedAccess
CheckId SA1624
Przyczyna
Dokumentacja waciwoci opisuje oba akcesory (get i set), chocia jeden z nich ma ustalony
ograniczony dostp.
Opis reguy
zostanie zamana, jeli jeden z akcesoriw waciwoci ma limitowany dostp (zazwyczaj set), lecz
dokumentacja opisuje oba akcesory.
Jak skorygowa bd
Naley zaktualizowa dokumentacj waciwoci i usun zbdny opis akcesoria.
4.1.13 SA1625: ElementDocumentationMustNotBeCopiedAndPasted
TypeName ElementDocumentationMustNotBeCopiedAndPasted
CheckId SA1625
Przyczyna
Dokumentacja elementu zawiera dwa lub wicej identycznych wpisw sugerujc, e fragmenty
dokumentacji zostay skopiowane i wklejone. Moe to oznacza, e dokumentacja zostaa niedbale
przygotowana.
Opis reguy
zostanie zamana, jeli dwa lub wicej znacznikw dokumentacji zawiera t sam tre.
Jak skorygowa bd
Naley zaktualizowa dokumentacj upewniajc si, e wpisy w niej maj unikaln, wartociow tre.
4.1.14 SA1627: DocumentationTextMustNotBeEmpty

TypeName DocumentationTextMustNotBeEmpty
CheckId SA1627
Strona 18 z 38
Przyczyna
Dokumentacja elementu C# zawiera pusty znacznik.
Opis reguy
zostanie zamana, jeli jeden ze znacznikw dokumentacji jest pusty.
Jak skorygowa bd
Naley doda opis do pustych znacznikw dokumentacji.
4.1.15 SA1631: DocumentationMustMeetCharacterPercentage

TypeName DocumentationMustMeetCharacterPercentage
CheckId SA1631
Przyczyna
Dokumentacja elementu C# nie spenia wymagania dotyczcego dugoci treci.
Opis reguy
zostanie zamana, jeli cz dokumentacji nie zawiera wystarczajcej liczby znakw. Warto ta jest
obliczana przez porwnanie liczby liter w opisie i liczby pozostaych znakw. Zbyt niska stosunkowo
liczba liter moe oznacza, e dokumentacja jest zbyt trudna do przeczytania, np.:
/// <summary>
/// @)$(*A name--------
/// </summary>
public class Name
{
...
}
Jak skorygowa bd
Naley zaktualizowa dokumentacj elementu uywajc gramatycznie poprawnego jzyka i
upewniajc si, e liter jest wystarczajco duo w porwnaniu do innych znakw.
4.1.16 SA1643: DestructorSummaryDocumentationMustBeginWithStandardText
TypeName DestructorSummaryDocumentationMustBeginWithStandardText
CheckId SA1643
Przyczyna
Dokumentacja destruktora nie zawiera odpowiedniego tekstu.
Opis reguy
zostanie zamana, jeli opis destruktora nie bdzie zaczyna si od poprawnego tekstu. Zasada ta
wymaga, aby dokumentacje destruktorw miay ustandaryzowan form rozpoczynajc si od tekstu
Finalizes an instance of the {nazwa klasy} class..
/// <summary>
/// Finalizes an instance of the Customer class.
Strona 19 z 38
/// </summary>
~Customer()
{
}
Moliwe jest dodanie znacznika:
/// <summary>
/// Finalizes an instance of the <see cref="Customer"/> class.
/// </summary>
~Customer()
{
}
Jak skorygowa bd
Naley zaktualizowa opis destruktora w sposb opisany powyej.
4.1.17 SA1646: IncludedDocumentationXPathDoesNotExist
TypeName IncludedDocumentationXPathDoesNotExist
CheckId SA1646
Przyczyna
Dokumentacja elementu C# zawiera bdny odnonik.
Opis reguy
zostanie zamana, jeli dokumentacja zawiera bdny odnonik XPath.
Jak skorygowa bd
Naley zaktualizowa dokumentacj, upewniajc si, e wszystke odnoniki s poprawne.
4.1.18 SA1647: IncludeNodeDoesNotContainValidFileAndPath

TypeName IncludeNodeDoesNotContainValidFileAndPath
CheckId SA1647
Przyczyna
Tag <include> w dokumenacji nie zawiera prawidowych wartoci atrybutw file i path.
Opis reguy
zostanie zamana, jeli zacznik do dokumentacji bdzie zawiera bdne wartoci file lub path.
/// <include file="IncludedDocumentation.xml" path="root/EnabledMethodDocs"
/>
public bool Enabled(bool true)
{
}
Jak skorygowa bd
Naley skorygowa dane zacznika do dokumentacji.
Strona 20 z 38
4.1.19 SA1648: InheritDocMustBeUsedWithInheritingClass
TypeName InheritDocMustBeUsedWithInheritingClass
CheckId SA1648
Przyczyna
W dokumentacji zosta uyty znacznik <inheritdoc>, chocia element nie dziedziczy adnej klasy i nie
implementuje interfejsu.
Opis reguy
zostanie zamana, jeli zostanie uyty zbdny znacznik <inheritdoc>, gdy klasa nie dziedziczy klasy
bazowej ani nie implementuje interfejsu. Wyjtkiem s znaczniki, ktre zawieraj atrybut cref
wskazujcy na element, z ktrego jest dziedziczona dokumentacja.
Jak skorygowa bd
Naley usun zbdny znacznik <inheritdoc> z dokumentacji.
4.2 Reguy dotyczce utrzymania kodu

4.2.1 SA1400: AccessModifierMustBeDeclared
TypeName AccessModifierMustBeDeclared
CheckId SA1400
Category Maintainability Rules
Przyczyna
Modyfikator dostpu elementu nie zosta jawnie zdefiniowany.
Opis reguy
C# pozwala na definiowanie elementw bez modyfikatora dostpu. W takim przypadku poziom
dostpnoci zostanie okrelony automatycznie, zalenie od typu elementu.
Ta regua wymaga, aby modyfikator dostpu by jawnie zdefiniowany dla kadego elementu. Zwiksza
to czytelno kodu i uatwia jego analiz.
Jak skorygowa bd
eby naprawi naruszenie tej reguy, dodaj modyfikator dostpu do definicji elementu.
4.2.2 SA1401: FieldsMustBePrivate
TypeName FieldsMustBePrivate
CheckId SA1401
Przyczyna
Pole wewntrz klasy C# ma modyfikator dostpu inny ni prywatny.
Opis reguy
Regua ta jest zamana, jeli pole w klasie ma ustalony modyfikator dostpu inny ni prywatny. W celu
zwikszenia atwoci utrzymania kodu, wartoci pl powinny by udostpniane na zewntrz za
pomoc waciwoci, natomiast same pola powinny pozosta prywatne. Podejcie to pozwala na
zmian implementacji waciwoci klasy oraz jej pl bez zmiany jej interfejsu.
Pola w strukturach mog mie dowolny modyfikator dostpu.
Strona 21 z 38
Pola statyczne i tylko do odczytu nie wpywaj na zamanie tej reguy. Pola takie s powszechnie
uywanie do reprezentacji staych wartoci, kiedy sowo kluczowe const nie moe zosta uyte,
dlatego stanowi wyjtek od tej reguy.
Jak skorygowa bd
Naley doda do pola modyfikator dostpu private i, jeli to konieczne, udostpni warto pola za
pomoc waciwoci.
4.2.3 SA1402: FileMayOnlyContainASingleType
TypeName FileMayOnlyContainASingleType
CheckId SA1402
Przyczyna
Plik z kodem C# zawiera wicej ni jeden unikalny typ.
Opis reguy
Zasada ta zostaje zamana, kiedy plik zawiera wicej ni jeden typ. Dla zwikszenia moliwoci rozwoju
kodu, kady typ powinien by umieszczony w swoim pliku, a nazwy plikw powinny odwzorowywa
nazw tego typu.
Jest moliwe skonfigurowanie, jakie rodzaje typw powinny by obejmowane przez t regu.
Domylnie, delegaty, enumy, struktury oraz interfejsy mog by umieszczane razem z klas w jednym
pliku. Moliwe jest take umieszczenie czci partial tej samej klasy w jednym pliku.
Jak skorygowa bd
eby naprawi naruszenie tej reguy, naley przemieci kady typ do osobnego pliku.
4.2.4 SA1403: FileMayOnlyContainASingleNamespace
TypeName FileMayOnlyContainASingleNamespace
CheckId SA1403
Przyczyna
Plik z kodem C# zawiera wicej ni jedn przestrze nazw.
Opis reguy
Regua ta zostaje zamana, jeli plik zawiera wicej ni jedn przestrze nazw. Dla zwikszenia atwoci
utrzymania kodu w przyszoci, kady plik powinien zawiera najwyej jedn przestrze nazw.
Jak skorygowa bd
eby naprawi naruszenie tej reguy, naley upewni si, e w pliku znajduje si tylko jedna przestrze
nazw (namespace).
4.2.5 SA1404: CodeAnalysisSuppressionMustHaveJustification
TypeName CodeAnalysisSuppressionMustHaveJustification
CheckId SA1404
Przyczyna
Atrybut Code Analysis SuppressMessage nie zawiera usprawiedliwienia.
Opis reguy
Naruszenie reguy nastpuje, kiedy kod zawiera atrybut Code Analysis SuppressMessage, ale nie
zdefiniowano atrybutu usprawiedliwienia dla powstrzymania. Kiedy regua Code Analysis jest
Strona 22 z 38
pominita, usprawiedliwienie powinno by zdefiniowane. Pomoe to zwikszy dugofalow polityk
konserwacji kodu.
[SuppressMessage("Microsoft.Performance",
"CA1804:RemoveUnusedLocals", Justification = "Used during unit
testing")]
public bool Enable()
{
}
Jak skorygowa bd
eby naprawi naruszenie tej reguy, dodaj tag Justification i usprawiedliwiajcy tekst do trybutu
SuppressMessage opisujcego powd powstrzymania.
4.2.6 SA1405: DebugAssertMustProvideMessageText
TypeName DebugAssertMustProvideMessageText
CheckId SA1405
Przyczyna
Odwoanie do Debug.Assert w kodzie C# nie zawiera wiadomoci opisujc.
Opis reguy
Naruszanie reguy nastpuje, kiedy kod zawiera odwoanie do Debug.Assert, ktre nie zawiera opisu
dla uytkownika kocowego. Przykadowo ponisza asercja zawiera wiadomo opisujc.
Debug.Assert(value != true, "The value must always be true.");
Jak skorygowa bd
eby naprawi naruszenie reguy, dodaj wiadomo opisujc do asercji, ktra zostanie wywietlona
uytkownikowi kocowemu, kiedy asercja zostanie uruchomiona
4.2.7 SA1406: DebugFailMustProvideMessageText

TypeName DebugFailMustProvideMessageText
CheckId SA1406
Przyczyna
Odwoanie do Debug.Fail w kodzie C# nie zawiera wiadomoci opisujcej.
Opis reguy
Naruszenie reguy nastpuje, kiedy kod zawiera odwoanie do Debug.Fail, ktre nie zawiera opisu dla
uytkownika kocowego. Przykadowo ponisze odwoanie zawiera wiadomo opisujc:
Debug.Fail("The code should never reach this point.");
Jak skorygowa bd
eby naprawi naruszenie reguy, dodaj wiadomo opisujc do wywoania Debug.Fail, ktra
zostanie wywietlona uytkownikowi kocowemu, kiedy asercja zostanie uruchomiona.
4.2.8 SA1407: ArithmeticExpressionsMustDeclarePrecedence
TypeName ArithmeticExpressionsMustDeclarePrecedence
CheckId SA1407
Strona 23 z 38
Przyczyna
Deklaracja w C# zawiera zoone wyraenie arytmetyczne, ktre nie zawiera operatorw nawiasw.
Opis reguy
C# zachowuje hierarch procedur dla operacji arytmetycznych. W C# moliwe jest napisanie wielu
arytmetycznych operacji w jednym wyraeniu, bez oddzielania ich nawiasami. W tym przypadku
kompilator automatycznie przydzieli kolejno i pierwszestwo operacji opierajc si na wczeniej
ustalonych reguach. Przykadowo:
int x = 5 + y * b / 6 % z - 2;
Mimo e ten kod jest poprawny, nie jest bardzo czytelny I atwy w utrzymaniu. eby wpeni zrozumie
ten kod, programista musi zna I rozumie podstawowe reguy pierwszestwa operatorw w C#.
Ta regua jest stworzona eby zwikszy czytelno, atwo konserwacji tego typu kodu i zmiejszy
ryzyko wystapienia bdw w przyszoci, poprzez zmuszanie programistw do wstawiania nawiasw
w celu zaznaczenia kolejnoci pierwszestwa deklaracji operatorw. Przykadowo poniej
przedstawiono wiele operacji arytmetycznych otoczonych nawiasami:
int x = 5 + (y * ((b / 6) % z)) - 2;
Wstawianie nawiadw czyni kod bardziej oczywistym, atwym do zrozumienia i eliminuje potrzeb
przypuszczania przez czytajcego o co chodzi w kodzie.
Jak skorygowa bd
eby naprawi naruszenie reguy, umie nawiasy w wyraeniach arytmetycznych, eby zaznaczy
pierwszestwo operacji.
4.2.9 SA1408: ConditionalExpressionsMustDeclarePrecedence
TypeName ConditionalExpressionsMustDeclarePrecedence
CheckId SA1408
Przyczyna
Deklaracja w C# zawiera zoone wyraenie warunkowe, ktre nie zawiera operatorw nawiasw.
Opis reguy
C# zachowuje hierarchi procedur dla wyrae warunkowych. W C# moliwe jest napisanie wielu
operacji warunkowych razem w jednym wyraeniu, bez oddzielania ich nawiasami. W tym przypadku
kompilator automatycznie przydzieli kolejno i pierwszestwo operacji opierajc si na wczeniej
ustalonych reguach. Przykadowo:
if (x || y && z && a || b)
{
}
Mimo e ten kod jest poprawny, nie jest bardzo czytelny I atwy w utrzymaniu. eby wpeni zrozumie
ten kod, programista musi zna I rozumie podstawowe reguy pierwszestwa operatorw w C#.
Ta regua jest stworzona eby zwikszy czytelno, atwo konserwacji tego typu kodu i zmiejszy
ryzyko wystapienia bdw w przyszoci, poprzez zmuszanie programistw do wstawiania nawiasw
w celu zaznaczenia kolejnoci pierwszestwa deklaracji operatorw. Przykadowo programicsa mg
napisa kod:
if ((x || y) && z && (a || b))
{
}
Strona 24 z 38
lub
if (x || (y && z && a) || b)
{
}
Wstawianie nawiadw czyni kod bardziej oczywistym, atwym do zrozumienia i eliminuje potrzeb
przypuszczania przez czytajcego o co chodzi w kodzie.
Jak skorygowa bd
Wstaw nawiasy do wyrae warunkowych, eby zdefiniowa kolejno operacji.
4.2.10 SA1409: RemoveUnnecessaryCode
TypeName RemoveUnnecessaryCode
CheckId SA1409
Przyczyna
Plik C# zawiera kod ktry jest niepotrzebny i moe zosta usunity bez oglnej zmiany logiki kodu.
Opis reguy
Naruszenie tej reguy nastpuje, kiedy plik zawiera kod, ktry mone zosta usunity bez oglnej
zmiany logiki kodu.
Przykadowo poniszy blok try-catch moe zosta cakowicie usunity dopki jest pusty.
try
{
}
catch (Exception ex)
{
}
Ponisze wyraenie try-finally zawiera kod w bloku try, ale nie posiada bloku catch i blok finally jest
pusty. Zatem blok try-finally nie peni adnej uytecznej funkcji i moe by usunity.
try
{
this.Method();
}
finally
{
}
Jako kocowy przykad ponisze wyraenie unsafe jest puste, a zatem nie dostarczaj adnej wartoci.
unsafe
{
}
Jak skorygowa bd
eby naprawi naruszenie reguy, usu niepotrzebny kod lub dopisz do niego dodatkowe wyraenia.
4.2.11 SA1410: RemoveDelegateParenthesisWhenPossible
CheckId SA1409
Przyczyna
Wywoanie anonimowej metody nie zawiera parametrw, lecz instrukcja zawiera puste nawiasy.
Opis reguy
Strona 25 z 38
Jeli metoda anonimowa nie przyjmuje parametrw, uycie nawiasw jest zbdne:
this.Method(delegate() { return 2; });
Jak skorygowa bd
eby naprawi naruszenie reguy, usu zbdne nawiasy:
this.Method(delegate { return 2; });
4.2.12 SA1411: AttributeConstructorMustNotUseUnnecessaryParenthesis

CheckId SA1409
Przyczyna
Deklaracja atrybutu zawiera nawiasy, chocia nie ma adnych parametrw.
Opis reguy
Naruszenie tej reguy nastpuje, kiedy atrybut nie posiada parametrw, a mimo to umieszczone
zostay w jego deklaracji nawiasy, ktre s opcjonalne.
[Serializable()]
Jak skorygowa bd
Zbdne nawiasy naley usun:
[Serializable]
4.3 Reguy nazewnictwa
4.3.1 SA1300: ElementMustBeginWithUpperCaseLetter
TypeName ElementMustBeginWithUpperCaseLetter
CheckId SA1300
Category Naming Rules
Przyczyna
Nazwa elementu w jzyku C# nie zaczyna si wielk liter.
Opis reguy
Naruszenie tej reguy wystpuje, kiedy nazwa pewnego typu nie zaczyna si wielk liter. Nastpujce
typy elementw powinny zaczyna si wielk liter: przestrzenie nazw, klasy, typy wyliczeniowe,
struktury, delegaty, zdarzenia, metody i waciwoci.
Dodatkowo jakiekolwiek pole, ktre jest publiczne, wewntrzne lub z dodanym atrybutem const
powinno zaczyna si wielk liter. Nieprywatne pola suce tylko do odczytu, take musz zaczyna
si wielk liter.
Jeeli nazwa pola lub zmiennej jest specjalnie taka sama jak nazwa pozycji powizanej z Win32 lub
COM, a zatem istnieje potrzeba nazwania jest z maej litery, umie pole lub zmienn wewntrz
specjalnej klasy NativeMethods. NativeMethods to klasa o jakiejkolwiek nazwie, koczcej si
NativeMethods i stworzona, jako wrapper dla Win32 lub COM.
Jak skorygowa bd
eby naprawi naruszenie reguy, zmie nazw elementu, tak eby zaczynaa si wielk liter lub
umie element w klasie NativeMethods, jeeli jest to poprawne.
4.3.2 SA1301: ElementMustBeginWithLowerCaseLetter
TypeName ElementMustBeginWithLowerCaseLetter
Strona 26 z 38
CheckId SA1301
Przyczyna
Aktualnie nie ma sytuacji w ktrej regua wystpuje.
4.3.3 SA1302: InterfaceNamesMustBeginWithI
TypeName InterfaceNamesMustBeginWithI
CheckId SA1302
Przyczyna
Nazwa interfejsu w C# nie zaczyna si gwn liter I.
Opis reguy
Naruszenie tej reguy wystpuje, kiedy nazwa interfejsu nie zaczyna si gwn liter I. Nazwy
interfejsw zawsze powinny zaczyna si od I. Przykadowo ICustomer.
COM, a zatem nie moe zaczyna si liter I, umie pole lub zmienn wewntrz specjalnej klasy
NativeMethods. NativeMethods to klasa o jakiejkolwiek nazwie, koczcej si NativeMethods i
stworzona, jako wrapper dla Win32 lub COM. StyleCop bdzie ignorowa naruszenie tej reguy, jeeli
pozycja bdzie znajdowaa si w klasie NativeMethods.
Jak skorygowa bd
eby naprawi naruszenie reguy, dodaj gwn liter I na pocztku nazwy interfejsu lub umie
element w klasie NativeMethods, jeeli jest to poprawne.
4.3.4 SA1303: ConstFieldNamesMustBeginWithUpperCaseLetter
TypeName ConstFieldNamesMustBeginWithUpperCaseLetter
CheckId SA1303
Przyczyna
Nazwa staego pola w C# musi zaczyna si wielk liter.
Opis reguy
Naruszenie tej reguy nastpuje, kiedy nazwa pola oznaczonego, jako stae nie zaczyna si wielk
liter.
NativeMethods i stworzona, jako wrapper dla Win32 lub COM.
Jak skorygowa bd
eby naprawi naruszenie reguy, zmie nazw pola, ktre jest stae tak, eby zaczynaa si wielk
liter lub umie element w klasie NativeMethods jeeli jest to poprawne.
4.3.5 SA1304: NonPrivateReadonlyFieldsMustBeginWithUpperCaseLetter
TypeName NonPrivateReadonlyFieldsMustBeginWithUpperCaseLetter
CheckId SA1304
Strona 27 z 38
Przyczyna
Nazwa nieprywatnego pola w C#, ktre jest tylko do odczytu musi zaczyna si wielk liter.
Opis reguy
Naruszenie tej reguy nastpuje, kiedy nazwa pola tylko do odczytu, ktre nie jest prywatne nie
zaczyna si wielk liter. Nieprywatne pola, ktre s tylko do odczytu musz zawsze zaczyna si
wielk liter.
NativeMethods i stworzona, jako wrapper dla Win32 lub COM. StyleCop bdzie ignorowa naruszenie
tej reguy, jeeli pozycja bdzie znajdowaa si w klasie NativeMethods.
Jak skorygowa bd
eby naprawi naruszenie reguy zmie nazw pola tylko do odczytu tak eby zaczynaa si wielk
liter, zmie pole na prywatne lub umie je w klasie NativeMethods, jeli jest to poprawne.
4.3.6 SA1305: FieldNamesMustNotUseHungarianNotation
TypeName FieldNamesMustNotUseHungarianNotation
CheckId SA1305
Przyczyna
Nazwa pola lub zmiennej w C# uywa notacji Wgierskiej.
Opis reguy
Naruszenie tej reguy nastpuje, kiedy uywana jest notacja Wgierska do nazywania pl lub
zmiennych. Uycie Wgierskiej notacji stao si powszechne w kodzie C++, ale ta tendencja nie jest ju
uywana w C#, bardziej opisowe nazwy zmiennych, ktre nie s oparte na ich typie, ale ktre opisuj,
do czego zmienna jest uywana.
Dodatkowo nowoczesne edytory kodu takie jak Visual Studio uatwiaj identyfikacje typu zmiennej lub
pola, zazwyczaj poprze przesunicie kursora myszy nad nazw zmiennej. Zmniejsza to potrzeb
uycia notacji Wgierskiej.
StyleCop zakada, e jakakolwiek nazwa zmiennej zaczynajca si jednym lub dwoma maymi znakami
uywa notacji Wgierskiej, co spowoduje zamanie tej reguy w kadym przypadku. Jest moliwe
zadeklarowanie kilku prefiksw, jako poprawnych, w tych przypadkach bd one ignorowane.
Przykadowo zmienna nazwa onExecute spowoduje zamanie reguy uywania notacji Wgierskiej,
kiedy naprawd nie wystpuje. Zatem prefiks on powinien by oznaczony, jako dozwolony.
eby skonfigurowa list dozwolonych prefiksw, uruchom ustawienia StyleCop dla projektu, przejd
do zakadki Hungarian jak pokazano poniej:
Strona 28 z 38
Dodanie jedno lub dwuliterowego prefiksu do listy spowoduje ignorowanie nazw zmiennych lub pl
zaczynajcych si od tego prefiksu.
COM, a zatem potrzebne jest uycie notacji Wgierskiej, umie pole lub zmienn wewntrz
Jak skorygowa bd
eby naprawi naruszenie reguy, usu notacje Wgiersk z nazw pl lub zmiennych, albo umie je w
klasie NativeMethods, jeli jest to poprawne.
4.3.7 SA1306: FieldNamesMustBeginWithLowerCaseLetter
TypeName FieldNamesMustBeginWithLowerCaseLetter
CheckId SA1306
Przyczyna
Nazwa pola lub zmiennej w kodzie C# nie zaczyna si ma liter.
Opis reguy
Naruszenie tej reguy nastpuje, kiedy nazwa pola lub zmiennej zaczyna si wielk liter. Stae musz
zawsze zaczyna si wielk liter, podczas gdy pola tylko do odczytu mog zaczyna si zarwno
wielk jak i ma liter. Take publiczne lub wewntrzne pola musz zawsze zaczyna si wielk liter.
COM, a zatem potrzebne jest uycie wielkiej litery na pocztku, umie pole lub zmienn wewntrz
Jak skorygowa bd
Strona 29 z 38
eby naprawi naruszenie tej reguy, zmie nazw pola lub zmiennej tak eby zaczynao si ma liter
lub umie je w klasie NativeMethods, jeli jest to poprawne.
4.3.8 SA1307: AccessibleFieldsMustBeginWithUpperCaseLetter
TypeName AccessibleFieldsMustBeginWithUpperCaseLetter
CheckId SA1307
Przyczyna
Nazwa publicznego lub wewntrznego pola w C# nie zaczyna si wielk liter.
Opis reguy
Naruszenie tej reguy nastpuje, kiedy nazwa publicznego lub wewntrznego pola zaczyna si ma
liter. Publiczne lub wewntrzne pola musz zaczyna si wielk liter.
COM, a zatem potrzebne jest uycie malej litery na pocztku, umie pole lub zmienn wewntrz
Jak skorygowa bd
eby naprawi naruszenie tej reguy, zmie nazw pola tak, eby zaczynaa si z wielkiej litery lub
umie pole w klasie NativeMethods, jeli jest to poprawne.
4.3.9 SA1308: VariableNamesMustNotBePrefixed
TypeName VariableNamesMustNotBePrefixed
CheckId SA1308
Przyczyna
Nazwa pola w C# zaczyna si prefiksem m_ lub s_.
Opis reguy
Naruszenie tej reguy nastpuje, kiedy nazwa pola zaczyna si prefiksem m_ lub s_.
Domylnie StyleCop uniemoliwia uycie podkrele, m_ itd. do zaznaczenia lokalnych pl, na rzecz
prefiksu this.. Korzyci pync z uywania this. jest to, e dotyczy ona na rwni wszystkich typw
elementw wczajc metody, waciwoci itd. Oraz nie tylko odwoania do pl skadowych klasy czyni
natychmiastowo rozpoznawalnymi, bez wzgldu, ktry edytor jest uywany do wywietlania kodu.
Kolejn korzyci jest tworzenie szybkich, rozpoznawalnych rnic pomidzy instancja skadow, a
statyczn, ktra nie jest poprzedzona prefiksem.
COM, a zatem potrzebny jest prefiks na pocztku, umie pole lub zmienn wewntrz specjalnej klasy
Jak skorygowa bd
eby naprawi naruszenie tej reguy, usu prefiks z pocztku nazwy pola lub umie lub w klasie
NativeMethods, jeli jest to poprawne.
4.3.10 SA1310: FieldNamesMustNotContainUnderscore
TypeName FieldNamesMustNotContainUnderscore
Strona 30 z 38
CheckId SA1310
Przyczyna
Nazwa pola w C# zawiera podkrelenie.
Opis reguy
Naruszenie tej reguy nastpuje, kiedy nazwa pola zawiera podkrelenie. Pola i zmienne powinny by
nazywane uywajc opisowych, czytelnych sw, ktre opisuj ich funkcj. Zazwyczaj takie nazwy
bd pisane z uyciem camel case i nie powinny uywa podkrelenia. Przykadowo uyj
customerPostCode zamiast customer_post_code.
COM, a zatem potrzebne jest uycie podkrelenia, umie pole lub zmienn wewntrz specjalnej klasy
Jak skorygowa bd
eby naprawi naruszenie tej reguy, usu podkrelenie z nazwy pola lub umie pole w klasie
NativeMethods, jeli jest to poprawne.
4.3.11 SA1311: StaticReadonlyFieldsMustBeginWithUpperCaseLetter
TypeName StaticReadonlyFieldsMustBeginWithUpperCaseLetter
CheckId SA1311
Przyczyna
Nazwa statycznego pola tylko do odczytu nie zaczyna si od wielkiej litery.
Opis reguy
Zamanie reguy wystpuje, jeli nazwa pola static readonly zaczyna si z maej litery.
Jak skorygowa bd
Zmiana nazwa pola na tak, ktra bdzie zaczyna si od wielkiej litery.
4.4 Reguy dotyczce porzdku
4.4.1 SA1216: UsingStaticDirectivesMustBePlacedAtTheCorrectLocation
TypeName UsingStaticDirectivesMustBePlacedAtTheCorrectLocation
CheckId SA1216
Category Order Rules
Przyczyna
Dyrektywa using static zostaa umieszczona w zej lokacji (przed standardow dyrektyw using albo za
aliasem dyrektywy.
Opis reguy
Zamanie reguy wystpuje, jeli dyrektywa using static znajduje si przed normalnym uyciem using
lub za dyrektyw z aliasem. Umieszczenie ich w odpowiednim miejscu (za normalnymi dyrektywami
using i przed aliasami using) pozwala zachowa przejrzysto kodu i atwe zidentifykowanie, ktre
dyrektywy using s statyczne.
Strona 31 z 38
Jak skorygowa bd
Umieszczenie dyrektyw using static za standardowymi dyrektywami using, a przed dyrektywami using
z aliasem.
4.5 Reguy dotyczce czytelnoci
4.5.1 SA1100: DoNotPrefixCallsWithBaseUnlessLocalImplementationExists
TypeName DoNotPrefixCallsWithBaseUnlessLocalImplementationExists
CheckId SA1100
Category Readability Rules
Przyczyna
Uycie elementu z klasy bazowej zaczyna si od base., ale klasa lokalna nie zawiera nadpisania tego
elementu.
Opis reguy
Zamanie reguy wystpuje, jeli odwoanie do elementu klasy bazowej ma prefiks base., lecz nie ma
lokalnej implementacji tego elementu. Regua ta zapobiega potencjalnym bugom, gdyby w przyszoci
zostaa dodana implementacja override.
Jak skorygowa bd
Usunicie lub zmiana prefiksu base. na this..
4.5.2 SA1102: QueryClauseShouldFollowPreviousClause
TypeName QueryClauseShouldFollowPreviousClause
CheckId SA1102
Przyczyna
Paragraf zapytania C# nie zaczyna si ani w tej samej linii co poprzedni paragraf, ani w nastpnej linii.
Opis reguy
Zamanie reguy wystpuje, jeli paragraf zapytania nie zaczyna si w tej samej linii co poprzedni lub
za nim w nastpnej linii, np.:
object x = select a in b
from c;
Jak skorygowa bd
Przesunicie paragrafu tak, aby znajdowa si w tej samej linii co poprzedni lub w wierszu niej.
4.5.3 SA1103: QueryClausesShouldBeOnSeparateLinesOrAllOnOneLine
TypeName QueryClausesShouldBeOnSeparateLinesOrAllOnOneLine
CheckId SA1103
Przyczyna
Czci zapytania C# ani nie s umieszczone w jednej linii, ani kada z nich nie jest umieszczona w
osobnej linii.
Opis reguy
Zamanie reguy wystpuje, jeli paragrafy zapytania nie s umieszczone w jednym wierszu, ale te
kady z nich nie jest umieszczony w osobnym wierszu.
Jak skorygowa bd
Strona 32 z 38
Zreorganizowanie zapytania tak, aby zajmowao jedn lini lub aby kada cz zapytania znajdowaa
si w osobnym wierszu.
4.5.4 SA1104: QueryClauseShouldBeginOnNewLineWhenPreviousClauseSpansMultipleLines
TypeName QueryClauseShouldBeginOnNewLineWhenPreviousClauseSpansMultipleLines
CheckId SA1104
Przyczyna
Cz zapytania C# zaczyna si w tej samej linii, co poprzednia, podczas gdy poprzednia rozciga si na
wiele linii.
Opis reguy
Zamanie reguy wystpuje, jeli paragraf zapytania nie s umieszczone w jednym wierszu, a nastpny
nie zaczyna si w nowym wierszu, np.:
var elementNames =
from element in GetElements
(
12,
45
) select element.Name;
Jak skorygowa bd
Przenie cz zapytania do nowego wiersza.
4.5.5 SA1105: QueryClausesSpanningMultipleLinesShouldBeginOnOwnLine
TypeName QueryClausesSpanningMultipleLinesShouldBeginOnOwnLine
CheckId SA1105
Przyczyna
Paragraf wewntrz zapytania rozciga si na wiele linii i nie zaczyna si w nowej linii.
Opis reguy
Zamanie reguy wystpuje, jeli paragraf zapytania zajmuje wiele linii, ale nie zaczyna si we wasnym
wierszu. Na przykad:
var elementDescriptions =
from element in elements select GenerateElementDescription
(
element
);
Poprawny zapis:
var elementDescriptions =
from element in elements
select GenerateElementDescription
(
element
);
Jak skorygowa bd
Przesunicie paragrafu niej, aby rozpoczynao si od nowej linii.
4.5.6 SA1106: CodeMustNotContainEmptyStatements
TypeName CodeMustNotContainEmptyStatements
CheckId SA1106
Strona 33 z 38
Przyczyna
Instrukcja w kodzie jest pusta.
Opis reguy
Zamanie reguy wystpuje, jeli w kodzie wystpuje pusta instrukcje, tj. zbdny rednik.
Jak skorygowa bd
Usun rednik zamykajcy pust instrukcj.
4.5.7 SA1107: CodeMustNotContainMultipleStatementsOnOneLine
TypeName CodeMustNotContainMultipleStatementsOnOneLine
CheckId SA1107
Przyczyna
Wiersz w kodzie zawiera wicej ni jedn instrukcj.
Opis reguy
Zamanie reguy wystpuje, jeli linia kodu zawiera wicej ni jedn instrukcj.
Jak skorygowa bd
Przenie instrukcje do odrbnych wierszy.
4.5.8 SA1108: BlockStatementsMustNotContainEmbeddedComments
TypeName BlockStatementsMustNotContainEmbeddedComments
CheckId SA1108
Przyczyna
Instrukcja zawiera komentarz pomidzy deklaracj a otwierajc klamr.
Opis reguy
Zamanie reguy wystpuje, jeli w kodzie wystpuje komentarz pomidzy deklaracj instrukcji a
klamr otwierajc jej ciao, np.:
if (x != y)
// Make sure x does not equal y
{
}
Jak skorygowa bd
Przenie komentarz nad instrukcj lub do jej ciaa (wewntrz klamr).
4.5.9 SA1109: BlockStatementsMustNotContainEmbeddedRegions
TypeName BlockStatementsMustNotContainEmbeddedRegions
CheckId SA1109
Przyczyna
Instrukcja zawiera tag regionu pomidzy deklaracj instrukcji a klamr otwierajc jej ciao.
Opis reguy
Strona 34 z 38
Zamanie reguy wystpuje, jeli tag regionu zosta umieszczony midzy deklaracj instrukcji a jej
ciaem, np.:
if (x != y)
#region
{
}
#endregion
Jak skorygowa bd
Przenie tag regionu na zewntrz instrukcji.
4.5.10 SA1112: ClosingParenthesisMustBeOnLineOfOpeningParenthesis
TypeName ClosingParenthesisMustBeOnLineOfOpeningParenthesis
CheckId SA1112
Przyczyna
Nawias lub klamra zamykajca w wywoaniu lub deklaracji metody lub ideksera nie znajduje si w tej
samej linii co otwierajcy nawias lub klamra, podczas gdy element nie przyjmuje parametrw.
Opis reguy
Zamanie reguy wystpuje, jeli element nie przyjmuje parametrw, a mimo to nawiasy uyte w jego
deklaracji lub wywoaniu zostay umieszczone w osobnych wierszach.
Jak skorygowa bd
Przenie nawiasy zamykajce do tych samych wierszy, co otwierajce.
4.5.11 SA1113: CommaMustBeOnSameLineAsPreviousParameter
TypeName CommaMustBeOnSameLineAsPreviousParameter
CheckId SA1113
Przyczyna
Przecinek rozdzielajcy parametry nie znajduje si w tej samej linii, co poprzedzajcy go parametr.
Opis reguy
Zamanie reguy wystpuje, jeli przecinek oddzielajcy parametry przeniesiony jest do innej linii, ni
poprzedzajcy go parametr.
Jak skorygowa bd
Przenie przecinek do tego samego wiersza, co poprzedzajcy go parametr.
4.5.12 SA1114: ParameterListMustFollowDeclaration
TypeName ParameterListMustFollowDeclaration
CheckId SA1114
Przyczyna
Lista parametrw nie rozpoczyna si w tej samej linii co otwierajcy j nawias lub bezporednio
nastpnej linii.
Opis reguy
Zamanie reguy wystpuje, jeli lista parametrw nie zaczyna si w tej samej lub bezporednio
kolejnej linii co nawias otwierajcy:
public string JoinName(
Strona 35 z 38
string first, string last)
{
}
Jak skorygowa bd
Zreorganizowa zapis tak, aby lista parametrw zaczynaa si w tej samej lub kolejnej linii co nawias
otwierajcy.
4.5.13 SA1120: CommentsMustContainText
TypeName CommentsMustContainText
CheckId SA1120
Przyczyna
Komentarz nie zawiera treci.
Opis reguy
Zamanie reguy wystpuje, jeli komentarz nie zawiera tekstu.
Jak skorygowa bd
Usun lub uzupeni komentarz.
4.5.14 SA1125: UseShorthandForNullableTypes
TypeName UseShorthandForNullableTypes
CheckId SA1125
Przyczyna
Typ Nullable nie zosta zadeklarowany w skrcony sposb (uywajc znaku ?).
Opis reguy
Zamanie reguy wystpuje, jeli typ Nullable nie zosta zdefiniowany w skrcony sposb. Np.
Nullable<DateTime> zamiast DateTime?.
Jak skorygowa bd
Uy skrconego zapisu typu Nullable.
4.5.15 SA1131: UseReadableConditions
TypeName UseReadableConditions
CheckId SA1131
Przyczyna
W porwnaniu zmiennej i dosownej lub staej wartoci, zmienna zostaa umieszczona po prawej
stronie wyraenia.
Opis reguy
Zamanie reguy wystpuje, jeli w wyraeniu porwnujcym zmienn i sta warto, zmienna zostaa
umieszczona po prawej stronie. Jako dosown lub sta warto rozumiemy wartoci liczbowe,
tekstowe, null, wartoci domylne (default(T)), referencje do wartoci static readonly, dowolne
wyraenie, ktrego wynikiem jest staa warto w czasie kompilacji.
Jak skorygowa bd
Zmieni kolejno porwnywanych elementw.
Strona 36 z 38
4.6 Reguy odstpw
4.6.1 SA1029: DoNotSplitNullConditionalOperators
TypeName DoNotSplitNullConditionalOperators
CheckId SA1029
Category Spacing Rules
Przyczyna
Operator warunku wartoci null (?. lub ?[) zosta odseparowany now lini, spacj lub komentarzem.
Opis reguy
Jak skorygowa bd
Naley usun zbdne znaki rozdzialajce operator warunkowy wartoci null.
Strona 37 z 38

Zasady Nazewnictwa

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Zasady Nazewnictwa

Uploaded by

Copyright:

Available Formats

1 Wstp .............................................................................................................................................................

Uyte w konwencji zwroty maj nastpujce znaczenie:

3.1 Konwencje wielkoci liter

3.1.1 Zasady wielkoci liter dla identyfikatorw

Typ Pascal public class StreamReader { ... }

Metoda Pascal public class Object

Callback callback CallBack

Canceled canceled Cancelled

DoNot doNot Don't

Endpoint endpoint EndPoint

FileName fileName Filename

Gridline gridline GridLine

Hashtable hashtable HashTable

Indexes indexes Indices

LogOff logOff LogOut

LogOn logOn LogIn

Metadata metadata MetaData,

Multiview multiview MultiView

Namespace namespace NameSpace

Placeholder placeholder PlaceHolder

SignIn signIn SignOn

SignOut signOut SignOff

UserName userName Username

WhiteSpace whiteSpace Whitespace

Writable writable Writeable

3.1.3 Wielko liter

3.2 Oglne zasady nazewnictwa

3.2.2 Uywanie skrtw i akronimw

3.2.3 Uywanie nazw specyficznych dla jzyka

Poniej tabela typw i ich mapowania na odpowiednie typy CLR:

C# Visual Basic C++ CLR

sbyte SByte char SByte

byte Byte unsigned char Byte

short Short short Int16

ushort UInt16 unsigned short UInt16

int Integer int Int32

uint UInt32 unsigned int UInt32

long Long __int64 Int64

ulong UInt64 unsigned __int64 UInt64

float Single float Single

double Double double Double

bool Boolean bool Boolean

char Char wchar_t Char

object Object Object Object

3.2.4 Nazywanie nowych wersji istniejcych API

3.3 Nazwy komponentw

3.4 Nazwy przestrzeni nazw

3.4.1 Przestrzenie nazw i konflikty nazw

3.5 Nazwy klas, struktur i interfejsw

Wytyczne nazewnictwa, ktre moesz powszechnie stosowa do nazywania typw.

3.6 Nazwy parametrw typw szablonowych

public int IComparer<T> { ... }

Uywaj prefiksu opisujcego typ parametru nazywanego z T.

public interface ISessionChannel<TSession> where TSession : ISession

Podstawowy Typ Wytyczne typw poczodnych/implementujcych

Dodawaj sufiks Attribute do nazw niestandardowych klas atrybutu.

3.9 Nazywanie typw skadowych

public class String {

3.10 Nazewnictwo parametrw

3.10.1 Nazewnictwo parametrw przeadowany

3.11 Nazewnictwo zasobw

4.1.3 SA1613: ElementParameterDocumentationMustDeclareParameterName

4.1.4 SA1614: ElementParameterDocumentationMustHaveText