Coding standards - casing and naming conventions

by Joyclyn Vincent

10 April 2024

Last updated 13 November 2024

official Standards

official Standards

Extracted from CM ref 11/59572

Definitions

For the purposes of this standard, the following definitions apply:

Term	Definition	Coding Example
Adjective	A word that describes a noun (e.g. big, wet, blue).	Last, First
Noun	A word that refers to a thing, person, place, or idea (e.g. book, student, Brisbane, education).	Role, List, Name
Noun Phrase	A phrase that defines or describes a noun (e.g. that book, student name).	userRole, roleList, LastName
Prefix	One or more characters added to the beginning of a word, typically to denote something in common (e.g. multi (many): multicultural, multilingual).	defaultType, defaultYear
Suffix	One or more characters added to the end of a word, typically to denote something in common (e.g. less (lack of): homeless, useless).	ErrorResource, TextResource
Verb	A word that refers to an action, event, or state of being (e.g. run, get, new).	Get, Refresh, Exception
Verb Phrase	A phrase that defines the object of the verb (e.g. run fast, new student).	GetDescription, RefreshCache

Disclaimer

The names ‘Microsoft’, ‘.NET’, and the names of other Microsoft products referenced herein, are trademarks or registered trademarks of Microsoft Corporation.

Naming conventions and standards

Spelling and preferred terms

Relates to Microsoft Code Analysis Rules: CA1703, CA1704, CA1726

Microsoft Code Analysis will raise an error for identifier names that are not recognised by the Microsoft Spelling Checker. Ensure that any words where spelling that may not be recognised by the Microsoft Spelling Checker are included in the project’s custom dictionary (see Appendix A. Creating and using custom dictionaries.

Microsoft Code Analysis will also raise an error where an ‘obsolete’ term is used, instead of the Microsoft-preferred term.

Obsolete terms and their preferred alternatives are:

Obsolete Term	Preferred Term
Arent	AreNot
Cancelled	Canceled
Cant	Cannot
ComPlus	EnterpriseServices
Couldn’t	CouldNot
Didn’t	DidNot
Doesn’t	DoesNot
Don’t	DoNot
Hadnt	HadNot
Hasn’t	HasNot
Havent	HaveNot
Indices	Indexes
Isnt	IsNot
LogIn	LogOn
LogOut	LogOff
Shouldn’t	ShouldNot
SignOn	SignIn
SignOff	SignOut
Wasn’t	WasNot
Werent	WereNot
Wont	WillNot
Wouldn’t	WouldNot
Writeable	Writable

Casing and notation

The following casing and notation terms are used throughout this standard:

Casing	Description	Example
Pascal	First character of each word is upper-case.	ColourBitConverter
Camel	First character of each word is upper-case, except the first word.	purchaseOrderId
Uppercase	All characters are upper-case.	SYSTEM_CODE

Notation	Description	Example
Hungarian	Name of a variable or function indicates its type or intended use.	strName, m_sName

Case insensitive language

Relates to Microsoft Code Analysis Rule: CA1708 Relates to Microsoft Naming Guidelines: Case Sensitivity

To avoid confusion and ensure cross-language interoperation, do not use identifier names that require case-sensitivity (e.g. void MyFunction(string a, string A) ).

Casing rules for all uppercase

Relates to Microsoft Code Analysis Rule: CA1709

Only use all uppercase letters for an identifier if it is defined as a Constant.
For example: SYSTEM_CODE.

Casing rules for compound words

Relates to Microsoft Code Analysis Rules: CA1701, CA1702, CA1709

Do not capitalise each word in closed-form compound words - that is, compound words written as a single word, such as endpoint or hashtable.

For example, hashtable is a closed-form compound word that should be treated as a single word and cased accordingly. In pascal case, it is Hashtable - in camel case, it is hashtable.

Other examples of compound words that will cause violations are CheckSum and MultiPart, which should be written as Checksum/checksum and Multipart/multipart.

To determine whether a word is a closed-form compound word, check the Macquarie Dictionary.

The following table identifies some common terms that are not closed-form compound words:

PascalCase	camelCase
BitFlag	bitFlag
FileName	fileName
LogOff	logOff
LogOn	logOn
SignIn	signIn
SignOut	signOut
UserName	userName
WhiteSpace	whiteSpace

Casing rules for acronyms and initialisms

Relates to Microsoft Code Analysis Rule: CA1709

Relates to Microsoft Naming Guidelines: Abbreviations

Where:

• Acronym: Term based on the first letter of each word, and pronounced as a single word

  (e.g. Technical and Further Education: TAFE).

• Initialism: Term based on the first letter of each word, and pronounced as a series of letters

  (e.g. Australian Broadcasting Corporation: ABC).

Casing of acronyms depends on the length of the acronym. All acronyms are at least two characters long. For the purposes of these coding standards, if an acronym is exactly two characters, it is considered a short acronym. An acronym of three or more characters is a long acronym.

The following rules specify the proper casing for short and long acronyms.

Note that the identifier casing rules take precedence over acronym casing rules.

Rule	Do
2 char.	Capitalise both characters, except the first word of a camel-cased identifier. For example: A property named DBRate is an example of a short acronym (DB) used as the first word of a pascal-cased identifier. A parameter named ioChannel is an example of a short acronym (IO) used as the first word of a camel-cased identifier.
3+ char.	Use PascalCase or camelCase, as appropriate (see section 3.2.5, casing rules for identifiers). For example: A class named XmlWriter is an example of a long acronym used as the first word of a pascal-cased identifier. A parameter named htmlReader is an example of a long acronym used as the first word of a camel-cased identifier.

Commonly-used acronyms and initialisms include:

Full Term	PascalCase	camelCase
Database	DB	db
Common Language Runtime	Clr	clr
Hypertext Markup Language	Html	html
Uniform Resource Locator	Url	url
File Transfer Protocol	Ftp	ftp
Input/Output	IO	io
User Interface	UI	ui
Component Object Model	Com	com
Application Program Interface	Api	api

Casing rules for identifiers

Relates to Microsoft Code Analysis Rules: CA1707, CA1709

Relates to Microsoft Naming Guidelines: Capitalisation Styles

Use pascal casing (PascalCase) for all public member, type, and namespace names consisting of multiple words. Note that this rule does not apply to instance fields; you should not use public instance fields.

General casing rules for identifiers:

Identifier	Case	Example
Class	PascalCase	PurchaseOrder	See page 13
Constant	UPPERCASE	DEFAULT_CACHE_EXPIRY_MINUTES	See page 18
Delegate	PascalCase	RefreshCacheCallback	See page 20
Enumeration type	PascalCase	LookupSource	See page 19
Enumeration value	PascalCase	LookupType, StoredProcedure	See page 19
Event	PascalCase	OnClick	See page 20
Exception	PascalCase	DatabaseException	See page 18
Interface	PascalCase	BusinessObject [1]	See page 17
Local variable	camelCase	firstName	See page 21
Member variable	camelCase	_firstName [2]	See page 21
Method	PascalCase	ListAll()	See page 15
Namespace	PascalCase	OneFramework.Web, System.Data.Common	See page 12
Parameter	camelCase	pageIndex	See page 16
Property	PascalCase	LastName	See page 14
Public Instance Field	PascalCase	RedValue
Read Only Static Field	PascalCase	RedValue	See page 20
Resource	PascalCase	ConfigurationErrorText.resx	See page 22

^{[1] Use the prefix ‘I’ (uppercase i) for interfaces.}

^{[2] Use the prefix ‘_’ for member variables.}

Note that constants and member variables are the only identifiers that should include underscores.

Naming standards

General naming standards

Relates to Microsoft Code Analysis Rules: CA1707, CA1716, CA1720, CA1722, CA1724

Relates to Microsoft Naming Guidelines: Word Choice, Avoiding Type Name Confusion

Rule	Do
1.	Keep names to a maximum of 33 characters.
2.	Name objects and methods as descriptively as possible, and choose easily readable identifier names. Keep names simple, but favour readability over brevity. For example, a property named CanScrollHorizontally is more easily understood than ScrollableX
3.	Use plurals when naming lists, collections, arrays, etc.
4.	Use literal English names rather than language-specific keywords for type names. For example, GetLength is more easily understood than GetInt

Rule	Do not
5.	Don’t use class names duplicated in heavily used namespaces. For example, don’t use the following for class names: System, Collections, Forms, UI.
6.	Don’t use identifiers that conflict with keywords of widely-used programming languages, or .NET Framework Namespace names. This exclusion includes the use of data types and common database suffixes (e.g. fg, cd, dt) in property names. See Appendix B. NET Framework Namespaces, and Appendix C. Common programming keywords.
7.	Don’t use non-alphanumeric characters in names.
8.	With the exception of constants and member variables, don’t use underscores in names. This exclusion includes the use of separators between words, when an identifier consists of multiple words. [3]
9.	Don’t use hungarian-type prefixes in identifiers.
10.	Don’t add words that provide no value to property names (e.g. Employee.EmployeeName is better formed as: Employee.Name).

^{[3] Use the appropriate casing to indicate the beginning of each word.}

Using abbreviations, acronyms, initialisms, and contractions

Relates to Microsoft Naming Guidelines: Abbreviations

Where:

• Abbreviation: Shortened form of a word or phrase (e.g. Laboratory: Lab).
• Acronym: Term based on the first letter of each word, and pronounced as a single word (e.g. Technical and Further Education: TAFE).
• Initialism: Term based on the first letter of each word, and pronounced as a series of letters (e.g. Australian Broadcasting Corporation: ABC).
• Contraction: Abbreviation that includes the first and last letters of a word (e.g. Limited: Ltd).

General use:

Rule	Acceptable
1.	Abbreviations can be used when the abbreviation is so common that people outside our industry will readily identify the meaning (e.g. Client.ID is acceptable in lieu of Client.Identifier or Client.Identity).
2.	The abbreviations ID and OK can be used in identifiers. In pascal-cased identifiers they should appear as Id and Ok. If used as the first word in a camel-cased identifier, they should appear as id and ok.

Rule	Do not
3.	Wherever possible, do not use abbreviations or acronyms/initialisms.
4.	Don’t use acronyms/initialisms that are not widely-recognised, and then only when necessary.
5.	Don’t use abbreviations or contractions as parts of identifier names. For example, use OnButtonClick rather than OnBtnClick.

Naming namespaces

Relates to Microsoft Naming Guidelines: Namespace Naming

Rule	Acceptable
1.	Follow the standard pattern, as appropriate, when naming namespaces: <CompanyName>.<ApplicationName \| Technology>.<Top Level Module>.<Bottom Level Module>... For example: DET.ApplicationName.BusinessLogic, OneFramework.Web.Forms.
2.	Separate logical components with full stops.
3.	Prefix namespaces with a meaningful identifier representing the scope of work (e.g. OneFramework, OneFramework.Web). There should be a clear relationship between the namespace and the folder structure in the solution.
4.	Use plural namespace names where appropriate (e.g. use System.Collections rather than System.Collection). Exceptions to this rule are brand names and abbreviations (e.g. use System.IO rather than System.IOs).

Rule	Do not
5.	Do not have namespaces and classes with the same name.

Naming classes

Relates to Microsoft Code Analysis Rules: CA1710, CA1722

Relates to Microsoft Naming Guidelines: Class Naming, Attribute Naming

Rule	Do
1.	Name classes with nouns or noun phrases.
2.	Use abbreviations sparingly in class names.
3.	Use the prefix Base for a base class where inheritance is expected.
4.	Use the suffix DA for data access classes.
5.	Use the suffix Collection for collection classes, that is, those classes that implement: - System.Collections.IEnumerable - System.Collections.ICollection - System.Collections.IList - System.Collections.Generic.IEnumerable - System.Collections.Generic.ICollection or - System.Collections.Generic.IList
6.	Use the suffix Attribute for custom attribute classes. For example: ObsoleteAttribute and AttributeUsageAttribute.
7.	When defining a class/interface pair where the class is a standard implementation of the interface, ensure the names differ only by prefixing the letter I (upper-case i) in the interface name. For example, OneFramework provides the IAsyncResult interface and the AsyncResult class.
8.	End the name of derived classes with the name of the base class. For example, OneFramework types that inherit from Stream end in Stream, and types that inherit from Exception end in Exception.

Rule	Do not
9.	Don’t use class names duplicated in heavily used namespaces. For example, don’t use any of the following for a class name: System, Collections, Forms, UI.
10.	Don’t have classes and namespaces with the same name.
11.	Don’t begin class names with the letter I (upper-case i), as that is the recommended prefix for interface names. If you must start with the letter I, ensure the second character is lower-case, as in IdentityStore.

Example (comments removed)

<span style="color: #0000FF">public abstract class</span> <span style="color: #2B91AF">BaseExceptionTranslator</span>
{

}

<span style="color: #0000FF">internal static</span> <span style="color: #2B91AF">classStudentDA</span>
{

}

<span style="color: #0000FF">public class</span> <span style="color: #2B91AF">StudentResultCollection: ICollection</span>
{

}

Naming properties

Relates to Microsoft Code Analysis Rules: CA1721, CA1722

Relates to Microsoft Naming Guidelines: Property Naming

Rule	Do
1.	Name properties using noun or noun phrases.
2.	When the attribute that the property Get and Set exposes is a boolean, prefix the method name with Is, Has, or Can, if value is added.
3.	Give a property the same name as its type. When a property is strongly typed to an enumeration, the name of the property can be the same as the name of the enumeration. For example, for an enumeration named CacheLevel, a property that returns one of its values can also be named CacheLevel.
4.	Use automatically implemented properties, where appropriate, and code the entire definition on one line. For example: Public string MyProperty { get; private set; }

Rule	Do not
5.	Don’t prefix the property name with a scope or data type identifier.
6.	Don’t use properties that match the names of Get methods. For example, don’t name a property EmployeeRecord and also name a method GetEmployeeRecord.

Example 1 (comments removed)

<span style="color: #0000FF">private string</span> _lastName;
<span style="color: #0000FF">public string</span> LastName
{
  <span style="color: #0000FF">get</span> { <span style="color: #0000FF">return</span> _lastName; }
  <span style="color: #0000FF">set</span> { _lastName = <span style="color: #0000FF">value</span>; }
}

<span style="color: #0000FF">private</span> <span style="color: #2B91AF">DateTime</span> _dateOfBirth;
<span style="color: #0000FF">public</span> <span style="color: #2B91AF">DateTime</span> DateOfBirth
{
  <span style="color: #0000FF">get</span> { <span style="color: #0000FF">return</span> _dateOfBirth; }
  <span style="color: #0000FF">set</span> { _dateOfBirth = <span style="color: #0000FF">value</span>; }
}

Example 2 (comments removed)

<span style="color: #0000FF">public bool</span> IsPrimary { <span style="color: #0000FF">get</span> { <span style="color: #0000FF">return</span> Type == (<span style="color: #0000FF">int</span>)Enumerations.<span style="color: #2B91AF">SchoolTypes</span>.Primary; } }

Naming methods

Relates to Microsoft Naming Guidelines: Method Naming

Rule	Do
1.	Name methods with verbs or verb phrases.
2,	Use the following names for common operations: * Save: Add or update a record. * Create: Add a new record. * Update: Update an existing record. * Delete: Delete an existing record. * List: Retrieve a collection of records. * Get: Retrieve a single record. * Get <column name>: Retrieve a specific column value for record.

Example (comments removed)

<span style="color: #0000FF">public void</span> Create()
{

}

<span style="color: #0000FF">public</span> <span style="color: #2B91AF">Collection</span>\<<span style="color: #2B91AF">Student</span>> List(
  <span style="color: #2B91AF">Int16</span> pageIndex,
  <span style="color: #2B91AF">Int16</span> pageSize)
{

}

<span style="color: #0000FF">internal static string</span> GetLookupDescription(
  <span style="color: #0000FF">string</span> lookupType,
  <span style="color: #0000FF">string</span> lookupCode,
  <span style="color: #2B91AF">MessageCollection</span> messages)
{

}

Naming parameters

Relates to Microsoft Code Analysis Rules: CA1719, CA1722

Relates to Microsoft Naming Guidelines: Parameter Naming

Rule	Do
1.	Use descriptive names to ensure that a parameter’s name and type clearly indicate its meaning.
2.	Base names on the parameter’s meaning, not on the parameter’s type.
3.	Avoid name clashes between parameters and member names.

Rule	Do not
4.	Don’t use a prefix for parameter naming.

Example (comments removed)

<span style="color: #0000FF">public void</span> Update(
  <span style="color: #2B91AF">Guid</span> id,
  <span style="color: #0000FF">string</span> lastName,
  <span style="color: #0000FF">string</span> firstName,
  <span style="color: #2B91AF">DateTime</span> dateOfBirth,
  <span style="color: #2B91AF">Int16</span> yearLevel)
{

}

Generic type parameters

Relates to Microsoft Code Analysis Rules: CA1715, CA1722

Rule	Do
1.	Name generic type parameters with descriptive names, unless a single-letter name is completely self-explanatory and a descriptive name would not add value. IDictionary<TKey, TValue> is an example of an interface that complies with this rule.
2.	Use the letter T as the type parameter name for types with one single-letter type parameter.
3.	Prefix descriptive type parameter names with the letter T.
4.	Indicate constraints placed on a type parameter in the name of parameter. For example, a parameter constrained to ISession may be called TSession.

Naming UI elements

The standard of prefixing controls/variables with three characters indicating the type (hungarian notation) is no longer used.

On those rare occasions where you need to give a control a name, adopt the conventions documented in the OneFramework web coding standards.

Naming interfaces

Relates to Microsoft Code Analysis Rules: CA1715, CA1722

Relates to Microsoft Naming Guidelines: Interface Naming

Rule	Do
1.	Name interfaces with nouns or noun phrases, or adjectives describing behaviour. For example, IComponent (descriptive noun), ICustomAttributeProvider (noun phrase), and IPersistable (adjective).
2.	Use abbreviations sparingly in interface names.
3.	Prefix interface names with the letter I (upper-case i), to indicate that the type is an interface.
4.	Use similar names when defining a class/interface pair where the class is a standard implementation of the interface. The names should differ only by the I (upper-case i) prefix of the interface name.

Example (comments removed)

<span style="color: #0000FF">public interface</span> <span style="color: #2B91AF">ILookup</span>
{
}
<span style="color: #0000FF">public class</span> <span style="color: #2B91AF">Lookup : ILookup</span>
{
}

Naming exceptions

Relates to Microsoft Code Analysis Rule: CA1710

Rule	Do
1.	Name exceptions with nouns or noun phrases.
2.	Use abbreviations sparingly in exception names.
3.	Use the suffix: Exception.

Example (comments removed)

<span style="color: #0000FF">public class</span> <span style="color: #2B91AF">SecurityException</span> : <span style="color: #2B91AF">SystemException</span>
{
}

Naming constants

| Rule | Do | | – | – | | 1. | Separate words using an underscore. | | 2. | Use a common prefix for related constants, not a suffix. |

Example (comments removed)

<span style="color: #0000FF">private const string</span> ENTITY_NAME = <span style="color: #A31515">"Student"</span>;
<span style="color: #0000FF">internal const</span> Int32 SESSION_TIMEOUT_MINUTES = 60;
<span style="color: #0000FF">public const string</span> MIME_TYPE_TEXT = <span style="color: #A31515">"text/plain"</span>;
<span style="color: #0000FF">public const string</span> MIME_TYPE_HTML = <span style="color: #A31515">"text/html"</span>;
<span style="color: #0000FF">public const string</span> MIME_TYPE_GIF = <span style="color: #A31515">"image/gif"</span>;
<span style="color: #0000FF">public void</span> Create()
{
  <span style="color: #0000FF">const</span> <span style="color: #2B91AF">Int16</span> DEFAULT_YEAR_LEVEL = 1;
  …
}

Naming enumerations

Relates to Microsoft Code Analysis Rules: CA1711, CA1712, CA1714, CA1717, CA1722

Relates to Microsoft Naming Guidelines: Enumeration Type Naming

Rule	Do
1.	Use singular names for most enum types, but use plural names for public enumerations with the System.FlagsAttribute attribute.
2.	Use abbreviations sparingly in names.
3.	Use a singular name for enumerations, unless its values are bit fields.

Rule	Do not
4.	Don’t use a family-name (type name) prefix for enumeration values.
5.	Don’t use any Enum prefix or suffix on enumeration types.
6.	Don’t use plural names for enumeration types that are not public enumerations with the System.FlagsAttribute attribute.

Example (comments removed)

<span style="color: #0000FF">public enum</span> <span style="color: #2B91AF">PrimaryColour</span>
{
  Red = 1,
  Green = 2,
  Blue = 3
}

[<span style="color: #2B91AF">Flags</span>]
<span style="color: #0000FF">public enum</span> <span style="color: #2B91AF">FileStatus</span>
{
  None = 0,
  Open = 1,
  Edit = 2,
  Save = 4,
  Close = 8,
  Corrupt = 16,
  Busy = 32,
  Good = Open | Edit | Save | Close,
  Bad = Corrupt | Busy
}

Naming static fields

Relates to Microsoft Naming Guidelines: Static Field Naming

Rule	Do
1.	Use nouns, noun phrases, or abbreviations of nouns to name static fields.
2.	Wherever possible, use static properties instead of public static fields.

Naming events and delegates

Relates to Microsoft Code Analysis Rules: CA1710, CA1711, CA1713, CA1722

Relates to Microsoft Naming Guidelines: Event Naming

Rule	Do
1.	Name event handlers with the EventHandler suffix.
2.	Name event argument classes with the EventArgs suffix.
3.	Name event names that have a concept of pre- and post-operation using the present and past tense (don’t use a BeforeXxx/AfterXxx pattern). For example, a Create() method could have Creating() and Created() events to indicate actions to occur before and after the Create has occurred.
4.	Use the CallBack suffix for a delegate that is not an event handler.
5.	Name events with a verb. For example: Clicked, DroppedDown.

Rule	Do not
6.	Don’t use the Delegate suffix for delegates.
7.	Don’t use a prefix or suffix on the event declaration on the type. For example, use Close instead on OnClose.

Example (comments removed)

<span style="color: #0000FF">public delegate object</span> <span style="color: #2B91AF">RefreshCacheCallback</span>(<span style="color: #0000FF">object</span>[] args);

<span style="color: #0000FF">public delegate void</span> <span style="color: #2B91AF">ChangedEventHandler</span>(<span style="color: #0000FF">object</span> sender, <span style="color: #2B91AF">EventArgs</span> e);

Naming local and member variables

Relates to Microsoft Code Analysis Rule: CA1722

Rule	Do
1.	Use meaningful, descriptive words to name variables, including nouns and noun phrases.
2.	Use an underscore prefix for member variables.

Rule	Do
3.	Don’t use prefixes or suffixes for local variables.
4.	Don’t use single character variable names. One exception in this case would be variables used for iterations in loops, where the variable is used only as a counter for iteration and is not used elsewhere in the loop.
5.	Don’t use abbreviations in variable names (e.g. string addr, int sal). Use full words instead (e.g. string address, int salary).

Example (comments removed)

<span style="color: #0000FF">public class</span> Student
{

  <span style="color: #0000FF">private</span> <span style="color: #2B91AF">Int16</span> _defaultYearLevel = 1;
  <span style="color: #0000FF">private</span> <span style="color: #2B91AF">Decimal</span> _defaultPaymentAmount = 1500.00;

  <span style="color: #0000FF">public</span> <span style="color: #2B91AF">Int32</span> GetNumberOfClasses()
  {
    <span style="color: #2B91AF">Int32</span> numberOfClasses = 0;
    <span style="color: #0000FF">string</span> studentName = <span style="color: #2B91AF">String</span>.Empty;
    …
  }
}

Naming resources

Relates to Microsoft Code Analysis Rules: CA1722

Rule	Do
1.	Provide descriptive, rather than short, identifiers. Keep identifiers concise where possible, but don’t sacrifice readability.
2.	Use only alphanumeric characters in naming resources.
3.	Use the dot separator to nest identifiers with a clear hierarchy. For example: Menus.FileMenu.Close.Text and Menus.FileMenu.Close.Color.
4.	Use the standard naming convention for exception message resources. The resource identifier should be the exception type name plus a short identifier of the exception separated by a dot. For example: ArgumentException.BadEnumValue store in file named: ArgumentErrorText.resx.

Rule	Do not
5.	Don’t use a resource prefix or suffix in the name of a resource. Use the format: [Class][Purpose].resx where Purpose = ErrorText, Expression, Message.

Example (comments removed)

<span style="color: #0000FF">OneFramework\Resources\ConfigurationErrorText.resx
OneFramework.Web\Resources\HTML.resx
OneFramework.UnitTest\ErrorResource.resx
OneFramework.Application\TextResource.resx
OneFramework.Utilities.IO\Resources\IOErrorText.resx
OneFramework.Utilities.Email\Resources\EmailErrorText.resx
OneFramework.DataAccess\DAResource.resx
OneFramework.Validators\Resources\FileValidationText.resx
OneFramework.Validators\Resources\RegExResource.resx
OneFramework.Validators\Resources\ValidationResource.resx
OneFramework.DataProtection\Resources\DataProtectionErrorText.resx</span>

I have an idea

I found a bug

I have a question