<?xml version="1.0" encoding="utf-8"?>
<root>
  <!-- 
    Microsoft ResX Schema 
    
    Version 2.0
    
    The primary goals of this format is to allow a simple XML format 
    that is mostly human readable. The generation and parsing of the 
    various data types are done through the TypeConverter classes 
    associated with the data types.
    
    Example:
    
    ... ado.net/XML headers & schema ...
    <resheader name="resmimetype">text/microsoft-resx</resheader>
    <resheader name="version">2.0</resheader>
    <resheader name="reader">System.Resources.ResXResourceReader, System.Windows.Forms, ...</resheader>
    <resheader name="writer">System.Resources.ResXResourceWriter, System.Windows.Forms, ...</resheader>
    <data name="Name1"><value>this is my long string</value><comment>this is a comment</comment></data>
    <data name="Color1" type="System.Drawing.Color, System.Drawing">Blue</data>
    <data name="Bitmap1" mimetype="application/x-microsoft.net.object.binary.base64">
        <value>[base64 mime encoded serialized .NET Framework object]</value>
    </data>
    <data name="Icon1" type="System.Drawing.Icon, System.Drawing" mimetype="application/x-microsoft.net.object.bytearray.base64">
        <value>[base64 mime encoded string representing a byte array form of the .NET Framework object]</value>
        <comment>This is a comment</comment>
    </data>
                
    There are any number of "resheader" rows that contain simple 
    name/value pairs.
    
    Each data row contains a name, and value. The row also contains a 
    type or mimetype. Type corresponds to a .NET class that support 
    text/value conversion through the TypeConverter architecture. 
    Classes that don't support this are serialized and stored with the 
    mimetype set.
    
    The mimetype is used for serialized objects, and tells the 
    ResXResourceReader how to depersist the object. This is currently not 
    extensible. For a given mimetype the value must be set accordingly:
    
    Note - application/x-microsoft.net.object.binary.base64 is the format 
    that the ResXResourceWriter will generate, however the reader can 
    read any of the formats listed below.
    
    mimetype: application/x-microsoft.net.object.binary.base64
    value   : The object must be serialized with 
            : System.Runtime.Serialization.Formatters.Binary.BinaryFormatter
            : and then encoded with base64 encoding.
    
    mimetype: application/x-microsoft.net.object.soap.base64
    value   : The object must be serialized with 
            : System.Runtime.Serialization.Formatters.Soap.SoapFormatter
            : and then encoded with base64 encoding.

    mimetype: application/x-microsoft.net.object.bytearray.base64
    value   : The object must be serialized into a byte array 
            : using a System.ComponentModel.TypeConverter
            : and then encoded with base64 encoding.
    -->
  <xsd:schema id="root" xmlns="" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:msdata="urn:schemas-microsoft-com:xml-msdata">
    <xsd:import namespace="http://www.w3.org/XML/1998/namespace" />
    <xsd:element name="root" msdata:IsDataSet="true">
      <xsd:complexType>
        <xsd:choice maxOccurs="unbounded">
          <xsd:element name="metadata">
            <xsd:complexType>
              <xsd:sequence>
                <xsd:element name="value" type="xsd:string" minOccurs="0" />
              </xsd:sequence>
              <xsd:attribute name="name" use="required" type="xsd:string" />
              <xsd:attribute name="type" type="xsd:string" />
              <xsd:attribute name="mimetype" type="xsd:string" />
              <xsd:attribute ref="xml:space" />
            </xsd:complexType>
          </xsd:element>
          <xsd:element name="assembly">
            <xsd:complexType>
              <xsd:attribute name="alias" type="xsd:string" />
              <xsd:attribute name="name" type="xsd:string" />
            </xsd:complexType>
          </xsd:element>
          <xsd:element name="data">
            <xsd:complexType>
              <xsd:sequence>
                <xsd:element name="value" type="xsd:string" minOccurs="0" msdata:Ordinal="1" />
                <xsd:element name="comment" type="xsd:string" minOccurs="0" msdata:Ordinal="2" />
              </xsd:sequence>
              <xsd:attribute name="name" type="xsd:string" use="required" msdata:Ordinal="1" />
              <xsd:attribute name="type" type="xsd:string" msdata:Ordinal="3" />
              <xsd:attribute name="mimetype" type="xsd:string" msdata:Ordinal="4" />
              <xsd:attribute ref="xml:space" />
            </xsd:complexType>
          </xsd:element>
          <xsd:element name="resheader">
            <xsd:complexType>
              <xsd:sequence>
                <xsd:element name="value" type="xsd:string" minOccurs="0" msdata:Ordinal="1" />
              </xsd:sequence>
              <xsd:attribute name="name" type="xsd:string" use="required" />
            </xsd:complexType>
          </xsd:element>
        </xsd:choice>
      </xsd:complexType>
    </xsd:element>
  </xsd:schema>
  <resheader name="resmimetype">
    <value>text/microsoft-resx</value>
  </resheader>
  <resheader name="version">
    <value>2.0</value>
  </resheader>
  <resheader name="reader">
    <value>System.Resources.ResXResourceReader, System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</value>
  </resheader>
  <resheader name="writer">
    <value>System.Resources.ResXResourceWriter, System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</value>
  </resheader>
  <data name="MiKo_0001_Description" xml:space="preserve">
    <value>Methods should be short to ease reading and maintenance (SRP, SLoA).</value>
  </data>
  <data name="MiKo_0001_MessageFormat" xml:space="preserve">
    <value>Too many LoC: {1,4} (allowed are max. {2})</value>
  </data>
  <data name="MiKo_0001_Title" xml:space="preserve">
    <value>Method is too big</value>
  </data>
  <data name="MiKo_0002_Description" xml:space="preserve">
    <value>To make maintenance easier, methods should be kept simple. This follows the Keep It Simple, Stupid (KISS) principle.
Following code constructs increase the Cyclomatic Complexity (CC) by +1:
    if | while | for | foreach | case | continue | goto | &amp;&amp; | || | catch | catch when | ternary operator ?: | ?? | ?.</value>
  </data>
  <data name="MiKo_0002_MessageFormat" xml:space="preserve">
    <value>Too high CC: {1,4} (allowed are max. {2})</value>
  </data>
  <data name="MiKo_0002_Title" xml:space="preserve">
    <value>Method is too complex</value>
  </data>
  <data name="MiKo_0003_Description" xml:space="preserve">
    <value>To make code easier to read and maintain, types should be kept small. This follows the Single Responsibility Principle (SRP).</value>
  </data>
  <data name="MiKo_0003_MessageFormat" xml:space="preserve">
    <value>Too many LoC: {1,4} (allowed are max. {2})</value>
  </data>
  <data name="MiKo_0003_Title" xml:space="preserve">
    <value>Type is too big</value>
  </data>
  <data name="MiKo_0004_Description" xml:space="preserve">
    <value>To follow the Single Responsibility Principle (SRP), methods should use as few parameters as possible.</value>
  </data>
  <data name="MiKo_0004_MessageFormat" xml:space="preserve">
    <value>Too many parameters: {1,4} (allowed are max. {2})</value>
  </data>
  <data name="MiKo_0004_Title" xml:space="preserve">
    <value>Method has too many parameters</value>
  </data>
  <data name="MiKo_0005_Description" xml:space="preserve">
    <value>To make code easier to read and maintain, local functions should be kept short. This follows the Single Responsibility Principle (SRP) and the Single Level of Abstraction (SLoA) principle.</value>
  </data>
  <data name="MiKo_0005_MessageFormat" xml:space="preserve">
    <value>Too many LoC: {1,4} (allowed are max. {2})</value>
  </data>
  <data name="MiKo_0005_Title" xml:space="preserve">
    <value>Local function is too big</value>
  </data>
  <data name="MiKo_0006_Description" xml:space="preserve">
    <value>To make maintenance easier, local functions should be kept simple. This follows the Keep It Simple, Stupid (KISS) principle.
Following code constructs increase the Cyclomatic Complexity (CC) by +1:
    if | while | for | foreach | case | continue | goto | &amp;&amp; | || | catch | catch when | ternary operator ?: | ?? | ?.</value>
  </data>
  <data name="MiKo_0006_MessageFormat" xml:space="preserve">
    <value>Too high CC: {1,4} (allowed are max. {2})</value>
  </data>
  <data name="MiKo_0006_Title" xml:space="preserve">
    <value>Local function is too complex</value>
  </data>
  <data name="MiKo_0007_Description" xml:space="preserve">
    <value>To follow the Single Responsibility Principle (SRP), local functions should use as few parameters as possible.</value>
  </data>
  <data name="MiKo_0007_MessageFormat" xml:space="preserve">
    <value>Too many parameters: {1,4} (allowed are max. {2})</value>
  </data>
  <data name="MiKo_0007_Title" xml:space="preserve">
    <value>Local function has too many parameters</value>
  </data>
  <data name="MiKo_1000_CodeFixTitle" xml:space="preserve">
    <value>Append suffix 'EventArgs'</value>
  </data>
  <data name="MiKo_1000_Description" xml:space="preserve">
    <value>To maintain consistency and clarity in code, event argument types should inherit from 'System.EventArgs' and their names should end with 'EventArgs'.</value>
  </data>
  <data name="MiKo_1000_MessageFormat" xml:space="preserve">
    <value>Name it '{1}' instead</value>
  </data>
  <data name="MiKo_1000_Title" xml:space="preserve">
    <value>'System.EventArgs' types should be suffixed with 'EventArgs'</value>
  </data>
  <data name="MiKo_1001_CodeFixTitle" xml:space="preserve">
    <value>Rename event argument</value>
  </data>
  <data name="MiKo_1001_Description" xml:space="preserve">
    <value>To maintain consistency and clarity in code, parameters that inherit from 'System.EventArgs' should be named 'e'.</value>
  </data>
  <data name="MiKo_1001_HelpLinkUri" xml:space="preserve">
    <value>https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/event</value>
  </data>
  <data name="MiKo_1001_MessageFormat" xml:space="preserve">
    <value>Name it '{1}'</value>
  </data>
  <data name="MiKo_1001_Title" xml:space="preserve">
    <value>'System.EventArgs' parameters should be named 'e'</value>
  </data>
  <data name="MiKo_1002_CodeFixTitle" xml:space="preserve">
    <value>Rename event argument</value>
  </data>
  <data name="MiKo_1002_Description" xml:space="preserve">
    <value>To follow the .NET Framework Design Guidelines, parameters of event handlers should be named 'sender' and 'e'.</value>
  </data>
  <data name="MiKo_1002_HelpLinkUri" xml:space="preserve">
    <value>https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/event</value>
  </data>
  <data name="MiKo_1002_MessageFormat" xml:space="preserve">
    <value>Name it '{1}'</value>
  </data>
  <data name="MiKo_1002_Title" xml:space="preserve">
    <value>Parameters should be named according the .NET Framework Design Guidelines for event handlers</value>
  </data>
  <data name="MiKo_1003_CodeFixTitle" xml:space="preserve">
    <value>Rename method according to event pattern</value>
  </data>
  <data name="MiKo_1003_Description" xml:space="preserve">
    <value>Event handlers should be named starting with 'On' followed by the event name to show they handle events.</value>
  </data>
  <data name="MiKo_1003_HelpLinkUri" xml:space="preserve">
    <value>https://learn.microsoft.com/en-us/dotnet/csharp/event-pattern</value>
  </data>
  <data name="MiKo_1003_MessageFormat" xml:space="preserve">
    <value>Name it '{1}'</value>
  </data>
  <data name="MiKo_1003_Title" xml:space="preserve">
    <value>Event handling method names should follow the .NET Framework Design Guidelines</value>
  </data>
  <data name="MiKo_1004_CodeFixTitle" xml:space="preserve">
    <value>Remove 'Event' suffix</value>
  </data>
  <data name="MiKo_1004_Description" xml:space="preserve">
    <value>Avoid using 'Event' as a suffix in event names because it's unnecessary and adds clutter.</value>
  </data>
  <data name="MiKo_1004_MessageFormat" xml:space="preserve">
    <value>Name it '{1}'</value>
  </data>
  <data name="MiKo_1004_Title" xml:space="preserve">
    <value>Events should not contain term 'Event' in their names</value>
  </data>
  <data name="MiKo_1005_CodeFixTitle" xml:space="preserve">
    <value>Rename EventArgs variable</value>
  </data>
  <data name="MiKo_1005_Description" xml:space="preserve">
    <value>To maintain consistency and clarity in code, variables of type 'System.EventArgs' (or its inheritors) should be named 'e'.</value>
  </data>
  <data name="MiKo_1005_MessageFormat" xml:space="preserve">
    <value>Name it '{1}'</value>
  </data>
  <data name="MiKo_1005_Title" xml:space="preserve">
    <value>'System.EventArgs' variables should be named properly</value>
  </data>
  <data name="MiKo_1006_Description" xml:space="preserve">
    <value>Events should use 'EventHandler&lt;T&gt;', where 'T' is a class that inherits from 'System.EventArgs' and is named after the event.
Example: A 'Loaded' event should use an 'EventHandler&lt;LoadedEventArgs&gt;'.</value>
  </data>
  <data name="MiKo_1006_MessageFormat" xml:space="preserve">
    <value>Use 'EventHandler&lt;{1}&gt;' instead</value>
  </data>
  <data name="MiKo_1006_Title" xml:space="preserve">
    <value>Events should use 'EventHandler&lt;T&gt;' with 'EventArgs' which are named after the event</value>
  </data>
  <data name="MiKo_1007_Description" xml:space="preserve">
    <value>Events and their event arguments are logically related, so they should be placed in the same namespace for better organization.</value>
  </data>
  <data name="MiKo_1007_MessageFormat" xml:space="preserve">
    <value>Used '{1}' should be in namespace '{2}'</value>
  </data>
  <data name="MiKo_1007_Title" xml:space="preserve">
    <value>Events and their corresponding 'EventArgs' types should be located in the same namespace</value>
  </data>
  <data name="MiKo_1008_CodeFixTitle" xml:space="preserve">
    <value>Rename DependencyProperty event handler argument</value>
  </data>
  <data name="MiKo_1008_Description" xml:space="preserve">
    <value>To follow the .NET Framework Design Guidelines, parameters of DependencyProperty event handlers should be named 'd' and 'e'.</value>
  </data>
  <data name="MiKo_1008_MessageFormat" xml:space="preserve">
    <value>Name it '{1}'</value>
  </data>
  <data name="MiKo_1008_Title" xml:space="preserve">
    <value>Parameters should be named according the .NET Framework Design Guidelines for DependencyProperty event handlers</value>
  </data>
  <data name="MiKo_1009_CodeFixTitle" xml:space="preserve">
    <value>Name event handler variable 'handler'</value>
  </data>
  <data name="MiKo_1009_Description" xml:space="preserve">
    <value>EventHandler variables should be named 'handler', to show they handle events.</value>
  </data>
  <data name="MiKo_1009_MessageFormat" xml:space="preserve">
    <value>Name it 'handler'</value>
  </data>
  <data name="MiKo_1009_Title" xml:space="preserve">
    <value>'System.EventHandler' variables should be named properly</value>
  </data>
  <data name="MiKo_1010_CodeFixTitle" xml:space="preserve">
    <value>Remove 'Execute' from name</value>
  </data>
  <data name="MiKo_1010_Description" xml:space="preserve">
    <value>Methods are meant to run code, so adding words like 'CanExecute' or 'Execute' to their names is unnecessary and repetitive. It's like saying 'executeExecute' - it does not add any useful information.</value>
  </data>
  <data name="MiKo_1010_MessageFormat" xml:space="preserve">
    <value>Name it '{1}'</value>
  </data>
  <data name="MiKo_1010_Title" xml:space="preserve">
    <value>Methods should not contain 'CanExecute' or 'Execute' in their names</value>
  </data>
  <data name="MiKo_1011_CodeFixTitle" xml:space="preserve">
    <value>Remove 'Do' from name</value>
  </data>
  <data name="MiKo_1011_Description" xml:space="preserve">
    <value>Methods are meant to run code, so adding words like 'Do' to their names is unnecessary and repetitive. It's like saying 'doDo' - it doesn't add any useful information.</value>
  </data>
  <data name="MiKo_1011_MessageFormat" xml:space="preserve">
    <value>Name it '{1}'</value>
  </data>
  <data name="MiKo_1011_Title" xml:space="preserve">
    <value>Methods should not contain 'Do' in their names</value>
  </data>
  <data name="MiKo_1012_CodeFixTitle" xml:space="preserve">
    <value>Rename 'fire' to 'raise'</value>
  </data>
  <data name="MiKo_1012_Description" xml:space="preserve">
    <value>The word 'Fire' has negative connotations, like firing employees or guns. It's not appropriate for events. Instead, use 'Raise' for events, as it conveys a more neutral and accurate action.</value>
  </data>
  <data name="MiKo_1012_MessageFormat" xml:space="preserve">
    <value>Name it '{1}'</value>
  </data>
  <data name="MiKo_1012_Title" xml:space="preserve">
    <value>Methods should be named 'Raise' instead of 'Fire'</value>
  </data>
  <data name="MiKo_1013_CodeFixTitle" xml:space="preserve">
    <value>Rename 'Notify' to 'On'</value>
  </data>
  <data name="MiKo_1013_Description" xml:space="preserve">
    <value>Seeing 'Notify' in a method name often means an event is being raised. In these cases, it's better to use the prefix 'On' instead. For example, instead of 'NotifyPropertyChanged', use 'OnPropertyChanged'. This makes it clearer that an event is being triggered.</value>
  </data>
  <data name="MiKo_1013_MessageFormat" xml:space="preserve">
    <value>Do not use term 'Notify'</value>
  </data>
  <data name="MiKo_1013_Title" xml:space="preserve">
    <value>Methods should not be named 'Notify' or 'OnNotify'</value>
  </data>
  <data name="MiKo_1014_CodeFixTitle" xml:space="preserve">
    <value>Rename 'Check'</value>
  </data>
  <data name="MiKo_1014_Description" xml:space="preserve">
    <value>The term 'Check' is ambiguous. If you mean to validate parameters, use words like 'Validate' or 'Verify'. If you're checking for a specific state, use 'Is', 'Can' or 'Has' instead. This makes your code more precise and easier to understand.</value>
  </data>
  <data name="MiKo_1014_MessageFormat" xml:space="preserve">
    <value>Do not use ambiguous term 'Check'</value>
  </data>
  <data name="MiKo_1014_Title" xml:space="preserve">
    <value>Methods should not be named with ambiguous 'Check'</value>
  </data>
  <data name="MiKo_1015_CodeFixTitle" xml:space="preserve">
    <value>Rename 'Init' to 'Initialize'</value>
  </data>
  <data name="MiKo_1015_Description" xml:space="preserve">
    <value>Instead of using the short form 'Init', you should use the full word 'Initialize'. Using 'Init' is considered lazy and less clear.</value>
  </data>
  <data name="MiKo_1015_MessageFormat" xml:space="preserve">
    <value>Name it '{1}'</value>
  </data>
  <data name="MiKo_1015_Title" xml:space="preserve">
    <value>Methods should be named 'Initialize' instead of 'Init'</value>
  </data>
  <data name="MiKo_1016_CodeFixTitle" xml:space="preserve">
    <value>Rename factory method</value>
  </data>
  <data name="MiKo_1016_Description" xml:space="preserve">
    <value>Since the method is part of a factory, its name should begin with 'Create'. This helps indicate its purpose more clearly.</value>
  </data>
  <data name="MiKo_1016_MessageFormat" xml:space="preserve">
    <value>Start name with 'Create'</value>
  </data>
  <data name="MiKo_1016_Title" xml:space="preserve">
    <value>Factory methods should be named 'Create'</value>
  </data>
  <data name="MiKo_1017_CodeFixTitle" xml:space="preserve">
    <value>Remove prefix from method</value>
  </data>
  <data name="MiKo_1017_Description" xml:space="preserve">
    <value>Avoid using 'Get' or 'Set' at the beginning of method names if the method already starts with 'Is', 'Can' or 'Has'. The 'Get' or 'Set' is unnecessary and makes the name longer without adding value.</value>
  </data>
  <data name="MiKo_1017_MessageFormat" xml:space="preserve">
    <value>Name it '{1}'</value>
  </data>
  <data name="MiKo_1017_Title" xml:space="preserve">
    <value>Methods should not be prefixed with 'Get' or 'Set' if followed by 'Is', 'Can' or 'Has'</value>
  </data>
  <data name="MiKo_1018_CodeFixTitle" xml:space="preserve">
    <value>Change noun to verb</value>
  </data>
  <data name="MiKo_1018_Description" xml:space="preserve">
    <value>When naming methods, avoid adding a noun form of a verb at the end if the verb itself is appropriate as the method name. This practice ensures method names are concise and clear.</value>
  </data>
  <data name="MiKo_1018_MessageFormat" xml:space="preserve">
    <value>Name it '{1}'</value>
  </data>
  <data name="MiKo_1018_Title" xml:space="preserve">
    <value>Methods should not be suffixed with noun of a verb</value>
  </data>
  <data name="MiKo_1019_CodeFixTitle" xml:space="preserve">
    <value>Rename 'Clear' and 'Remove'</value>
  </data>
  <data name="MiKo_1019_Description" xml:space="preserve">
    <value>Methods named 'Remove' that have no parameters should be renamed to 'Clear' to better reflect their function.
Conversely, methods named 'Clear' that have parameters should be renamed to 'Remove' to accurately describe their action.
This naming convention helps ensure clarity and consistency in method functionality.</value>
  </data>
  <data name="MiKo_1019_MessageFormat" xml:space="preserve">
    <value>Name it '{1}'</value>
  </data>
  <data name="MiKo_1019_Title" xml:space="preserve">
    <value>'Clear' and 'Remove' methods should be named based on their number of parameters</value>
  </data>
  <data name="MiKo_1020_Description" xml:space="preserve">
    <value>Long names can be difficult to read and use, making both writing code and conducting code reviews more challenging. Keeping names concise improves readability and efficiency.</value>
  </data>
  <data name="MiKo_1020_MessageFormat" xml:space="preserve">
    <value>Type name exceeds limit of {2} chars by {1}</value>
  </data>
  <data name="MiKo_1020_Title" xml:space="preserve">
    <value>Type names should be limited in length</value>
  </data>
  <data name="MiKo_1021_Description" xml:space="preserve">
    <value>Long names can be difficult to read and use, making both writing code and conducting code reviews more challenging. Keeping names concise improves readability and efficiency.</value>
  </data>
  <data name="MiKo_1021_MessageFormat" xml:space="preserve">
    <value>Method name exceeds limit of {2} chars by {1}</value>
  </data>
  <data name="MiKo_1021_Title" xml:space="preserve">
    <value>Method names should be limited in length</value>
  </data>
  <data name="MiKo_1022_Description" xml:space="preserve">
    <value>Long names can be difficult to read and use, making both writing code and conducting code reviews more challenging. Keeping names concise improves readability and efficiency.</value>
  </data>
  <data name="MiKo_1022_MessageFormat" xml:space="preserve">
    <value>Parameter name exceeds limit of {2} chars by {1}</value>
  </data>
  <data name="MiKo_1022_Title" xml:space="preserve">
    <value>Parameter names should be limited in length</value>
  </data>
  <data name="MiKo_1023_Description" xml:space="preserve">
    <value>Long names can be difficult to read and use, making both writing code and conducting code reviews more challenging. Keeping names concise improves readability and efficiency.</value>
  </data>
  <data name="MiKo_1023_MessageFormat" xml:space="preserve">
    <value>Field name exceeds limit of {2} chars by {1}</value>
  </data>
  <data name="MiKo_1023_Title" xml:space="preserve">
    <value>Field names should be limited in length</value>
  </data>
  <data name="MiKo_1024_Description" xml:space="preserve">
    <value>Long names can be difficult to read and use, making both writing code and conducting code reviews more challenging. Keeping names concise improves readability and efficiency.</value>
  </data>
  <data name="MiKo_1024_MessageFormat" xml:space="preserve">
    <value>Property name exceeds limit of {2} chars by {1}</value>
  </data>
  <data name="MiKo_1024_Title" xml:space="preserve">
    <value>Property names should be limited in length</value>
  </data>
  <data name="MiKo_1025_Description" xml:space="preserve">
    <value>Long names can be difficult to read and use, making both writing code and conducting code reviews more challenging. Keeping names concise improves readability and efficiency.</value>
  </data>
  <data name="MiKo_1025_MessageFormat" xml:space="preserve">
    <value>Event name exceeds limit of {2} chars by {1}</value>
  </data>
  <data name="MiKo_1025_Title" xml:space="preserve">
    <value>Event names should be limited in length</value>
  </data>
  <data name="MiKo_1026_Description" xml:space="preserve">
    <value>Long names can be difficult to read and use, making both writing code and conducting code reviews more challenging. Keeping names concise improves readability and efficiency.</value>
  </data>
  <data name="MiKo_1026_MessageFormat" xml:space="preserve">
    <value>Variable name exceeds limit of {2} chars by {1}</value>
  </data>
  <data name="MiKo_1026_Title" xml:space="preserve">
    <value>Variable names should be limited in length</value>
  </data>
  <data name="MiKo_1027_Description" xml:space="preserve">
    <value>Long names can be difficult to read and use, making both writing code and conducting code reviews more challenging. Keeping names concise improves readability and efficiency.</value>
  </data>
  <data name="MiKo_1027_MessageFormat" xml:space="preserve">
    <value>Variable name in loop exceeds limit of {2} chars by {1}</value>
  </data>
  <data name="MiKo_1027_Title" xml:space="preserve">
    <value>Variable names in loops should be limited in length</value>
  </data>
  <data name="MiKo_1028_Description" xml:space="preserve">
    <value>Long names can be difficult to read and use, making both writing code and conducting code reviews more challenging. Keeping names concise improves readability and efficiency.</value>
  </data>
  <data name="MiKo_1028_MessageFormat" xml:space="preserve">
    <value>Local function name exceeds limit of {2} chars by {1}</value>
  </data>
  <data name="MiKo_1028_Title" xml:space="preserve">
    <value>Local function names should be limited in length</value>
  </data>
  <data name="MiKo_1030_CodeFixTitle" xml:space="preserve">
    <value>Remove base type indicator</value>
  </data>
  <data name="MiKo_1030_Description" xml:space="preserve">
    <value>Using 'Abstract' or 'Base' in the name of a type to indicate it is a base type is unnecessary. Any interface or type that is not sealed can serve as a base type, so adding these terms only creates clutter and distracts users.</value>
  </data>
  <data name="MiKo_1030_MessageFormat" xml:space="preserve">
    <value>Remove '{1}' from name</value>
  </data>
  <data name="MiKo_1030_Title" xml:space="preserve">
    <value>Types should not have an 'Abstract' or 'Base' marker to indicate that they are base types</value>
  </data>
  <data name="MiKo_1031_CodeFixTitle" xml:space="preserve">
    <value>Remove 'Model' indicator</value>
  </data>
  <data name="MiKo_1031_Description" xml:space="preserve">
    <value>Using 'Model' as a suffix for entity types is unnecessary. Entities should just be named plainly without any suffixes. For example, use 'User' instead of 'UserModel'.</value>
  </data>
  <data name="MiKo_1031_MessageFormat" xml:space="preserve">
    <value>Name it '{1}'</value>
  </data>
  <data name="MiKo_1031_Title" xml:space="preserve">
    <value>Entity types should not use a 'Model' suffix</value>
  </data>
  <data name="MiKo_1032_CodeFixTitle" xml:space="preserve">
    <value>Remove 'Model' indicator</value>
  </data>
  <data name="MiKo_1032_Description" xml:space="preserve">
    <value>Using 'Model' in a method name to indicate it deals with an entity is unnecessary. Just name the method clearly without using 'Model'.</value>
  </data>
  <data name="MiKo_1032_MessageFormat" xml:space="preserve">
    <value>Name it '{1}'</value>
  </data>
  <data name="MiKo_1032_Title" xml:space="preserve">
    <value>Methods dealing with entities should not use a 'Model' as marker</value>
  </data>
  <data name="MiKo_1033_CodeFixTitle" xml:space="preserve">
    <value>Remove 'Model' indicator</value>
  </data>
  <data name="MiKo_1033_Description" xml:space="preserve">
    <value>Adding 'Model' as a suffix to a parameter name is unnecessary. Just name the parameter plainly, like using 'user' instead of 'userModel'. This keeps it simple and clear.</value>
  </data>
  <data name="MiKo_1033_MessageFormat" xml:space="preserve">
    <value>Name it '{1}'</value>
  </data>
  <data name="MiKo_1033_Title" xml:space="preserve">
    <value>Parameters representing entities should not use a 'Model' suffix</value>
  </data>
  <data name="MiKo_1034_CodeFixTitle" xml:space="preserve">
    <value>Remove 'Model' indicator</value>
  </data>
  <data name="MiKo_1034_Description" xml:space="preserve">
    <value>Using 'Model' as a suffix for field names is unnecessary. Just name the field plainly, like 'user' instead of 'userModel'. This keeps it simple and clear.</value>
  </data>
  <data name="MiKo_1034_MessageFormat" xml:space="preserve">
    <value>Name it '{1}'</value>
  </data>
  <data name="MiKo_1034_Title" xml:space="preserve">
    <value>Fields representing entities should not use a 'Model' suffix</value>
  </data>
  <data name="MiKo_1035_CodeFixTitle" xml:space="preserve">
    <value>Remove 'Model' indicator</value>
  </data>
  <data name="MiKo_1035_Description" xml:space="preserve">
    <value>Using 'Model' in a property name to show it deals with an entity is unnecessary. Just name the property clearly without 'Model'.</value>
  </data>
  <data name="MiKo_1035_MessageFormat" xml:space="preserve">
    <value>Name it '{1}'</value>
  </data>
  <data name="MiKo_1035_Title" xml:space="preserve">
    <value>Properties dealing with entities should not use a 'Model' marker</value>
  </data>
  <data name="MiKo_1036_CodeFixTitle" xml:space="preserve">
    <value>Remove 'Model' indicator</value>
  </data>
  <data name="MiKo_1036_Description" xml:space="preserve">
    <value>Using 'Model' in an event name to show it deals with an entity is unnecessary. Just name the event clearly without 'Model'.</value>
  </data>
  <data name="MiKo_1036_MessageFormat" xml:space="preserve">
    <value>Name it '{1}'</value>
  </data>
  <data name="MiKo_1036_Title" xml:space="preserve">
    <value>Events dealing with entities should not use a 'Model' marker</value>
  </data>
  <data name="MiKo_1037_CodeFixTitle" xml:space="preserve">
    <value>Remove type suffix</value>
  </data>
  <data name="MiKo_1037_Description" xml:space="preserve">
    <value>Using 'Enum' as a suffix to indicate a type an Enum is unnecessary. This also goes for suffixes in general, whether for interfaces, classes, records, or structs. Keeping names clear and straightforward without these suffixes makes the code cleaner and easier to understand.</value>
  </data>
  <data name="MiKo_1037_MessageFormat" xml:space="preserve">
    <value>Name it '{1}'</value>
  </data>
  <data name="MiKo_1037_Title" xml:space="preserve">
    <value>Types should not be suffixed with 'Type', 'Interface', 'Class', 'Struct', 'Record' or 'Enum'</value>
  </data>
  <data name="MiKo_1038_CodeFixTitle" xml:space="preserve">
    <value>Suffix type with 'Extensions'</value>
  </data>
  <data name="MiKo_1038_Description" xml:space="preserve">
    <value>To make maintenance easier, classes with extension methods should all end with the same suffix. This helps quickly identify their purpose and makes the code easier to work with.</value>
  </data>
  <data name="MiKo_1038_MessageFormat" xml:space="preserve">
    <value>End name with '{1}'</value>
  </data>
  <data name="MiKo_1038_Title" xml:space="preserve">
    <value>Classes that contain extension methods should end with same suffix</value>
  </data>
  <data name="MiKo_1039_CodeFixTitle" xml:space="preserve">
    <value>Rename 'this' argument</value>
  </data>
  <data name="MiKo_1039_Description" xml:space="preserve">
    <value>To simplify maintenance, the 'this' parameter in extension methods should always have a standard name. This makes the code consistent and easier to understand.</value>
  </data>
  <data name="MiKo_1039_MessageFormat" xml:space="preserve">
    <value>Name it {1}</value>
  </data>
  <data name="MiKo_1039_Title" xml:space="preserve">
    <value>The 'this' parameter of extension methods should have a default name</value>
  </data>
  <data name="MiKo_1040_Description" xml:space="preserve">
    <value>Adding suffixes like 'List' to parameter names adds unnecessary clutter. It's best to avoid them for cleaner, more readable code.</value>
  </data>
  <data name="MiKo_1040_MessageFormat" xml:space="preserve">
    <value>Name it '{1}'</value>
  </data>
  <data name="MiKo_1040_Title" xml:space="preserve">
    <value>Parameters should not be suffixed with implementation details</value>
  </data>
  <data name="MiKo_1041_Description" xml:space="preserve">
    <value>Adding suffixes like 'List' to field names adds unnecessary clutter. It's best to avoid them for cleaner, more readable code.</value>
  </data>
  <data name="MiKo_1041_MessageFormat" xml:space="preserve">
    <value>Name it '{1}'</value>
  </data>
  <data name="MiKo_1041_Title" xml:space="preserve">
    <value>Fields should not be suffixed with implementation details</value>
  </data>
  <data name="MiKo_1042_CodeFixTitle" xml:space="preserve">
    <value>Name it 'cancellationToken'</value>
  </data>
  <data name="MiKo_1042_Description" xml:space="preserve">
    <value>To simplify maintenance and align with .NET Framework standards, 'CancellationToken' parameters should be consistently named. This helps keep the code clear and consistent.</value>
  </data>
  <data name="MiKo_1042_MessageFormat" xml:space="preserve">
    <value>Name it '{1}'</value>
  </data>
  <data name="MiKo_1042_Title" xml:space="preserve">
    <value>'CancellationToken' parameters should have specific name</value>
  </data>
  <data name="MiKo_1043_CodeFixTitle" xml:space="preserve">
    <value>Name it 'token'</value>
  </data>
  <data name="MiKo_1043_Description" xml:space="preserve">
    <value>To simplify maintenance and align with .NET Framework standards, 'CancellationToken' variables should be consistently named. This helps keep the code clear and consistent.</value>
  </data>
  <data name="MiKo_1043_MessageFormat" xml:space="preserve">
    <value>Name it '{1}'</value>
  </data>
  <data name="MiKo_1043_Title" xml:space="preserve">
    <value>'CancellationToken' variables should have specific name</value>
  </data>
  <data name="MiKo_1044_CodeFixTitle" xml:space="preserve">
    <value>Append 'Command' suffix</value>
  </data>
  <data name="MiKo_1044_Description" xml:space="preserve">
    <value>To simplify maintenance, always add the suffix 'Command' to commands. This makes it clear they are commands and keeps the code consistent.</value>
  </data>
  <data name="MiKo_1044_MessageFormat" xml:space="preserve">
    <value>Add '{1}' as suffix</value>
  </data>
  <data name="MiKo_1044_Title" xml:space="preserve">
    <value>Commands should be suffixed with 'Command'</value>
  </data>
  <data name="MiKo_1045_CodeFixTitle" xml:space="preserve">
    <value>Remove 'Command' suffix</value>
  </data>
  <data name="MiKo_1045_Description" xml:space="preserve">
    <value>To simplify maintenance, drop the 'Command' suffix since the method is already invoked as a command. Keeps things clean and clear.</value>
  </data>
  <data name="MiKo_1045_MessageFormat" xml:space="preserve">
    <value>Name it '{1}'</value>
  </data>
  <data name="MiKo_1045_Title" xml:space="preserve">
    <value>Methods that are invoked by commands should not be suffixed with 'Command'</value>
  </data>
  <data name="MiKo_1046_CodeFixTitle" xml:space="preserve">
    <value>Append 'Async' suffix</value>
  </data>
  <data name="MiKo_1046_Description" xml:space="preserve">
    <value>To make maintenance easier, methods using the Task-based Asynchronous Pattern (TAP) should end with the suffix 'Async.' This helps clearly identify them as asynchronous methods.</value>
  </data>
  <data name="MiKo_1046_HelpLinkUri" xml:space="preserve">
    <value>https://learn.microsoft.com/en-us/dotnet/standard/asynchronous-programming-patterns/task-based-asynchronous-pattern-tap</value>
  </data>
  <data name="MiKo_1046_MessageFormat" xml:space="preserve">
    <value>Name it '{1}'</value>
  </data>
  <data name="MiKo_1046_Title" xml:space="preserve">
    <value>Asynchronous methods should follow the Task-based Asynchronous Pattern (TAP)</value>
  </data>
  <data name="MiKo_1047_CodeFixTitle" xml:space="preserve">
    <value>Remove 'Async' suffix</value>
  </data>
  <data name="MiKo_1047_Description" xml:space="preserve">
    <value>To simplify maintenance, do not add the 'Async' suffix to methods that do not follow the Task-based Asynchronous Pattern (TAP). Using 'Async' implies they do follow the pattern, which would be misleading.</value>
  </data>
  <data name="MiKo_1047_HelpLinkUri" xml:space="preserve">
    <value>https://learn.microsoft.com/en-us/dotnet/standard/asynchronous-programming-patterns/task-based-asynchronous-pattern-tap</value>
  </data>
  <data name="MiKo_1047_MessageFormat" xml:space="preserve">
    <value>Name it '{1}'</value>
  </data>
  <data name="MiKo_1047_Title" xml:space="preserve">
    <value>Methods not following the Task-based Asynchronous Pattern (TAP) should not lie about being asynchronous</value>
  </data>
  <data name="MiKo_1048_CodeFixTitle" xml:space="preserve">
    <value>Append 'Converter' suffix</value>
  </data>
  <data name="MiKo_1048_Description" xml:space="preserve">
    <value>To simplify maintenance, all class names for value converters should end with the suffix 'Converter.' This consistency helps quickly identify their role and purpose.</value>
  </data>
  <data name="MiKo_1048_MessageFormat" xml:space="preserve">
    <value>End name with '{1}'</value>
  </data>
  <data name="MiKo_1048_Title" xml:space="preserve">
    <value>Classes that are value converters should end with a specific suffix</value>
  </data>
  <data name="MiKo_1049_CodeFixTitle" xml:space="preserve">
    <value>Replace requirement term</value>
  </data>
  <data name="MiKo_1049_Description" xml:space="preserve">
    <value>Using terms like 'Must', 'Need', 'Shall', 'Should', 'Will', or 'Would' in names is not clear enough. Instead, go for positive verbs or adjectives like 'Is', 'Has', or 'Can.' These make the names more explicit and easier to understand.</value>
  </data>
  <data name="MiKo_1049_MessageFormat" xml:space="preserve">
    <value>Do not use '{1}' in name</value>
  </data>
  <data name="MiKo_1049_Title" xml:space="preserve">
    <value>Do not use requirement terms such as 'Shall', 'Should', 'Must' or 'Need' for names</value>
  </data>
  <data name="MiKo_1050_CodeFixTitle" xml:space="preserve">
    <value>Rename return value</value>
  </data>
  <data name="MiKo_1050_Description" xml:space="preserve">
    <value>Return variables should clearly describe the data they hold, not their technical aspect.
So, use meaningful names instead of vague ones like 'ret', 'retVal', or 'returnValue'. It makes the code more readable and understandable.</value>
  </data>
  <data name="MiKo_1050_MessageFormat" xml:space="preserve">
    <value>Use a more descriptive name than '{1}'</value>
  </data>
  <data name="MiKo_1050_Title" xml:space="preserve">
    <value>Return values should have descriptive names</value>
  </data>
  <data name="MiKo_1051_CodeFixTitle" xml:space="preserve">
    <value>Name it 'callback'</value>
  </data>
  <data name="MiKo_1051_Description" xml:space="preserve">
    <value>Using the delegate type as a suffix for parameter names is redundant and unhelpful. Instead, use descriptive names like 'callback', 'filter', or 'map' to provide clearer context.</value>
  </data>
  <data name="MiKo_1051_MessageFormat" xml:space="preserve">
    <value>Use a better matching name instead</value>
  </data>
  <data name="MiKo_1051_Title" xml:space="preserve">
    <value>Do not suffix parameters with delegate types</value>
  </data>
  <data name="MiKo_1052_CodeFixTitle" xml:space="preserve">
    <value>Name it 'callback'</value>
  </data>
  <data name="MiKo_1052_Description" xml:space="preserve">
    <value>Using the delegate type as a suffix for variable names is redundant and unhelpful. Instead, use descriptive names like 'callback', 'filter', or 'map' to provide clearer context.</value>
  </data>
  <data name="MiKo_1052_MessageFormat" xml:space="preserve">
    <value>Use a better matching name instead</value>
  </data>
  <data name="MiKo_1052_Title" xml:space="preserve">
    <value>Do not suffix variables with delegate types</value>
  </data>
  <data name="MiKo_1053_CodeFixTitle" xml:space="preserve">
    <value>Rename delegate field</value>
  </data>
  <data name="MiKo_1053_Description" xml:space="preserve">
    <value>Using the delegate type as a suffix for field names is redundant and unhelpful. Instead, use descriptive names like 'callback', 'filter', or 'map' to provide clearer context.</value>
  </data>
  <data name="MiKo_1053_MessageFormat" xml:space="preserve">
    <value>Use a better matching name instead</value>
  </data>
  <data name="MiKo_1053_Title" xml:space="preserve">
    <value>Do not suffix fields with delegate types</value>
  </data>
  <data name="MiKo_1054_CodeFixTitle" xml:space="preserve">
    <value>Remove 'Utility' marker suffix</value>
  </data>
  <data name="MiKo_1054_Description" xml:space="preserve">
    <value>Names like 'helper' or 'utility' are too vague and do not follow the Single Responsibility Principle (SRP). These types often end up having too broad a scope and do not clearly define what they do.
Instead, use specific names that describe their exact purpose, making the code easier to understand and maintain.</value>
  </data>
  <data name="MiKo_1054_MessageFormat" xml:space="preserve">
    <value>Remove '{1}' from name</value>
  </data>
  <data name="MiKo_1054_Title" xml:space="preserve">
    <value>Do not name types 'Helper' or 'Utility'</value>
  </data>
  <data name="MiKo_1055_CodeFixTitle" xml:space="preserve">
    <value>Rename dependency property</value>
  </data>
  <data name="MiKo_1055_Description" xml:space="preserve">
    <value>To show that fields are containers for specific dependency properties, add the suffix 'Property' to their names. This aligns with the naming conventions in the .NET Framework.</value>
  </data>
  <data name="MiKo_1055_HelpLinkUri" xml:space="preserve">
    <value>https://learn.microsoft.com/en-us/dotnet/framework/wpf/advanced/how-to-implement-a-dependency-property</value>
  </data>
  <data name="MiKo_1055_MessageFormat" xml:space="preserve">
    <value>Name it '{1}' instead</value>
  </data>
  <data name="MiKo_1055_Title" xml:space="preserve">
    <value>Dependency properties should be suffixed with 'Property' (as in the .NET Framework)</value>
  </data>
  <data name="MiKo_1056_Description" xml:space="preserve">
    <value>To show that fields are containers for specific dependency properties, they should be prefixed with the property name. This aligns with the naming conventions in the .NET Framework.</value>
  </data>
  <data name="MiKo_1056_HelpLinkUri" xml:space="preserve">
    <value>https://learn.microsoft.com/en-us/dotnet/framework/wpf/advanced/how-to-implement-a-dependency-property</value>
  </data>
  <data name="MiKo_1056_MessageFormat" xml:space="preserve">
    <value>Name it {1} instead</value>
  </data>
  <data name="MiKo_1056_Title" xml:space="preserve">
    <value>Dependency properties should be prefixed with property names (as in the .NET Framework)</value>
  </data>
  <data name="MiKo_1057_CodeFixTitle" xml:space="preserve">
    <value>Rename dependency property key</value>
  </data>
  <data name="MiKo_1057_Description" xml:space="preserve">
    <value>To show that fields are keys for specific dependency properties, add the suffix 'Key' to their names. This aligns with the naming conventions in the .NET Framework.</value>
  </data>
  <data name="MiKo_1057_HelpLinkUri" xml:space="preserve">
    <value>https://learn.microsoft.com/en-us/dotnet/api/system.windows.dependencypropertykey</value>
  </data>
  <data name="MiKo_1057_MessageFormat" xml:space="preserve">
    <value>Name it '{1}' instead</value>
  </data>
  <data name="MiKo_1057_Title" xml:space="preserve">
    <value>Dependency property keys should be suffixed with 'Key' (as in the .NET Framework)</value>
  </data>
  <data name="MiKo_1058_Description" xml:space="preserve">
    <value>To show that fields are keys for specific dependency properties, they should be prefixed with the property name. This aligns with the naming conventions in the .NET Framework.</value>
  </data>
  <data name="MiKo_1058_HelpLinkUri" xml:space="preserve">
    <value>https://learn.microsoft.com/en-us/dotnet/api/system.windows.dependencypropertykey</value>
  </data>
  <data name="MiKo_1058_MessageFormat" xml:space="preserve">
    <value>Name it {1} instead</value>
  </data>
  <data name="MiKo_1058_Title" xml:space="preserve">
    <value>Dependency property keys should be prefixed with property names (as in the .NET Framework)</value>
  </data>
  <data name="MiKo_1059_CodeFixTitle" xml:space="preserve">
    <value>Remove 'Impl' marker suffix</value>
  </data>
  <data name="MiKo_1059_Description" xml:space="preserve">
    <value>Using 'Impl' or 'Implementation' in type names is unnecessary and unhelpful. It's better to name types directly after the interface they implement, without adding an 'Impl' marker. This keeps names clear and concise.</value>
  </data>
  <data name="MiKo_1059_MessageFormat" xml:space="preserve">
    <value>Remove '{1}' from name</value>
  </data>
  <data name="MiKo_1059_Title" xml:space="preserve">
    <value>Do not name types 'Impl' or 'Implementation'</value>
  </data>
  <data name="MiKo_1060_CodeFixTitle" xml:space="preserve">
    <value>Change to 'NotFound'</value>
  </data>
  <data name="MiKo_1060_Description" xml:space="preserve">
    <value>When developers need to indicate that an entity was not found, they might have a repository method like 'GetXyz' that returns an error code (e.g., null) or throws an exception if 'Xyz' does not exist.
Naming the exception 'GetXyzFailedException' is unclear because it does not specify the reason for the failure. A better name would be 'XyzNotFoundException,' indicating that 'Xyz' was not found.

Similarly, using 'XyzMissingException' is also misleading. 'Missing' implies it should be there but is not, whereas 'not found' simply states it does not exist. Hence, 'XyzNotFoundException' is a clearer and more precise choice.</value>
  </data>
  <data name="MiKo_1060_MessageFormat" xml:space="preserve">
    <value>Consider to name it '{1}' instead</value>
  </data>
  <data name="MiKo_1060_Title" xml:space="preserve">
    <value>Use '&lt;Entity&gt;NotFound' instead of 'Get&lt;Entity&gt;Failed' or '&lt;Entity&gt;Missing'</value>
  </data>
  <data name="MiKo_1061_CodeFixTitle" xml:space="preserve">
    <value>Rename out parameter</value>
  </data>
  <data name="MiKo_1061_Description" xml:space="preserve">
    <value>When a 'TryXyz' method includes an [out] parameter, name it specifically, as it's the actual result of the method. The return value only indicates success or failure:
- For a 'Try' method, name the [out] parameter 'result'.
- For a 'TryGet' method, name the [out] parameter based on the method's name, dropping the 'TryGet' prefix.

For example, in the 'TryGetMyValue' method, the parameter should be named 'myValue'. This keeps names precise and clear.</value>
  </data>
  <data name="MiKo_1061_MessageFormat" xml:space="preserve">
    <value>Name it '{1}'</value>
  </data>
  <data name="MiKo_1061_Title" xml:space="preserve">
    <value>The name of 'Try' method's [out] parameter should be specific</value>
  </data>
  <data name="MiKo_1062_Description" xml:space="preserve">
    <value>Detection methods, properties, or fields like 'Can', 'Has', or 'Contains' should be concise, like 'HasConnection' or 'ContainsKey'.
If their names are longer, it likely means they are misplaced and violate the Single Responsibility Principle (SRP).</value>
  </data>
  <data name="MiKo_1062_MessageFormat" xml:space="preserve">
    <value>Avoid name with more than {1} words</value>
  </data>
  <data name="MiKo_1062_Title" xml:space="preserve">
    <value>'Can/Has/Contains' methods, properties or fields shall consist of only a few words</value>
  </data>
  <data name="MiKo_1063_CodeFixTitle" xml:space="preserve">
    <value>Replace abbreviations in name</value>
  </data>
  <data name="MiKo_1063_Description" xml:space="preserve">
    <value>Using abbreviations in names is bad practice. It makes it difficult for new developers to understand the code. Plus, abbreviations distract readers, as they have to constantly translate their meaning.</value>
  </data>
  <data name="MiKo_1063_MessageFormat" xml:space="preserve">
    <value>Use '{2}' instead of abbreviation '{1}'</value>
  </data>
  <data name="MiKo_1063_Title" xml:space="preserve">
    <value>Do not use abbreviations in names</value>
  </data>
  <data name="MiKo_1064_Description" xml:space="preserve">
    <value>To make maintenance easier, base parameter names on their meaning, not their type. This keeps the code more intuitive and easier to understand.</value>
  </data>
  <data name="MiKo_1064_MessageFormat" xml:space="preserve">
    <value>Name parameter based on its meaning instead of its type</value>
  </data>
  <data name="MiKo_1064_Title" xml:space="preserve">
    <value>Parameter names reflect their meaning and not their type</value>
  </data>
  <data name="MiKo_1065_CodeFixTitle" xml:space="preserve">
    <value>Rename operator parameter</value>
  </data>
  <data name="MiKo_1065_Description" xml:space="preserve">
    <value>According to the .NET Framework Design Guidelines for operator overloads, parameters should have standard names if they do not have specific meanings.
- For binary operator overloads, use 'left' and 'right'.
- For unary operator overloads, use 'value'.

This ensures clarity and consistency in your code.</value>
  </data>
  <data name="MiKo_1065_HelpLinkUri" xml:space="preserve">
    <value>https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/naming-parameters</value>
  </data>
  <data name="MiKo_1065_MessageFormat" xml:space="preserve">
    <value>Name it '{1}'</value>
  </data>
  <data name="MiKo_1065_Title" xml:space="preserve">
    <value>Operator parameters should be named according the .NET Framework Design Guidelines for operator overloads</value>
  </data>
  <data name="MiKo_1066_CodeFixTitle" xml:space="preserve">
    <value>Rename parameter to match its property</value>
  </data>
  <data name="MiKo_1066_Description" xml:space="preserve">
    <value>To ease usage of a class, constructor parameters that get assigned directly to properties should have the same name as the property. So a client of the class easily knows what the parameter is used for.</value>
  </data>
  <data name="MiKo_1066_MessageFormat" xml:space="preserve">
    <value>Name parameter according to the assigned property</value>
  </data>
  <data name="MiKo_1066_Title" xml:space="preserve">
    <value>Constructor parameters that are assigned to a property should be named after the property</value>
  </data>
  <data name="MiKo_1067_CodeFixTitle" xml:space="preserve">
    <value>Remove 'Perform' from name</value>
  </data>
  <data name="MiKo_1067_Description" xml:space="preserve">
    <value>The purpose of methods is to execute code, so it's useless and repetitive to have 'Perform' in their names.</value>
  </data>
  <data name="MiKo_1067_MessageFormat" xml:space="preserve">
    <value>Remove 'Perform' from name</value>
  </data>
  <data name="MiKo_1067_Title" xml:space="preserve">
    <value>Methods should not contain 'Perform' in their names</value>
  </data>
  <data name="MiKo_1068_Description" xml:space="preserve">
    <value>Workflows, being high-level constructs within the business layer, should have methods named 'CanRun' or 'Run', much like commands that use 'CanExecute' and 'Execute'. This naming convention keeps things consistent and clear.</value>
  </data>
  <data name="MiKo_1068_MessageFormat" xml:space="preserve">
    <value>Name it '{1}'</value>
  </data>
  <data name="MiKo_1068_Title" xml:space="preserve">
    <value>Workflow methods should be named 'CanRun' or 'Run'</value>
  </data>
  <data name="MiKo_1069_Description" xml:space="preserve">
    <value>To ease maintenance, property names should be based on the property's meaning rather than its type.</value>
  </data>
  <data name="MiKo_1069_MessageFormat" xml:space="preserve">
    <value>Name property based on its meaning instead of its type</value>
  </data>
  <data name="MiKo_1069_Title" xml:space="preserve">
    <value>Property names reflect their meaning and not their type</value>
  </data>
  <data name="MiKo_1070_CodeFixTitle" xml:space="preserve">
    <value>Rename variable into plural</value>
  </data>
  <data name="MiKo_1070_Description" xml:space="preserve">
    <value>Local variables for collections (like those implementing 'IEnumerable') should have plural names that describe the contents, not the collection itself.
For example, instead of naming a variable 'userCollection', name it 'users' to clearly indicate it holds multiple user entities.</value>
  </data>
  <data name="MiKo_1070_MessageFormat" xml:space="preserve">
    <value>Name it '{1}'</value>
  </data>
  <data name="MiKo_1070_Title" xml:space="preserve">
    <value>Local collection variables shall use plural name</value>
  </data>
  <data name="MiKo_1071_Description" xml:space="preserve">
    <value>Boolean variables define some state. So they should be named as statements and not as questions.
That easies reading, as most likely, boolean variables are used in if/else or switch statements.

Example:
   'isDeviceOnline' is a question.
   'deviceIsOnline' instead is a statement.

   'if (isDeviceOnline) DoSomething();' is harder to read
   'if (deviceIsOnline) DoSomething();' is more fluent to read.</value>
  </data>
  <data name="MiKo_1071_MessageFormat" xml:space="preserve">
    <value>Formulate question as statement</value>
  </data>
  <data name="MiKo_1071_Title" xml:space="preserve">
    <value>Local boolean variables should be named as statements and not as questions</value>
  </data>
  <data name="MiKo_1072_Description" xml:space="preserve">
    <value>Boolean properties or methods define some state. So they should be named as statements and not as questions.
That easies reading, as most likely, boolean properties or methods are used in if/else or switch statements.

Example:
   'IsDeviceOnline' is a question.
   'DeviceIsOnline' instead is a statement.

   'if (IsDeviceOnline) DoSomething();' is harder to read
   'if (DeviceIsOnline) DoSomething();' is more fluent to read.</value>
  </data>
  <data name="MiKo_1072_MessageFormat" xml:space="preserve">
    <value>Formulate question as statement</value>
  </data>
  <data name="MiKo_1072_Title" xml:space="preserve">
    <value>Boolean properties or methods should be named as statements and not as questions</value>
  </data>
  <data name="MiKo_1073_Description" xml:space="preserve">
    <value>Boolean fields represent a state and should be named as statements, not questions.
This makes the code easier to read, especially in if/else or switch statements.

Example:
   'IsDeviceOnline' is a question.
   'DeviceIsOnline' instead is a statement.

   'if (IsDeviceOnline) DoSomething();' is harder to read
   'if (DeviceIsOnline) DoSomething();' is more fluent to read.</value>
  </data>
  <data name="MiKo_1073_MessageFormat" xml:space="preserve">
    <value>Formulate question as statement</value>
  </data>
  <data name="MiKo_1073_Title" xml:space="preserve">
    <value>Boolean fields should be named as statements and not as questions</value>
  </data>
  <data name="MiKo_1074_Description" xml:space="preserve">
    <value>If an object is used for synchronizing threads with lock statements, add the suffix 'Lock' to its name. This makes it clear that the object is used as a synchronization mechanism.</value>
  </data>
  <data name="MiKo_1074_MessageFormat" xml:space="preserve">
    <value>Suffix field with 'Lock' because it is used as lock object</value>
  </data>
  <data name="MiKo_1074_Title" xml:space="preserve">
    <value>Objects used to lock on should be suffixed with 'Lock'</value>
  </data>
  <data name="MiKo_1075_CodeFixTitle" xml:space="preserve">
    <value>Remove suffix 'EventArgs'</value>
  </data>
  <data name="MiKo_1075_Description" xml:space="preserve">
    <value>Event argument types should inherit from 'System.EventArgs' and have names ending with 'EventArgs'. If a type ends with 'EventArgs' but does not follow this pattern, it's misleading and should not use 'EventArgs' in its name.</value>
  </data>
  <data name="MiKo_1075_MessageFormat" xml:space="preserve">
    <value>Name it '{1}' instead</value>
  </data>
  <data name="MiKo_1075_Title" xml:space="preserve">
    <value>Non-'System.EventArgs' types should not be suffixed with 'EventArgs'</value>
  </data>
  <data name="MiKo_1076_CodeFixTitle" xml:space="preserve">
    <value>Change suffix to 'Event'</value>
  </data>
  <data name="MiKo_1076_Description" xml:space="preserve">
    <value>Prism event types follow the pattern defined by Prism and end their names with 'Event'.</value>
  </data>
  <data name="MiKo_1076_MessageFormat" xml:space="preserve">
    <value>Name it '{1}' instead</value>
  </data>
  <data name="MiKo_1076_Title" xml:space="preserve">
    <value>Prism event types should be suffixed with 'Event'</value>
  </data>
  <data name="MiKo_1077_CodeFixTitle" xml:space="preserve">
    <value>Remove 'Enum' suffix</value>
  </data>
  <data name="MiKo_1077_Description" xml:space="preserve">
    <value>Indicating that an enum member is an enum member by using 'Enum' as its suffix does not make sense.</value>
  </data>
  <data name="MiKo_1077_MessageFormat" xml:space="preserve">
    <value>Name it '{0}'</value>
  </data>
  <data name="MiKo_1077_Title" xml:space="preserve">
    <value>Enum members should not be suffixed with 'Enum'</value>
  </data>
  <data name="MiKo_1078_CodeFixTitle" xml:space="preserve">
    <value>Rename builder method</value>
  </data>
  <data name="MiKo_1078_Description" xml:space="preserve">
    <value>The method belongs to a builder and therefore its name should be started with 'Build'.</value>
  </data>
  <data name="MiKo_1078_MessageFormat" xml:space="preserve">
    <value>Start name with 'Build'</value>
  </data>
  <data name="MiKo_1078_Title" xml:space="preserve">
    <value>Builder method names should start with 'Build'</value>
  </data>
  <data name="MiKo_1079_CodeFixTitle" xml:space="preserve">
    <value>Remove suffix 'Repository'</value>
  </data>
  <data name="MiKo_1079_Description" xml:space="preserve">
    <value>DDD defines repository classes. However, those classes should not be suffixed with 'Repository' as everybody understands different things as a repository.</value>
  </data>
  <data name="MiKo_1079_MessageFormat" xml:space="preserve">
    <value>Remove suffix 'Repository'</value>
  </data>
  <data name="MiKo_1079_Title" xml:space="preserve">
    <value>Repositories should not be suffixed with 'Repository'</value>
  </data>
  <data name="MiKo_1080_Description" xml:space="preserve">
    <value>It is much easier to read a number inside a name if it is written as number and not its spelling (e.g. 'issue42' in contrast to 'issueFortyTwo').</value>
  </data>
  <data name="MiKo_1080_MessageFormat" xml:space="preserve">
    <value>Use number instead of spelling</value>
  </data>
  <data name="MiKo_1080_Title" xml:space="preserve">
    <value>Names should contain numbers instead of their spellings</value>
  </data>
  <data name="MiKo_1081_CodeFixTitle" xml:space="preserve">
    <value>Remove number</value>
  </data>
  <data name="MiKo_1081_Description" xml:space="preserve">
    <value>Using numbers at the end of method names makes it confusing for users to understand which method to use or if they need to use them together. Instead, give methods clear, descriptive names.</value>
  </data>
  <data name="MiKo_1081_MessageFormat" xml:space="preserve">
    <value>Do not use a number as suffix</value>
  </data>
  <data name="MiKo_1081_Title" xml:space="preserve">
    <value>Methods should not be suffixed with a number</value>
  </data>
  <data name="MiKo_1082_CodeFixTitle" xml:space="preserve">
    <value>Remove number</value>
  </data>
  <data name="MiKo_1082_Description" xml:space="preserve">
    <value>Adding numbers to the end of property names (especially if the returned type also has a number) makes them hard to read. Usually, the number can just be left out, making the names clearer and to the point.</value>
  </data>
  <data name="MiKo_1082_MessageFormat" xml:space="preserve">
    <value>Do not use a number as suffix</value>
  </data>
  <data name="MiKo_1082_Title" xml:space="preserve">
    <value>Properties should not be suffixed with a number if their types have number suffixes</value>
  </data>
  <data name="MiKo_1083_CodeFixTitle" xml:space="preserve">
    <value>Remove number</value>
  </data>
  <data name="MiKo_1083_Description" xml:space="preserve">
    <value>Adding numbers to the end of fiekd names (especially if the type also has a number) makes them hard to read. Usually, the number can just be left out, making the names clearer and to the point.</value>
  </data>
  <data name="MiKo_1083_MessageFormat" xml:space="preserve">
    <value>Do not use a number as suffix</value>
  </data>
  <data name="MiKo_1083_Title" xml:space="preserve">
    <value>Fields should not be suffixed with a number if their types have number suffixes</value>
  </data>
  <data name="MiKo_1084_CodeFixTitle" xml:space="preserve">
    <value>Remove number</value>
  </data>
  <data name="MiKo_1084_Description" xml:space="preserve">
    <value>Adding numbers to the end of variable names (especially if the type also has a number) makes them hard to read. Usually, the number can just be left out, making the names clearer and to the point.</value>
  </data>
  <data name="MiKo_1084_MessageFormat" xml:space="preserve">
    <value>Do not use a number as suffix</value>
  </data>
  <data name="MiKo_1084_Title" xml:space="preserve">
    <value>Variables should not be suffixed with a number if their types have number suffixes</value>
  </data>
  <data name="MiKo_1085_CodeFixTitle" xml:space="preserve">
    <value>Remove number</value>
  </data>
  <data name="MiKo_1085_Description" xml:space="preserve">
    <value>Using numbers in parameter names provides no benefit. Instead, give parameters clear and descriptive names to make them easier to understand and use.</value>
  </data>
  <data name="MiKo_1085_MessageFormat" xml:space="preserve">
    <value>Do not use a number as suffix</value>
  </data>
  <data name="MiKo_1085_Title" xml:space="preserve">
    <value>Parameters should not be suffixed with a number</value>
  </data>
  <data name="MiKo_1086_Description" xml:space="preserve">
    <value>Using numbers in method names such 'Send2You' or 'Do4You' is slang and should be avoided. Instead, the correct words 'To' or 'For' should be used.</value>
  </data>
  <data name="MiKo_1086_MessageFormat" xml:space="preserve">
    <value>Do not use a number as slang</value>
  </data>
  <data name="MiKo_1086_Title" xml:space="preserve">
    <value>Methods should not be named using numbers as slang</value>
  </data>
  <data name="MiKo_1087_CodeFixTitle" xml:space="preserve">
    <value>Rename constructor parameter after counterpart in base class</value>
  </data>
  <data name="MiKo_1087_Description" xml:space="preserve">
    <value>To ease usage and avoid misunderstandings, the names of constructor parameters should be identical to the names of constructors of the base class.</value>
  </data>
  <data name="MiKo_1087_MessageFormat" xml:space="preserve">
    <value>Name constructor parameter '{1}'</value>
  </data>
  <data name="MiKo_1087_Title" xml:space="preserve">
    <value>Name constructor parameters after their counterparts in the base class</value>
  </data>
  <data name="MiKo_1088_Description" xml:space="preserve">
    <value>To indicate that something is a singleton, the specific property or field should be named 'Instance' as convention. That makes it easier to spot.</value>
  </data>
  <data name="MiKo_1088_MessageFormat" xml:space="preserve">
    <value>Name it 'Instance'</value>
  </data>
  <data name="MiKo_1088_Title" xml:space="preserve">
    <value>Singleton instances should be named 'Instance'</value>
  </data>
  <data name="MiKo_1089_CodeFixTitle" xml:space="preserve">
    <value>Rename method and remove 'Get' prefix</value>
  </data>
  <data name="MiKo_1089_Description" xml:space="preserve">
    <value>To ease reading, methods should not be prefixed with 'Get', especially when they are part of repositories.
For example, 'GetUsersByCity' should be renamed to 'UsersWithCity', as the code where it is used is easier to read that way.</value>
  </data>
  <data name="MiKo_1089_MessageFormat" xml:space="preserve">
    <value>Do not prefix with 'Get'</value>
  </data>
  <data name="MiKo_1089_Title" xml:space="preserve">
    <value>Methods should not be prefixed with 'Get'</value>
  </data>
  <data name="MiKo_1090_CodeFixTitle" xml:space="preserve">
    <value>Rename parameter</value>
  </data>
  <data name="MiKo_1090_Description" xml:space="preserve">
    <value>Instead of adding a type suffix to a parameter name (like 'xyzComparer'), just name it after its function (like 'comparer'). The type already tells you what it is, so adding that information again is redundant.</value>
  </data>
  <data name="MiKo_1090_MessageFormat" xml:space="preserve">
    <value>Name it '{1}'</value>
  </data>
  <data name="MiKo_1090_Title" xml:space="preserve">
    <value>Parameters should not be suffixed with specific types</value>
  </data>
  <data name="MiKo_1091_CodeFixTitle" xml:space="preserve">
    <value>Remove variable suffix</value>
  </data>
  <data name="MiKo_1091_Description" xml:space="preserve">
    <value>Instead of adding a type suffix to a variable name (like 'xyzComparer'), just name it after its function (like 'comparer'). The type already tells you what it is, so adding that information again is redundant.</value>
  </data>
  <data name="MiKo_1091_MessageFormat" xml:space="preserve">
    <value>Name it '{1}'</value>
  </data>
  <data name="MiKo_1091_Title" xml:space="preserve">
    <value>Variables should not be suffixed with specific types</value>
  </data>
  <data name="MiKo_1092_CodeFixTitle" xml:space="preserve">
    <value>Remove suffix</value>
  </data>
  <data name="MiKo_1092_Description" xml:space="preserve">
    <value>Instead of suffixing an 'ability' type with redundant information (such as 'ComparableItem'), the redundant information should be left out of the name of the type (such as 'Comparable').</value>
  </data>
  <data name="MiKo_1092_MessageFormat" xml:space="preserve">
    <value>Name it '{1}'</value>
  </data>
  <data name="MiKo_1092_Title" xml:space="preserve">
    <value>'Ability' Types should not be suffixed with redundant information</value>
  </data>
  <data name="MiKo_1093_CodeFixTitle" xml:space="preserve">
    <value>Remove suffix 'Object' or 'Struct'</value>
  </data>
  <data name="MiKo_1093_Description" xml:space="preserve">
    <value>Avoid using 'Object' or 'Struct' as suffixes in identifiers. Often, better names can be chosen that don't include these terms, like 'Identifier' instead of 'IdentificationObject'.</value>
  </data>
  <data name="MiKo_1093_MessageFormat" xml:space="preserve">
    <value>Do not use suffix '{1}'</value>
  </data>
  <data name="MiKo_1093_Title" xml:space="preserve">
    <value>Do not use the suffix 'Object' or 'Struct'</value>
  </data>
  <data name="MiKo_1094_Description" xml:space="preserve">
    <value>Types should have active suffixes that clearly identify them as types. Avoid using passive suffixes like 'Management' or 'Handling' and opt for more active terms like 'Manager' or 'Handler'.
Keep the passive suffixes for namespaces.</value>
  </data>
  <data name="MiKo_1094_MessageFormat" xml:space="preserve">
    <value>Name it '{1}' instead</value>
  </data>
  <data name="MiKo_1094_Title" xml:space="preserve">
    <value>Do not suffix types with passive namespace names</value>
  </data>
  <data name="MiKo_1095_Description" xml:space="preserve">
    <value>While 'Delete' and 'Remove' seem similar, there's a key difference:
- 'Delete' means to erase something, making it nonexistent and nonrecoverable.
- 'Remove' means to take something away and set it aside, but it still exists.

So, do not mix these terms in documentation and naming.
For instance, do not name a method 'RemoveUser' if the documentation states it 'Deletes the user from the database.' .</value>
  </data>
  <data name="MiKo_1095_MessageFormat" xml:space="preserve">
    <value>Choose wisely between 'Delete' and 'Remove'</value>
  </data>
  <data name="MiKo_1095_Title" xml:space="preserve">
    <value>Do not use 'Delete' and 'Remove' both in names and documentation</value>
  </data>
  <data name="MiKo_1096_Description" xml:space="preserve">
    <value>To be more explicit and direct, names should use 'Failed' instead of 'NotSuccesful'.</value>
  </data>
  <data name="MiKo_1096_MessageFormat" xml:space="preserve">
    <value>Use 'Failed' instead of 'NotSuccessful'</value>
  </data>
  <data name="MiKo_1096_Title" xml:space="preserve">
    <value>Names should use 'Failed' instead of 'NotSuccessful'</value>
  </data>
  <data name="MiKo_1097_CodeFixTitle" xml:space="preserve">
    <value>Remove field prefix</value>
  </data>
  <data name="MiKo_1097_Description" xml:space="preserve">
    <value>Parameters should not use the same prefixes as fields because that would be make them difficult to distinguish from fields. Reviewers probably are not aware of such and might come to wrong conclusions when reading the code.</value>
  </data>
  <data name="MiKo_1097_MessageFormat" xml:space="preserve">
    <value>Do not use field prefix '{1}'</value>
  </data>
  <data name="MiKo_1097_Title" xml:space="preserve">
    <value>Parameter names should not follow the naming scheme for fields</value>
  </data>
  <data name="MiKo_1098_Description" xml:space="preserve">
    <value>When a type implements a business interface, its name should reflect that. This makes it easier for developers to identify and use the type. For instance, if a type implements the 'IPart' interface, it should be named something like 'XyzPart'.</value>
  </data>
  <data name="MiKo_1098_MessageFormat" xml:space="preserve">
    <value>Suffix type name according to one of the following interfaces: {1}</value>
  </data>
  <data name="MiKo_1098_Title" xml:space="preserve">
    <value>Type names should reflect the business interface(s) they implement</value>
  </data>
  <data name="MiKo_1099_CodeFixTitle" xml:space="preserve">
    <value>Rename parameter to match overload</value>
  </data>
  <data name="MiKo_1099_Description" xml:space="preserve">
    <value>Parameters on method overloads should have the same name. The reason is that most likely these parameters represent the same inputs accross the different overloads which should be reflected in their names.</value>
  </data>
  <data name="MiKo_1099_MessageFormat" xml:space="preserve">
    <value>Name it '{1}' to match overload</value>
  </data>
  <data name="MiKo_1099_Title" xml:space="preserve">
    <value>Matching parameters on method overloads should have identical names</value>
  </data>
  <data name="MiKo_1100_Description" xml:space="preserve">
    <value>A unit test class should clearly indicate the type it tests by naming it with the type's name as a prefix, followed by 'Tests'. For example, if testing 'MyXyzClass', the test class should be named 'MyXyzClassTests'. This makes it easy to identify what is being tested.</value>
  </data>
  <data name="MiKo_1100_MessageFormat" xml:space="preserve">
    <value>Name it '{1}'</value>
  </data>
  <data name="MiKo_1100_Title" xml:space="preserve">
    <value>Test classes should start with the name of the type under test</value>
  </data>
  <data name="MiKo_1101_CodeFixTitle" xml:space="preserve">
    <value>Append 'Tests' suffix</value>
  </data>
  <data name="MiKo_1101_Description" xml:space="preserve">
    <value>A unit test class should use the suffix 'Tests' rather than 'Test', since it typically contains multiple tests.</value>
  </data>
  <data name="MiKo_1101_MessageFormat" xml:space="preserve">
    <value>Name it '{1}'</value>
  </data>
  <data name="MiKo_1101_Title" xml:space="preserve">
    <value>Test classes should end with 'Tests'</value>
  </data>
  <data name="MiKo_1102_CodeFixTitle" xml:space="preserve">
    <value>Remove test marker from name</value>
  </data>
  <data name="MiKo_1102_Description" xml:space="preserve">
    <value>Methods marked as unit tests should not need 'Test' in their name. It's redundant, as the unit test framework already indicates they are tests. Keep the names clear and descriptive without 'Test'.</value>
  </data>
  <data name="MiKo_1102_MessageFormat" xml:space="preserve">
    <value>Remove '{1}' from name</value>
  </data>
  <data name="MiKo_1102_Title" xml:space="preserve">
    <value>Test methods should not contain 'Test' in their names</value>
  </data>
  <data name="MiKo_1103_CodeFixTitle" xml:space="preserve">
    <value>Rename to 'PrepareTest'</value>
  </data>
  <data name="MiKo_1103_Description" xml:space="preserve">
    <value>A unit test initialization method should be named 'PrepareTest' to clearly indicate its purpose in preparing the test environment. This naming makes the code easy to read and understand.</value>
  </data>
  <data name="MiKo_1103_MessageFormat" xml:space="preserve">
    <value>Name it '{1}'</value>
  </data>
  <data name="MiKo_1103_Title" xml:space="preserve">
    <value>Test initialization methods should be named 'PrepareTest'</value>
  </data>
  <data name="MiKo_1104_CodeFixTitle" xml:space="preserve">
    <value>Rename to 'CleanupTest'</value>
  </data>
  <data name="MiKo_1104_Description" xml:space="preserve">
    <value>A unit test cleanup method should be named 'CleanupTest' to clearly indicate its purpose in tidying up the test environment after the test runs. This naming makes the code easy to read and understand.</value>
  </data>
  <data name="MiKo_1104_MessageFormat" xml:space="preserve">
    <value>Name it '{1}'</value>
  </data>
  <data name="MiKo_1104_Title" xml:space="preserve">
    <value>Test cleanup methods should be named 'CleanupTest'</value>
  </data>
  <data name="MiKo_1105_CodeFixTitle" xml:space="preserve">
    <value>Rename to 'PrepareTestEnvironment'</value>
  </data>
  <data name="MiKo_1105_Description" xml:space="preserve">
    <value>A one-time unit test initialization method should be named 'PrepareTestEnvironment' to clearly indicate its role in setting up the test environment just once before all tests run. This ensures clarity and consistency in the test setup process.</value>
  </data>
  <data name="MiKo_1105_MessageFormat" xml:space="preserve">
    <value>Name it '{1}'</value>
  </data>
  <data name="MiKo_1105_Title" xml:space="preserve">
    <value>One-time test initialization methods should be named 'PrepareTestEnvironment'</value>
  </data>
  <data name="MiKo_1106_CodeFixTitle" xml:space="preserve">
    <value>Rename to 'CleanupTestEnvironment'</value>
  </data>
  <data name="MiKo_1106_Description" xml:space="preserve">
    <value>A one-time unit test cleanup method should be named 'CleanupTestEnvironment' to clearly indicate its role in cleaning up the test environment after all tests have run. This helps maintain consistency and clarity in your test suite.</value>
  </data>
  <data name="MiKo_1106_MessageFormat" xml:space="preserve">
    <value>Name it '{1}'</value>
  </data>
  <data name="MiKo_1106_Title" xml:space="preserve">
    <value>One-time test cleanup methods should be named 'CleanupTestEnvironment'</value>
  </data>
  <data name="MiKo_1107_CodeFixTitle" xml:space="preserve">
    <value>Use underscores instead of Pascal-casing</value>
  </data>
  <data name="MiKo_1107_Description" xml:space="preserve">
    <value>To make maintenance easier, avoid using Pascal-casing for test method names. Instead, use underscores to separate the different words. This improves readability and makes the code easier to understand.</value>
  </data>
  <data name="MiKo_1107_MessageFormat" xml:space="preserve">
    <value>Use underscores instead of Pascal-casing</value>
  </data>
  <data name="MiKo_1107_Title" xml:space="preserve">
    <value>Test methods should not be in Pascal-casing</value>
  </data>
  <data name="MiKo_1108_CodeFixTitle" xml:space="preserve">
    <value>Remove Mock suffix</value>
  </data>
  <data name="MiKo_1108_Description" xml:space="preserve">
    <value>For easier maintenance, name variables, parameters, properties, and fields based on what they represent, not what they technically are.
Using names like 'Mock', 'Stub', 'Fake', or 'Shim' adds clutter and distracts developers from the actual purpose of the code.
Clear, meaningful names keep the focus on what the code does.</value>
  </data>
  <data name="MiKo_1108_MessageFormat" xml:space="preserve">
    <value>Do not name it 'Mock', 'Stub', 'Fake' or 'Shim'</value>
  </data>
  <data name="MiKo_1108_Title" xml:space="preserve">
    <value>Do not name variables, parameters, fields and properties 'Mock', 'Stub', 'Fake' or 'Shim'</value>
  </data>
  <data name="MiKo_1109_CodeFixTitle" xml:space="preserve">
    <value>Prefix with 'Testable' instead of suffix 'Ut'</value>
  </data>
  <data name="MiKo_1109_Description" xml:space="preserve">
    <value>Sometimes, types or their functionalities are not directly testable due to visibility issues. To bypass this, you can inherit from those types and use the inherited type for testing. Additional methods or properties can also be added to access the original, hidden ones.

These specially introduced types should have the same name as the original, prefixed with 'Testable' (instead of using the confusing 'Ut' suffix).
This approach is clearer and makes the test code more readable.</value>
  </data>
  <data name="MiKo_1109_MessageFormat" xml:space="preserve">
    <value>Name it '{1}'</value>
  </data>
  <data name="MiKo_1109_Title" xml:space="preserve">
    <value>Prefix testable types with 'Testable' instead of using the 'Ut' suffix</value>
  </data>
  <data name="MiKo_1110_CodeFixTitle" xml:space="preserve">
    <value>Append underscore</value>
  </data>
  <data name="MiKo_1110_Description" xml:space="preserve">
    <value>For easier maintenance, parameterized test methods should be clear and parameters should stand out. To achieve this, add an underscore before the parameters.
For example, 'Do_something_for_value_(42)' is easier to read than 'Do_something_for_value(42)' due to the extra space before the parenthesis. This makes the method more readable.</value>
  </data>
  <data name="MiKo_1110_MessageFormat" xml:space="preserve">
    <value>Suffix name with underscore</value>
  </data>
  <data name="MiKo_1110_Title" xml:space="preserve">
    <value>Test methods with parameters should be suffixed with underscore</value>
  </data>
  <data name="MiKo_1111_CodeFixTitle" xml:space="preserve">
    <value>Remove underscore</value>
  </data>
  <data name="MiKo_1111_Description" xml:space="preserve">
    <value>For easier maintenance, parameterless test methods should be clear and easy to read. Unlike parameterized methods, they should not have underscores before the parentheses.
For example, 'Do_something_for_value()' is more readable than 'Do_something_for_value_()'.</value>
  </data>
  <data name="MiKo_1111_MessageFormat" xml:space="preserve">
    <value>Do not suffix name with underscore</value>
  </data>
  <data name="MiKo_1111_Title" xml:space="preserve">
    <value>Test methods without parameters should not be suffixed with underscore</value>
  </data>
  <data name="MiKo_1112_CodeFixTitle" xml:space="preserve">
    <value>Remove 'arbitrary' from name</value>
  </data>
  <data name="MiKo_1112_Description" xml:space="preserve">
    <value>In tests, the term 'arbitrary' adds no real value to field, parameter, or variable names since test data is inherently arbitrary. Removing it keeps the names simpler and just as clear.</value>
  </data>
  <data name="MiKo_1112_MessageFormat" xml:space="preserve">
    <value>Remove 'arbitrary' from name</value>
  </data>
  <data name="MiKo_1112_Title" xml:space="preserve">
    <value>Do not name test data 'arbitrary'</value>
  </data>
  <data name="MiKo_1113_Description" xml:space="preserve">
    <value>The "Given... When... Then..." BDD style is meant for non-developer stakeholders. Since unit tests are for developers, this style can make them harder to read and understand. Therefore, avoid using BDD style in unit tests for better clarity.</value>
  </data>
  <data name="MiKo_1113_MessageFormat" xml:space="preserve">
    <value>Do not name BDD style</value>
  </data>
  <data name="MiKo_1113_Title" xml:space="preserve">
    <value>Test methods should not be named according BDD style</value>
  </data>
  <data name="MiKo_1114_Description" xml:space="preserve">
    <value>Test methods should be named based on the specific scenarios they test, rather than labeling them as 'happy path' or 'bad path'. This approach makes the purpose of each test clearer and more understandable.</value>
  </data>
  <data name="MiKo_1114_MessageFormat" xml:space="preserve">
    <value>Do not name '{0}' a happy or bad path</value>
  </data>
  <data name="MiKo_1114_Title" xml:space="preserve">
    <value>Test methods should not be named 'HappyPath' or 'BadPath'</value>
  </data>
  <data name="MiKo_1115_CodeFixTitle" xml:space="preserve">
    <value>Fix "Yoda-speak" method name</value>
  </data>
  <data name="MiKo_1115_Description" xml:space="preserve">
    <value>Test method names should be easy to read and describe the scenario fluently.
Avoid 'Yoda' style names like "Send_EMailAddressValid_SendsMail".
A clearer name would be "Send_sends_email_to_valid_address", which is easier to read and understand.</value>
  </data>
  <data name="MiKo_1115_MessageFormat" xml:space="preserve">
    <value>Do not use "Yoda-speak" for method names</value>
  </data>
  <data name="MiKo_1115_Title" xml:space="preserve">
    <value>Test methods should be named in a fluent way</value>
  </data>
  <data name="MiKo_1200_CodeFixTitle" xml:space="preserve">
    <value>Rename exception</value>
  </data>
  <data name="MiKo_1200_Description" xml:space="preserve">
    <value>To make maintenance easier, name exceptions consistently across all catch blocks. Use the same name each time to keep the code clear.</value>
  </data>
  <data name="MiKo_1200_MessageFormat" xml:space="preserve">
    <value>Name it '{1}'</value>
  </data>
  <data name="MiKo_1200_Title" xml:space="preserve">
    <value>Name exceptions in catch blocks consistently</value>
  </data>
  <data name="MiKo_1201_CodeFixTitle" xml:space="preserve">
    <value>Rename exception</value>
  </data>
  <data name="MiKo_1201_Description" xml:space="preserve">
    <value>To make maintenance easier, exceptions passed as parameters should always have the same name. This consistency helps keep the code clear.</value>
  </data>
  <data name="MiKo_1201_MessageFormat" xml:space="preserve">
    <value>Name it '{1}' or '{2}'</value>
  </data>
  <data name="MiKo_1201_Title" xml:space="preserve">
    <value>Name exceptions as parameters consistently</value>
  </data>
  <data name="MiKo_1300_CodeFixTitle" xml:space="preserve">
    <value>Name it '_'</value>
  </data>
  <data name="MiKo_1300_Description" xml:space="preserve">
    <value>To make maintenance easier and reduce visual clutter, consistently name unimportant lambda parameters as '_'. This helps keep the code clean and easy to read.</value>
  </data>
  <data name="MiKo_1300_MessageFormat" xml:space="preserve">
    <value>Name it '_' instead</value>
  </data>
  <data name="MiKo_1300_Title" xml:space="preserve">
    <value>Unimportant identifiers in lambda statements should be named '_'</value>
  </data>
  <data name="MiKo_1400_Description" xml:space="preserve">
    <value>Namespaces group functionalities, so their names should be plural. This makes it clear that they encompass multiple related functions or classes, enhancing readability and organization.</value>
  </data>
  <data name="MiKo_1400_HelpLinkUri" xml:space="preserve">
    <value>https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/names-of-namespaces</value>
  </data>
  <data name="MiKo_1400_MessageFormat" xml:space="preserve">
    <value>Use plural for namespace, such as '{1}'</value>
  </data>
  <data name="MiKo_1400_Title" xml:space="preserve">
    <value>Namespace names should be in plural</value>
  </data>
  <data name="MiKo_1401_Description" xml:space="preserve">
    <value>Avoid including language-specific terms like 'Interfaces', 'Exceptions', or 'Enums' in namespace names. Namespaces should focus on grouping related functionalities, not the technical aspects of the code. This keeps them clear and more universal.</value>
  </data>
  <data name="MiKo_1401_MessageFormat" xml:space="preserve">
    <value>Do not use technical name '{0}' in namespace</value>
  </data>
  <data name="MiKo_1401_Title" xml:space="preserve">
    <value>Namespaces should not contain technical language names</value>
  </data>
  <data name="MiKo_1402_Description" xml:space="preserve">
    <value>Namespaces should not be named after WPF-specific design patterns like 'Commands', 'Models', 'ViewModels', or 'Views.' Models are entities, while commands, view models, and views are UI-specific components that belong together. Clear and descriptive names help keep the code organized and more understandable.</value>
  </data>
  <data name="MiKo_1402_MessageFormat" xml:space="preserve">
    <value>Do not use WPF design pattern name '{0}' in namespace</value>
  </data>
  <data name="MiKo_1402_Title" xml:space="preserve">
    <value>Namespaces should not be named after WPF-specific design patterns</value>
  </data>
  <data name="MiKo_1403_Description" xml:space="preserve">
    <value>To prevent redundancy and confusion, avoid naming namespaces after parent namespaces. Instead, choose names that clearly indicate the namespace's purpose and the functionalities it contains. This helps developers easily understand and navigate the code structure.</value>
  </data>
  <data name="MiKo_1403_MessageFormat" xml:space="preserve">
    <value>Do not re-use '{0}' in namespace</value>
  </data>
  <data name="MiKo_1403_Title" xml:space="preserve">
    <value>Namespaces should not be named after any of their parent namespaces</value>
  </data>
  <data name="MiKo_1404_Description" xml:space="preserve">
    <value>Avoid using vague names like 'Miscellaneous' or 'Utilities' for namespaces. Instead, choose specific names that clearly describe the functionalitiesthey contain. This helps developers easily understand and navigate the code structure.</value>
  </data>
  <data name="MiKo_1404_MessageFormat" xml:space="preserve">
    <value>Do not use '{0}' in namespace</value>
  </data>
  <data name="MiKo_1404_Title" xml:space="preserve">
    <value>Namespaces should not contain unspecific names</value>
  </data>
  <data name="MiKo_1405_Description" xml:space="preserve">
    <value>Namespaces should be named based on the features they provide, not deployment details.
For example, using a 'Lib' suffix just indicates the assembly is a DLL, which is not helpful. Instead, focus on naming namespaces to reflect the functionality they offer, regardless of whether they're part of a library or an executable.</value>
  </data>
  <data name="MiKo_1405_MessageFormat" xml:space="preserve">
    <value>Do not use '{1}' in namespace</value>
  </data>
  <data name="MiKo_1405_Title" xml:space="preserve">
    <value>Namespaces should not contain 'Lib'</value>
  </data>
  <data name="MiKo_1406_Description" xml:space="preserve">
    <value>Value converters should be placed in and grouped under a specific namespace called 'Converters' to make them easier to find. This keeps the code organized and more navigable.</value>
  </data>
  <data name="MiKo_1406_MessageFormat" xml:space="preserve">
    <value>Place in 'Converters' namespace</value>
  </data>
  <data name="MiKo_1406_Title" xml:space="preserve">
    <value>Value converters should be placed in 'Converters' namespace</value>
  </data>
  <data name="MiKo_1407_Description" xml:space="preserve">
    <value>A test should reside in the same namespace as the class it tests. This makes it easier to find and relate the test to the class, enhancing organization and clarity.</value>
  </data>
  <data name="MiKo_1407_MessageFormat" xml:space="preserve">
    <value>Do not use 'Test' in namespace</value>
  </data>
  <data name="MiKo_1407_Title" xml:space="preserve">
    <value>Test namespaces should not contain 'Test'</value>
  </data>
  <data name="MiKo_1408_Description" xml:space="preserve">
    <value>To make usage easier, place extension method classes in the same namespace as the types they extend. This helps developers easily detect and use them with IntelliSense.</value>
  </data>
  <data name="MiKo_1408_MessageFormat" xml:space="preserve">
    <value>Place class in namespace '{1}'</value>
  </data>
  <data name="MiKo_1408_Title" xml:space="preserve">
    <value>Extension methods should be placed in same namespace as the extended types</value>
  </data>
  <data name="MiKo_1409_Description" xml:space="preserve">
    <value>Namespaces should be made up of full words without any leading or trailing underscores. This helps developers easily understand and navigate the code structure.</value>
  </data>
  <data name="MiKo_1409_MessageFormat" xml:space="preserve">
    <value>Name it '{1}' instead</value>
  </data>
  <data name="MiKo_1409_Title" xml:space="preserve">
    <value>Do not prefix or suffix namespaces with underscores</value>
  </data>
  <data name="MiKo_2000_CodeFixTitle" xml:space="preserve">
    <value>Fix malformed XML</value>
  </data>
  <data name="MiKo_2000_Description" xml:space="preserve">
    <value>Documentation should be valid XML to generate API documentation and support IntelliSense. This helps developers understand and use the code better, ensuring the documentation is accurate and accessible.</value>
  </data>
  <data name="MiKo_2000_MessageFormat" xml:space="preserve">
    <value>Documentation is malformed (contains invalid characters, e.g. '&amp;', '&gt;', '&lt;')</value>
  </data>
  <data name="MiKo_2000_Title" xml:space="preserve">
    <value>Documentation should be valid XML</value>
  </data>
  <data name="MiKo_2001_CodeFixTitle" xml:space="preserve">
    <value>Start comment with 'Occurs '</value>
  </data>
  <data name="MiKo_2001_Description" xml:space="preserve">
    <value>Events should be documented using the phrase 'Occurs...' to clearly indicate that they occur. This makes the documentation more precise.</value>
  </data>
  <data name="MiKo_2001_MessageFormat" xml:space="preserve">
    <value>Start &lt;summary&gt; with: '{1}'</value>
  </data>
  <data name="MiKo_2001_Title" xml:space="preserve">
    <value>Events should be documented properly</value>
  </data>
  <data name="MiKo_2002_CodeFixTitle" xml:space="preserve">
    <value>Apply 'Provides data for the &lt;see cref="TODO"/&gt; event.' comment</value>
  </data>
  <data name="MiKo_2002_Description" xml:space="preserve">
    <value>To make maintenance easier, classes inheriting from 'System.EventArgs' should include documentation stating 'Provides data for the &lt;see cref="XYZ" /&gt; event.' This clarifies which event they relate to, ensuring the documentation is clear and helpful.</value>
  </data>
  <data name="MiKo_2002_MessageFormat" xml:space="preserve">
    <value>&lt;summary&gt; should follow pattern: '{1} ... {2}'</value>
  </data>
  <data name="MiKo_2002_Title" xml:space="preserve">
    <value>EventArgs should be documented properly</value>
  </data>
  <data name="MiKo_2003_CodeFixTitle" xml:space="preserve">
    <value>Start comment with 'Handles the '</value>
  </data>
  <data name="MiKo_2003_Description" xml:space="preserve">
    <value>Documentation for an event handler should begin with a standard phrase that explains which event it handles.</value>
  </data>
  <data name="MiKo_2003_MessageFormat" xml:space="preserve">
    <value>Start &lt;summary&gt; with: '{1}'</value>
  </data>
  <data name="MiKo_2003_Title" xml:space="preserve">
    <value>Documentation of event handlers should have a default starting phrase</value>
  </data>
  <data name="MiKo_2004_CodeFixTitle" xml:space="preserve">
    <value>Fix comment of event handler parameter</value>
  </data>
  <data name="MiKo_2004_Description" xml:space="preserve">
    <value>Event handler parameter names should adhere to the .NET Framework Design Guidelines for event handlers. They should clearly define their purpose, making the documentation straightforward and easy to understand.</value>
  </data>
  <data name="MiKo_2004_MessageFormat" xml:space="preserve">
    <value>Change documentation to: '{1}'</value>
  </data>
  <data name="MiKo_2004_Title" xml:space="preserve">
    <value>Documentation of event handler parameter names should follow .NET Framework Design Guidelines for event handlers</value>
  </data>
  <data name="MiKo_2005_Description" xml:space="preserve">
    <value>Documentation should avoid using 'event arg'. Instead, directly reference the specific class like this: '&lt;see cref="XyzEventArgs" /&gt;'. This approach provides clarity and allows easy navigation to the related event argument type.</value>
  </data>
  <data name="MiKo_2005_MessageFormat" xml:space="preserve">
    <value>Do not use term 'event arg'</value>
  </data>
  <data name="MiKo_2005_Title" xml:space="preserve">
    <value>Textual references to EventArgs should be documented properly</value>
  </data>
  <data name="MiKo_2006_CodeFixTitle" xml:space="preserve">
    <value>Apply standard comment to RoutedEvent</value>
  </data>
  <data name="MiKo_2006_Description" xml:space="preserve">
    <value>Routed events should follow the same documentation style as the .NET Framework. This consistency ensures clarity, making it easier for developers to understand and work with these events.</value>
  </data>
  <data name="MiKo_2006_MessageFormat" xml:space="preserve">
    <value>&lt;{1}&gt; should be: '{2}'</value>
  </data>
  <data name="MiKo_2006_Title" xml:space="preserve">
    <value>Routed events should be documented as done by the .NET Framework</value>
  </data>
  <data name="MiKo_2010_CodeFixTitle" xml:space="preserve">
    <value>Append sealed text to comment</value>
  </data>
  <data name="MiKo_2010_Description" xml:space="preserve">
    <value>To simplify their use in inheritance scenarios, sealed classes should clearly document that they are sealed. This helps developers understand their constraints and usage better.</value>
  </data>
  <data name="MiKo_2010_MessageFormat" xml:space="preserve">
    <value>End &lt;summary&gt; with: '{1}'</value>
  </data>
  <data name="MiKo_2010_Title" xml:space="preserve">
    <value>Sealed classes should document being sealed</value>
  </data>
  <data name="MiKo_2011_CodeFixTitle" xml:space="preserve">
    <value>Remove sealed text to comment</value>
  </data>
  <data name="MiKo_2011_Description" xml:space="preserve">
    <value>Unsealed classes should not mention being sealed since they are not. This keeps things clear and straightforward for developers.</value>
  </data>
  <data name="MiKo_2011_MessageFormat" xml:space="preserve">
    <value>&lt;summary&gt; should not contain: '{1}'</value>
  </data>
  <data name="MiKo_2011_Title" xml:space="preserve">
    <value>Unsealed classes should not lie about sealing</value>
  </data>
  <data name="MiKo_2012_CodeFixTitle" xml:space="preserve">
    <value>Fix meaningless phrase</value>
  </data>
  <data name="MiKo_2012_Description" xml:space="preserve">
    <value>To simplify development and maintenance, the &lt;summary&gt; documentation should briefly explain a type's responsibility from the user's perspective.
Except for callback interfaces, it should avoid meaningless phrases like 'Used to'. Instead, start with phrases like 'Allows to', 'Represents', or 'Provides'.
This approach keeps the documentation clear and user-focused.</value>
  </data>
  <data name="MiKo_2012_MessageFormat" xml:space="preserve">
    <value>&lt;summary&gt; should not {1} meaningless phrase: '{2}'</value>
  </data>
  <data name="MiKo_2012_Title" xml:space="preserve">
    <value>&lt;summary&gt; documentation should describe the type's responsibility</value>
  </data>
  <data name="MiKo_2013_CodeFixTitle" xml:space="preserve">
    <value>Start comment with '{0}'</value>
  </data>
  <data name="MiKo_2013_Description" xml:space="preserve">
    <value>To make enums easier to use, they should clearly specify the types of values they define. This adds clarity and helps developers understand their purpose more quickly.</value>
  </data>
  <data name="MiKo_2013_MessageFormat" xml:space="preserve">
    <value>Start &lt;summary&gt; with: '{1}'</value>
  </data>
  <data name="MiKo_2013_Title" xml:space="preserve">
    <value>&lt;summary&gt; documentation of Enums should have a default starting phrase</value>
  </data>
  <data name="MiKo_2014_CodeFixTitle" xml:space="preserve">
    <value>Apply standard 'Dispose' comment</value>
  </data>
  <data name="MiKo_2014_Description" xml:space="preserve">
    <value>Dispose methods should follow the .NET Framework's documentation style. This ensures consistency and clarity, making it easier for developers to understand and implement disposal patterns correctly.</value>
  </data>
  <data name="MiKo_2014_MessageFormat" xml:space="preserve">
    <value>Change documentation to: '{1}'</value>
  </data>
  <data name="MiKo_2014_Title" xml:space="preserve">
    <value>Dispose methods should be documented as done by the .NET Framework</value>
  </data>
  <data name="MiKo_2015_CodeFixTitle" xml:space="preserve">
    <value>Replace term 'fire'</value>
  </data>
  <data name="MiKo_2015_Description" xml:space="preserve">
    <value>The word 'Fire' has negative connotations, like firing employees or guns. It's not appropriate for events or exceptions. Instead, use 'Raise' for events and 'Throw' for exceptions, as it conveys a more neutral and accurate action.</value>
  </data>
  <data name="MiKo_2015_MessageFormat" xml:space="preserve">
    <value>Use {1} instead of {2} in documentation</value>
  </data>
  <data name="MiKo_2015_Title" xml:space="preserve">
    <value>Documentation should use 'raise' or 'throw' instead of 'fire'</value>
  </data>
  <data name="MiKo_2016_CodeFixTitle" xml:space="preserve">
    <value>Start comment with '{0}'</value>
  </data>
  <data name="MiKo_2016_Description" xml:space="preserve">
    <value>Documentation for asynchronous methods should state that the method runs asynchronously. Start with 'Asynchronously...' to clearly convey this. This ensures developers immediately understand the method's behavior.</value>
  </data>
  <data name="MiKo_2016_MessageFormat" xml:space="preserve">
    <value>Start &lt;summary&gt; with: '{1}'</value>
  </data>
  <data name="MiKo_2016_Title" xml:space="preserve">
    <value>Documentation for asynchronous methods should start with specific phrase</value>
  </data>
  <data name="MiKo_2017_CodeFixTitle" xml:space="preserve">
    <value>Apply standard comment to DependencyProperty</value>
  </data>
  <data name="MiKo_2017_Description" xml:space="preserve">
    <value>Dependency properties should follow the same documentation style used by the .NET Framework. This consistency ensures clarity and makes it easier for developers to understand and work with these properties.</value>
  </data>
  <data name="MiKo_2017_MessageFormat" xml:space="preserve">
    <value>&lt;{1}&gt; should be: '{2}'</value>
  </data>
  <data name="MiKo_2017_Title" xml:space="preserve">
    <value>Dependency properties should be documented as done by the .NET Framework</value>
  </data>
  <data name="MiKo_2018_CodeFixTitle" xml:space="preserve">
    <value>Start &lt;summary&gt; with '{0}'</value>
  </data>
  <data name="MiKo_2018_Description" xml:space="preserve">
    <value>Terms like 'Check' or 'Test' can be vague. When validating parameters, use 'Validates'. When verifying something, use 'Verifies'. If the method needs to determine some condition or situation, use 'Determines whether.'
This ensures clarity and precision in your code.</value>
  </data>
  <data name="MiKo_2018_MessageFormat" xml:space="preserve">
    <value>Start &lt;summary&gt; with '{1}'</value>
  </data>
  <data name="MiKo_2018_Title" xml:space="preserve">
    <value>Documentation should not use the ambiguous terms 'Check' or 'Test'</value>
  </data>
  <data name="MiKo_2019_Description" xml:space="preserve">
    <value>&lt;summary&gt; documentation should always begin with a third person singular verb, such as "Provides". This concise description of the functionality that the class, property, etc. offers or represents ensures clarity and helps maintain a uniform documentation style.</value>
  </data>
  <data name="MiKo_2019_MessageFormat" xml:space="preserve">
    <value>Start &lt;summary&gt; with a third person singular verb</value>
  </data>
  <data name="MiKo_2019_Title" xml:space="preserve">
    <value>&lt;summary&gt; documentation should start with a third person singular verb (for example "Provides ")</value>
  </data>
  <data name="MiKo_2020_CodeFixTitle" xml:space="preserve">
    <value>Use &lt;inheritdoc/&gt;</value>
  </data>
  <data name="MiKo_2020_Description" xml:space="preserve">
    <value>Using a &lt;summary&gt; documentation that solely references something else with &lt;see cref="..." /&gt; is not effective, since IntelliSense does not display these descriptions. For such cases, the &lt;inheritdoc /&gt; tag should be used, as it's specifically designed for this purpose. This ensures the documentation is properly shown in IntelliSense and makes it more useful for developers.</value>
  </data>
  <data name="MiKo_2020_MessageFormat" xml:space="preserve">
    <value>Use &lt;inheritdoc /&gt; instead</value>
  </data>
  <data name="MiKo_2020_Title" xml:space="preserve">
    <value>Inherited documentation should be used with &lt;inheritdoc /&gt; marker</value>
  </data>
  <data name="MiKo_2021_CodeFixTitle" xml:space="preserve">
    <value>Start documentation with 'The '</value>
  </data>
  <data name="MiKo_2021_Description" xml:space="preserve">
    <value>The documentation of parameters should describe what they represent.</value>
  </data>
  <data name="MiKo_2021_MessageFormat" xml:space="preserve">
    <value>Start documentation with: {1}</value>
  </data>
  <data name="MiKo_2021_Title" xml:space="preserve">
    <value>Documentation of parameter should have a default starting phrase</value>
  </data>
  <data name="MiKo_2022_CodeFixTitle" xml:space="preserve">
    <value>Fix comment start of [out] parameter</value>
  </data>
  <data name="MiKo_2022_Description" xml:space="preserve">
    <value>For [out] parameter documentation, start with the success case, such as "On successful return, contains...". This approach aligns with the .NET framework documentation and ensures clarity for developers.</value>
  </data>
  <data name="MiKo_2022_MessageFormat" xml:space="preserve">
    <value>Start documentation with: {1}</value>
  </data>
  <data name="MiKo_2022_Title" xml:space="preserve">
    <value>Documentation of [out] parameters should have a default starting phrase</value>
  </data>
  <data name="MiKo_2023_CodeFixTitle" xml:space="preserve">
    <value>Fix comment start of Boolean parameter</value>
  </data>
  <data name="MiKo_2023_Description" xml:space="preserve">
    <value>For Boolean parameters, documentation should explicitly describe the 'true' case followed by the 'false' case. Use the format '&lt;see langword="true"/&gt; to indicate that ...; otherwise, &lt;see langword="false"/&gt;.'. This aligns with best practices and provides clarity for developers.</value>
  </data>
  <data name="MiKo_2023_MessageFormat" xml:space="preserve">
    <value>Documentation should follow pattern: '{1} ... {2}'</value>
  </data>
  <data name="MiKo_2023_Title" xml:space="preserve">
    <value>Documentation of Boolean parameters should have a default starting phrase</value>
  </data>
  <data name="MiKo_2024_CodeFixTitle" xml:space="preserve">
    <value>Fix comment start of Enum parameter</value>
  </data>
  <data name="MiKo_2024_Description" xml:space="preserve">
    <value>The Enum parameter documentation should begin with a phrase specifying the action to be taken with the Enum. This ensures clarity about how the Enum will be used and what it represents.</value>
  </data>
  <data name="MiKo_2024_MessageFormat" xml:space="preserve">
    <value>Start documentation with: {1}</value>
  </data>
  <data name="MiKo_2024_Title" xml:space="preserve">
    <value>Documentation of Enum parameters should have a default starting phrase</value>
  </data>
  <data name="MiKo_2025_CodeFixTitle" xml:space="preserve">
    <value>Fix comment start of CancellationToken</value>
  </data>
  <data name="MiKo_2025_Description" xml:space="preserve">
    <value>Documentation for 'CancellationToken' parameters should begin with a phrase that outlines its usage, like: 'The token to monitor for cancellation requests.' This keeps the documentation clear and consistent, aiding developers in understanding its purpose.</value>
  </data>
  <data name="MiKo_2025_MessageFormat" xml:space="preserve">
    <value>Start documentation with: {1}</value>
  </data>
  <data name="MiKo_2025_Title" xml:space="preserve">
    <value>Documentation of 'CancellationToken' parameters should have a default starting phrase</value>
  </data>
  <data name="MiKo_2026_Description" xml:space="preserve">
    <value>Documentation must always be accurate. If a parameter is still in use, it should never be labeled as unused. Keeping documentation truthful and clear is crucial for effective maintenance and development.</value>
  </data>
  <data name="MiKo_2026_MessageFormat" xml:space="preserve">
    <value>Documentation lies about being unused</value>
  </data>
  <data name="MiKo_2026_Title" xml:space="preserve">
    <value>Used parameters should not be documented to be unused</value>
  </data>
  <data name="MiKo_2027_CodeFixTitle" xml:space="preserve">
    <value>Fix comment start of parameter of serialization constructor</value>
  </data>
  <data name="MiKo_2027_Description" xml:space="preserve">
    <value>To ease the usage, the documentation of the parameters of the serialization constructors shall have a specific phrase that describes what they contain.</value>
  </data>
  <data name="MiKo_2027_MessageFormat" xml:space="preserve">
    <value>Change documentation to: '{1}'</value>
  </data>
  <data name="MiKo_2027_Title" xml:space="preserve">
    <value>Serialization constructor parameters shall be documented with a specific phrase</value>
  </data>
  <data name="MiKo_2028_Description" xml:space="preserve">
    <value>Documentation must go beyond just listing parameter names. It should clearly describe what the parameters represent and how they are used. Simply stating the parameter's name doesn't provide enough context or information. Accurate and detailed documentation makes code easier to understand and maintain.</value>
  </data>
  <data name="MiKo_2028_MessageFormat" xml:space="preserve">
    <value>Documentation should contain more than just the parameter name</value>
  </data>
  <data name="MiKo_2028_Title" xml:space="preserve">
    <value>Documentation of parameter should not just contain the name of the parameter</value>
  </data>
  <data name="MiKo_2029_CodeFixTitle" xml:space="preserve">
    <value>Remove 'cref' value from &lt;inheritdoc/&gt;</value>
  </data>
  <data name="MiKo_2029_Description" xml:space="preserve">
    <value>Instead of using &lt;inheritdoc&gt; with a 'cref' to itself, provide a clear and well-written &lt;summary&gt; XML documentation.</value>
  </data>
  <data name="MiKo_2029_MessageFormat" xml:space="preserve">
    <value>Do not use &lt;inheritdoc cref="{0}" /&gt;</value>
  </data>
  <data name="MiKo_2029_Title" xml:space="preserve">
    <value>&lt;inheritdoc&gt; documentation should not use a 'cref' to itself</value>
  </data>
  <data name="MiKo_2030_Description" xml:space="preserve">
    <value>Documentation for a return value should start with a default phrase that provides a detailed description of what the returned value is. This approach helps clarify the purpose and use of the return value for developers.</value>
  </data>
  <data name="MiKo_2030_MessageFormat" xml:space="preserve">
    <value>Start &lt;{1}&gt; with: '{2}'</value>
  </data>
  <data name="MiKo_2030_Title" xml:space="preserve">
    <value>Documentation of return value should have a default starting phrase</value>
  </data>
  <data name="MiKo_2031_CodeFixTitle" xml:space="preserve">
    <value>Fix return comment</value>
  </data>
  <data name="MiKo_2031_Description" xml:space="preserve">
    <value>The documentation for a 'Task' return value should start with a phrase that describes what the task represents and what result data it provides. This helps developers quickly understand the purpose and output of the task.</value>
  </data>
  <data name="MiKo_2031_MessageFormat" xml:space="preserve">
    <value>Start &lt;{1}&gt; with: '{2}'</value>
  </data>
  <data name="MiKo_2031_Title" xml:space="preserve">
    <value>Documentation of Task return value should have a specific (starting) phrase</value>
  </data>
  <data name="MiKo_2032_CodeFixTitle" xml:space="preserve">
    <value>Fix return comment</value>
  </data>
  <data name="MiKo_2032_Description" xml:space="preserve">
    <value>For Boolean return values, documentation should explicitly describe the 'true' case followed by the 'false' case. Use the format '&lt;see langword="true"/&gt; if ...; otherwise, &lt;see langword="false"/&gt;.'. This aligns with best practices, ensures clarity and helps developers understand the possible outcomes of the method.</value>
  </data>
  <data name="MiKo_2032_MessageFormat" xml:space="preserve">
    <value>&lt;{1}&gt; should follow pattern: '{2} ... {3}'</value>
  </data>
  <data name="MiKo_2032_Title" xml:space="preserve">
    <value>Documentation of Boolean return value should have a specific phrase</value>
  </data>
  <data name="MiKo_2033_CodeFixTitle" xml:space="preserve">
    <value>Fix return comment</value>
  </data>
  <data name="MiKo_2033_Description" xml:space="preserve">
    <value>The documentation of a String as return value should have a specific phrase.</value>
  </data>
  <data name="MiKo_2033_MessageFormat" xml:space="preserve">
    <value>Start &lt;{1}&gt; with: '{2}'</value>
  </data>
  <data name="MiKo_2033_Title" xml:space="preserve">
    <value>Documentation of String return value should have a default starting phrase</value>
  </data>
  <data name="MiKo_2034_CodeFixTitle" xml:space="preserve">
    <value>Fix return comment</value>
  </data>
  <data name="MiKo_2034_Description" xml:space="preserve">
    <value>The documentation of an Enum as return value should have a specific phrase.</value>
  </data>
  <data name="MiKo_2034_MessageFormat" xml:space="preserve">
    <value>Start &lt;{1}&gt; with: '{2}'</value>
  </data>
  <data name="MiKo_2034_Title" xml:space="preserve">
    <value>Documentation of Enum return value should have a default starting phrase</value>
  </data>
  <data name="MiKo_2035_CodeFixTitle" xml:space="preserve">
    <value>Fix return comment</value>
  </data>
  <data name="MiKo_2035_Description" xml:space="preserve">
    <value>The documentation of a collection as return value should have a specific phrase.</value>
  </data>
  <data name="MiKo_2035_MessageFormat" xml:space="preserve">
    <value>Start &lt;{1}&gt; with: '{2}'</value>
  </data>
  <data name="MiKo_2035_Title" xml:space="preserve">
    <value>Documentation of collection return value should have a default starting phrase</value>
  </data>
  <data name="MiKo_2036_CodeFixTitle_DefaultFalse" xml:space="preserve">
    <value>Fix comment for default value 'false'</value>
  </data>
  <data name="MiKo_2036_CodeFixTitle_DefaultTrue" xml:space="preserve">
    <value>Fix comment for default value 'true'</value>
  </data>
  <data name="MiKo_2036_CodeFixTitle_Enum" xml:space="preserve">
    <value>Fix comment for enum default value</value>
  </data>
  <data name="MiKo_2036_CodeFixTitle_NoDefault" xml:space="preserve">
    <value>Fix comment for no default value</value>
  </data>
  <data name="MiKo_2036_Description" xml:space="preserve">
    <value>Boolean or Enum property documentation should conclude with a phrase detailing the default return value. This helps developers quickly understand the property's typical output.</value>
  </data>
  <data name="MiKo_2036_MessageFormat" xml:space="preserve">
    <value>End &lt;{1}&gt; with: '{2}'
Or with: '{3}'</value>
  </data>
  <data name="MiKo_2036_Title" xml:space="preserve">
    <value>Documentation of Boolean or Enum property shall describe the default value</value>
  </data>
  <data name="MiKo_2037_CodeFixTitle" xml:space="preserve">
    <value>Apply standard comment to command property</value>
  </data>
  <data name="MiKo_2037_Description" xml:space="preserve">
    <value>The documentation for a property that returns a command should begin with a phrase that clearly describes what the command does, making the documentation more helpful and precise for developers.</value>
  </data>
  <data name="MiKo_2037_MessageFormat" xml:space="preserve">
    <value>Start &lt;{1}&gt; with: '{2}'</value>
  </data>
  <data name="MiKo_2037_Title" xml:space="preserve">
    <value>&lt;summary&gt; documentation of command properties should have a default starting phrase</value>
  </data>
  <data name="MiKo_2038_CodeFixTitle" xml:space="preserve">
    <value>Apply standard comment to command</value>
  </data>
  <data name="MiKo_2038_Description" xml:space="preserve">
    <value>The documentation for a command should start with a standard phrase such as 'Represents a command that can...'. This clearly describes the command's functionality and ensures consistency and clarity for developers.</value>
  </data>
  <data name="MiKo_2038_MessageFormat" xml:space="preserve">
    <value>Start &lt;{1}&gt; with: '{2}'</value>
  </data>
  <data name="MiKo_2038_Title" xml:space="preserve">
    <value>&lt;summary&gt; documentation of command should have a default starting phrase</value>
  </data>
  <data name="MiKo_2039_CodeFixTitle" xml:space="preserve">
    <value>Apply standard extension methods comment to class</value>
  </data>
  <data name="MiKo_2039_Description" xml:space="preserve">
    <value>The documentation for a class that contains extension methods should begin with the phrase 'Provides a set of &lt;see langword="static"/&gt; methods for...'
This format clearly describes the purpose of the class and its functionality, making the documentation straightforward and helpful for developers.</value>
  </data>
  <data name="MiKo_2039_MessageFormat" xml:space="preserve">
    <value>Start &lt;{1}&gt; with: '{2}'</value>
  </data>
  <data name="MiKo_2039_Title" xml:space="preserve">
    <value>&lt;summary&gt; documentation of classes that contain extension methods should have a default starting phrase</value>
  </data>
  <data name="MiKo_2040_CodeFixTitle" xml:space="preserve">
    <value>Use &lt;see langword="..."/&gt;</value>
  </data>
  <data name="MiKo_2040_Description" xml:space="preserve">
    <value>To support other .NET languages beyond C#, documentation should use '&lt;see langword="..."/&gt;' instead of '&lt;c&gt;...&lt;/c&gt;'. This ensures that language-specific terms are accurately translated into the correct terminology for each language, making the codebase more inclusive and accessible to non-C# developers.</value>
  </data>
  <data name="MiKo_2040_MessageFormat" xml:space="preserve">
    <value>Use '{2}' instead of '{1}'</value>
  </data>
  <data name="MiKo_2040_Title" xml:space="preserve">
    <value>&lt;see langword="..."/&gt; should be used instead of &lt;c&gt;...&lt;/c&gt;</value>
  </data>
  <data name="MiKo_2041_CodeFixTitle" xml:space="preserve">
    <value>Place XML tag outside &lt;summary&gt;</value>
  </data>
  <data name="MiKo_2041_Description" xml:space="preserve">
    <value>The &lt;summary&gt; documentation should be concise and only contain a brief summary description. Other information should be included in the appropriate XML tags alongside the &lt;summary&gt;. This ensures clarity and organization in the documentation.</value>
  </data>
  <data name="MiKo_2041_HelpLinkUri" xml:space="preserve">
    <value>https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/xmldoc/recommended-tags-for-documentation-comments</value>
  </data>
  <data name="MiKo_2041_MessageFormat" xml:space="preserve">
    <value>&lt;summary&gt; should not contain: '&lt;{0}/&gt;'</value>
  </data>
  <data name="MiKo_2041_Title" xml:space="preserve">
    <value>&lt;summary&gt; documentation should not contain other documentation tags</value>
  </data>
  <data name="MiKo_2042_CodeFixTitle" xml:space="preserve">
    <value>Replace &lt;br/&gt; with &lt;para/&gt;</value>
  </data>
  <data name="MiKo_2042_Description" xml:space="preserve">
    <value>Documentation should use the '&lt;para/&gt;' XML tags instead of '&lt;br/&gt;' or '&lt;p/&gt;' HTML tags. This ensures a consistent format, suitable for XML-based documentation tools and frameworks.</value>
  </data>
  <data name="MiKo_2042_HelpLinkUri" xml:space="preserve">
    <value>https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/xmldoc/para</value>
  </data>
  <data name="MiKo_2042_MessageFormat" xml:space="preserve">
    <value>Use '&lt;para/&gt;' instead of '{1}'</value>
  </data>
  <data name="MiKo_2042_Title" xml:space="preserve">
    <value>Documentation should use '&lt;para/&gt;' XML tags instead of '&lt;br/&gt;' HTML tags</value>
  </data>
  <data name="MiKo_2043_CodeFixTitle" xml:space="preserve">
    <value>Start &lt;summary&gt; with 'Encapsulates a method that '</value>
  </data>
  <data name="MiKo_2043_Description" xml:space="preserve">
    <value>Custom delegate type documentation should start with 'Encapsulates a method that...'. This phrase is crucial because a delegate refers to either a static method or an instance method of a class.
Declaring a delegate type sets a contract specifying the method signatures it can encapsulate, clarifying its purpose and usage for developers.</value>
  </data>
  <data name="MiKo_2043_MessageFormat" xml:space="preserve">
    <value>Start &lt;{1}&gt; with: '{2}'</value>
  </data>
  <data name="MiKo_2043_Title" xml:space="preserve">
    <value>&lt;summary&gt; documentation of custom delegates should have a default starting phrase</value>
  </data>
  <data name="MiKo_2044_CodeFixTitle" xml:space="preserve">
    <value>Use &lt;paramref&gt; tag for parameter</value>
  </data>
  <data name="MiKo_2044_Description" xml:space="preserve">
    <value>Method parameters should be referenced using &lt;paramref name="..."/&gt; in the documentation, not &lt;param name="..."/&gt; or plain text. This allows the documentation to update automatically if the parameter is renamed or deleted.</value>
  </data>
  <data name="MiKo_2044_MessageFormat" xml:space="preserve">
    <value>Fix incorrect parameter reference '{1}'</value>
  </data>
  <data name="MiKo_2044_Title" xml:space="preserve">
    <value>Documentation references method parameters correctly</value>
  </data>
  <data name="MiKo_2045_CodeFixTitle" xml:space="preserve">
    <value>Fix parameter reference</value>
  </data>
  <data name="MiKo_2045_Description" xml:space="preserve">
    <value>The &lt;summary&gt; documentation should not reference method parameters. Its sole purpose is to provide a brief overview. Including parameter details would be too specific for this high-level summary.</value>
  </data>
  <data name="MiKo_2045_MessageFormat" xml:space="preserve">
    <value>&lt;summary&gt; should not contain parameter reference ' {0} '</value>
  </data>
  <data name="MiKo_2045_Title" xml:space="preserve">
    <value>&lt;summary&gt; documentation should not reference parameters</value>
  </data>
  <data name="MiKo_2046_CodeFixTitle" xml:space="preserve">
    <value>Replace invalid type parameter reference</value>
  </data>
  <data name="MiKo_2046_Description" xml:space="preserve">
    <value>The XML documentation should reference type parameters properly via '&lt;typeparamref name="..." /&gt;'.</value>
  </data>
  <data name="MiKo_2046_MessageFormat" xml:space="preserve">
    <value>Replace invalid type parameter reference</value>
  </data>
  <data name="MiKo_2046_Title" xml:space="preserve">
    <value>Documentation should reference type parameters correctly</value>
  </data>
  <data name="MiKo_2047_Description" xml:space="preserve">
    <value>The documentation of an Attribute should start with a specific phrase that describes its purpose.</value>
  </data>
  <data name="MiKo_2047_MessageFormat" xml:space="preserve">
    <value>Start &lt;summary&gt; with: {1}</value>
  </data>
  <data name="MiKo_2047_Title" xml:space="preserve">
    <value>&lt;summary&gt; documentation of Attributes should have a default starting phrase</value>
  </data>
  <data name="MiKo_2048_CodeFixTitle" xml:space="preserve">
    <value>Start comment with '{0}'</value>
  </data>
  <data name="MiKo_2048_Description" xml:space="preserve">
    <value>The documentation of a value converters should start with a specific phrase that describes what they convert.</value>
  </data>
  <data name="MiKo_2048_MessageFormat" xml:space="preserve">
    <value>Start &lt;summary&gt; with: '{1}'</value>
  </data>
  <data name="MiKo_2048_Title" xml:space="preserve">
    <value>&lt;summary&gt; documentation of value converters should have a default starting phrase</value>
  </data>
  <data name="MiKo_2049_CodeFixTitle" xml:space="preserve">
    <value>Replace 'will be' with 'is'</value>
  </data>
  <data name="MiKo_2049_Description" xml:space="preserve">
    <value>The term 'will be' is not specific enough and it uses the future tense, which is not accurate for describing the current behavior or state of the code. Using 'is' instead gets straight to the point and employs the present tense, accurately reflecting the current behavior.
This practice ensures clarity and precision, making your code's behavior easier to understand.</value>
  </data>
  <data name="MiKo_2049_MessageFormat" xml:space="preserve">
    <value>Replace '{0}' with '{1}'</value>
  </data>
  <data name="MiKo_2049_Title" xml:space="preserve">
    <value>Documentation should be more explicit and not use 'will be'</value>
  </data>
  <data name="MiKo_2050_CodeFixTitle" xml:space="preserve">
    <value>Apply standard exception comment</value>
  </data>
  <data name="MiKo_2050_Description" xml:space="preserve">
    <value>Documentation for exceptions should follow the .NET Framework guidelines. This consistency ensures that the information is clear, precise, and familiar to developers, making it easier to understand and maintain.</value>
  </data>
  <data name="MiKo_2050_MessageFormat" xml:space="preserve">
    <value>Start &lt;{1}&gt; with: '{2}'</value>
  </data>
  <data name="MiKo_2050_Title" xml:space="preserve">
    <value>Exceptions should be documented following the .NET Framework</value>
  </data>
  <data name="MiKo_2051_CodeFixTitle" xml:space="preserve">
    <value>Fix exception comment</value>
  </data>
  <data name="MiKo_2051_Description" xml:space="preserve">
    <value>When documenting a thrown exception, use a simple condition phrase like: 'The item is not available.' Avoid phrases like 'Thrown if' or 'throws if' since it's already clear that the exception is thrown under those conditions. This keeps the documentation concise and to the point.</value>
  </data>
  <data name="MiKo_2051_MessageFormat" xml:space="preserve">
    <value>Use condition form to document thrown exception</value>
  </data>
  <data name="MiKo_2051_Title" xml:space="preserve">
    <value>Thrown Exceptions should be documented as kind of a condition (such as '&lt;paramref name="xyz"/&gt; is &lt;c&gt;42&lt;/c&gt;')</value>
  </data>
  <data name="MiKo_2052_CodeFixTitle" xml:space="preserve">
    <value>Fix exception comment</value>
  </data>
  <data name="MiKo_2052_Description" xml:space="preserve">
    <value>When documenting an ArgumentNullException, use the specific phrase: '&lt;paramref name="value"/&gt; is &lt;see langword="null"/&gt;.'
This approach ensures clarity and consistency, helping developers understand the condition under which the exception is thrown.</value>
  </data>
  <data name="MiKo_2052_MessageFormat" xml:space="preserve">
    <value>{1} should be something like:

{2}</value>
  </data>
  <data name="MiKo_2052_Title" xml:space="preserve">
    <value>Throwing of ArgumentNullException should be documented using a default phrase</value>
  </data>
  <data name="MiKo_2053_Description" xml:space="preserve">
    <value>An ArgumentNullException should not be documented for value-type parameters as value types inherently cannot have a null value.</value>
  </data>
  <data name="MiKo_2053_MessageFormat" xml:space="preserve">
    <value>Remove '{2}' from &lt;exception cref="ArgumentNullException"/&gt; as '{1}' is a value type</value>
  </data>
  <data name="MiKo_2053_Title" xml:space="preserve">
    <value>Throwing of ArgumentNullException should be documented only for reference type parameters</value>
  </data>
  <data name="MiKo_2054_CodeFixTitle" xml:space="preserve">
    <value>Fix exception comment</value>
  </data>
  <data name="MiKo_2054_Description" xml:space="preserve">
    <value>When documenting an ArgumentException being thrown, the documentation should start with the specific phrase: '&lt;paramref name="value"/&gt; is ...'.
This approach ensures clarity and consistency, helping developers understand the condition under which the exception is thrown.</value>
  </data>
  <data name="MiKo_2054_MessageFormat" xml:space="preserve">
    <value>{1} should be something like:
{2}</value>
  </data>
  <data name="MiKo_2054_Title" xml:space="preserve">
    <value>Throwing of ArgumentException should be documented using a default starting phrase</value>
  </data>
  <data name="MiKo_2055_CodeFixTitle" xml:space="preserve">
    <value>Fix exception comment</value>
  </data>
  <data name="MiKo_2055_Description" xml:space="preserve">
    <value>When documenting an ArgumentOutOfRangeException being thrown, the documentation should start with the specific phrase: '&lt;paramref name="value"/&gt; is ...'.
This approach ensures clarity and consistency, helping developers understand under what condition the argument is considered out of range.</value>
  </data>
  <data name="MiKo_2055_MessageFormat" xml:space="preserve">
    <value>{1} should be something like:
{2}</value>
  </data>
  <data name="MiKo_2055_Title" xml:space="preserve">
    <value>Throwing of ArgumentOutOfRangeException should be documented using a default starting phrase</value>
  </data>
  <data name="MiKo_2056_CodeFixTitle" xml:space="preserve">
    <value>Apply default ending comment to documentation of thrown 'ObjectDisposedException'</value>
  </data>
  <data name="MiKo_2056_Description" xml:space="preserve">
    <value>When documenting an ObjectDisposedException being thrown, the documentation should end with the specific phrase "... has been disposed." If the class includes a 'Close' method, it should end with "... has been closed."
This distinction clearly indicates the reason for the exception and helps developers understand the status of the object.</value>
  </data>
  <data name="MiKo_2056_MessageFormat" xml:space="preserve">
    <value>{1} should end with: '{2}'</value>
  </data>
  <data name="MiKo_2056_Title" xml:space="preserve">
    <value>Throwing of ObjectDisposedException should be documented using a default ending phrase</value>
  </data>
  <data name="MiKo_2057_CodeFixTitle" xml:space="preserve">
    <value>Remove exception comment</value>
  </data>
  <data name="MiKo_2057_Description" xml:space="preserve">
    <value>Types that do not inherit from 'IDisposable' cannot be disposed. Therefore, they should not document throwing an 'ObjectDisposedException'. This keeps the documentation accurate and logical.</value>
  </data>
  <data name="MiKo_2057_MessageFormat" xml:space="preserve">
    <value>Remove '{1}' because type does not inherit from 'IDisposable'</value>
  </data>
  <data name="MiKo_2057_Title" xml:space="preserve">
    <value>Types that are not disposable shall not throw an ObjectDisposedException</value>
  </data>
  <data name="MiKo_2059_CodeFixTitle" xml:space="preserve">
    <value>Consolidate exception documentation</value>
  </data>
  <data name="MiKo_2059_Description" xml:space="preserve">
    <value>To improve readability and maintenance, document thrown exceptions only once, consolidating them instead of listing multiple separate instances. This approach helps developers find specific information more easily and keeps the documentation clean and efficient.</value>
  </data>
  <data name="MiKo_2059_MessageFormat" xml:space="preserve">
    <value>Consolidate the documentation of &lt;exception cref='{1}'&gt;</value>
  </data>
  <data name="MiKo_2059_Title" xml:space="preserve">
    <value>Multiple documentation of same exception should be consolidated into one</value>
  </data>
  <data name="MiKo_2060_CodeFixTitle" xml:space="preserve">
    <value>Apply standard comment to factory</value>
  </data>
  <data name="MiKo_2060_Description" xml:space="preserve">
    <value>The documentation of factories should be uniform and consistent.</value>
  </data>
  <data name="MiKo_2060_MessageFormat" xml:space="preserve">
    <value>Start &lt;summary&gt; with: '{1}'</value>
  </data>
  <data name="MiKo_2060_Title" xml:space="preserve">
    <value>Factories should be documented in an uniform way</value>
  </data>
  <data name="MiKo_2070_CodeFixTitle" xml:space="preserve">
    <value>Replace 'Return' in comment</value>
  </data>
  <data name="MiKo_2070_Description" xml:space="preserve">
    <value>If method documentation starts with 'Returns', it shifts focus to the return value rather than the method's purpose. Instead, describe the method's intended function, not what it returns. This ensures clarity about the method's primary responsibility.</value>
  </data>
  <data name="MiKo_2070_MessageFormat" xml:space="preserve">
    <value>Start &lt;summary&gt; with: '{1}'</value>
  </data>
  <data name="MiKo_2070_Title" xml:space="preserve">
    <value>&lt;summary&gt; documentation should not start with 'Returns'</value>
  </data>
  <data name="MiKo_2071_Description" xml:space="preserve">
    <value>&lt;summary&gt; documentation for methods returning Enum types should avoid phrases meant for boolean types. Enum values are not booleans, so the documentation should not use terms like 'indicates whether', which imply a boolean context. This ensures the documentation accurately reflects the nature of the Enum type.</value>
  </data>
  <data name="MiKo_2071_MessageFormat" xml:space="preserve">
    <value>Do not use '{0}' in &lt;summary&gt;</value>
  </data>
  <data name="MiKo_2071_Title" xml:space="preserve">
    <value>&lt;summary&gt; documentation for methods that return Enum types should not contain phrase for boolean type</value>
  </data>
  <data name="MiKo_2072_CodeFixTitle" xml:space="preserve">
    <value>Start &lt;summary&gt; with 'Attempts to'</value>
  </data>
  <data name="MiKo_2072_Description" xml:space="preserve">
    <value>'Try' methods attempt to achieve something. Therefore, their &lt;summary&gt; documentation should start with 'Attempts to...' This clearly indicates the method's purpose and conveys its intent.</value>
  </data>
  <data name="MiKo_2072_MessageFormat" xml:space="preserve">
    <value>Start &lt;summary&gt; with 'Attempts to '</value>
  </data>
  <data name="MiKo_2072_Title" xml:space="preserve">
    <value>&lt;summary&gt; documentation should not start with 'Try'</value>
  </data>
  <data name="MiKo_2073_CodeFixTitle" xml:space="preserve">
    <value>Start &lt;summary&gt; with 'Determines whether'</value>
  </data>
  <data name="MiKo_2073_Description" xml:space="preserve">
    <value>The &lt;summary&gt; documentation of 'Contain' methods should start with the phrase 'Determines whether...'. This is because they attempt to determine if something exists within something else. This phrase sets a clear expectation for the method's functionality.</value>
  </data>
  <data name="MiKo_2073_MessageFormat" xml:space="preserve">
    <value>Start &lt;summary&gt; with 'Determines whether'</value>
  </data>
  <data name="MiKo_2073_Title" xml:space="preserve">
    <value>&lt;summary&gt; documentation of 'Contains' methods should start with 'Determines whether '</value>
  </data>
  <data name="MiKo_2074_CodeFixTitle" xml:space="preserve">
    <value>Fix comment of parameter</value>
  </data>
  <data name="MiKo_2074_Description" xml:space="preserve">
    <value>The &lt;summary&gt; documentation of 'Contain' methods should end with the phrase ' to seek.'. This is because they attempt to determine if a given parameter's value exists within something. This phrasing clearly communicates the intent and functionality of the parameter within the method.</value>
  </data>
  <data name="MiKo_2074_MessageFormat" xml:space="preserve">
    <value>&lt;param name="{0}"&gt; should end with: '{1}'</value>
  </data>
  <data name="MiKo_2074_Title" xml:space="preserve">
    <value>Documentation of parameter of 'Contains' method should have a default ending phrase</value>
  </data>
  <data name="MiKo_2075_CodeFixTitle" xml:space="preserve">
    <value>Change to '{0}'</value>
  </data>
  <data name="MiKo_2075_Description" xml:space="preserve">
    <value>XML documentation is for other developers. When you refer to 'Action' or 'Function' delegates, there's no need to call them 'action', 'func', or 'function', as the type info is already clear. Instead, refer to them as 'callback' since these delegates act as references to specific methods and serve as callbacks within the code.</value>
  </data>
  <data name="MiKo_2075_MessageFormat" xml:space="preserve">
    <value>Replace '{0}' with '{1}'</value>
  </data>
  <data name="MiKo_2075_Title" xml:space="preserve">
    <value>Documentation should use the term 'callback' instead of 'action', 'func' or 'function'</value>
  </data>
  <data name="MiKo_2076_CodeFixTitle" xml:space="preserve">
    <value>Document default value</value>
  </data>
  <data name="MiKo_2076_Description" xml:space="preserve">
    <value>In case a parameter is an optional one it is important to document its default value. This is because the values of those optional parameters are "baked into" the calling code.</value>
  </data>
  <data name="MiKo_2076_MessageFormat" xml:space="preserve">
    <value>Document the default value via '{1}'</value>
  </data>
  <data name="MiKo_2076_Title" xml:space="preserve">
    <value>Documentation should document default values of optional parameters</value>
  </data>
  <data name="MiKo_2077_Description" xml:space="preserve">
    <value>&lt;summary&gt; documentation should not include &lt;code&gt; snippets. The summary should be brief. Code snippets, which typically serve as examples, should be placed in the &lt;example&gt; section instead.</value>
  </data>
  <data name="MiKo_2077_MessageFormat" xml:space="preserve">
    <value>&lt;summary&gt; should not contain &lt;code&gt;</value>
  </data>
  <data name="MiKo_2077_Title" xml:space="preserve">
    <value>&lt;summary&gt; documentation should not contain &lt;code&gt;</value>
  </data>
  <data name="MiKo_2078_Description" xml:space="preserve">
    <value>&lt;code&gt; documentation should not include XML tags. Code snippets usually serve as examples and typically contain source code. If they contain plain XML, the XML won't be converted into documentation. Consequently, the resulting online help or IntelliSense will not display them.</value>
  </data>
  <data name="MiKo_2078_MessageFormat" xml:space="preserve">
    <value>&lt;code&gt; should not contain XML</value>
  </data>
  <data name="MiKo_2078_Title" xml:space="preserve">
    <value>&lt;code&gt; documentation should not contain XML tags</value>
  </data>
  <data name="MiKo_2079_CodeFixTitle" xml:space="preserve">
    <value>Remove obvious comment</value>
  </data>
  <data name="MiKo_2079_Description" xml:space="preserve">
    <value>Comments that merely state the name of a property and that it gets or sets provide no meaningful information. Such redundant comments should be removed to keep the code clean and focused on more valuable insights. Clear and concise documentation improves overall readability and maintenance.</value>
  </data>
  <data name="MiKo_2079_MessageFormat" xml:space="preserve">
    <value>Comment is obvious and provides no value</value>
  </data>
  <data name="MiKo_2079_Title" xml:space="preserve">
    <value>&lt;summary&gt; documentation of properties should not have obvious text</value>
  </data>
  <data name="MiKo_2080_CodeFixTitle" xml:space="preserve">
    <value>Start field with default phrase</value>
  </data>
  <data name="MiKo_2080_Description" xml:space="preserve">
    <value>The documentation of fields should start with a default phrase.</value>
  </data>
  <data name="MiKo_2080_MessageFormat" xml:space="preserve">
    <value>Start &lt;summary&gt; with: '{1}'</value>
  </data>
  <data name="MiKo_2080_Title" xml:space="preserve">
    <value>&lt;summary&gt; documentation of fields should have a default starting phrase</value>
  </data>
  <data name="MiKo_2081_CodeFixTitle" xml:space="preserve">
    <value>Append read-only text</value>
  </data>
  <data name="MiKo_2081_Description" xml:space="preserve">
    <value>For public-visible read-only fields, the documentation should clearly state that the field is read-only. This detail informs developers about the field's immutability and intended usage.</value>
  </data>
  <data name="MiKo_2081_MessageFormat" xml:space="preserve">
    <value>End &lt;summary&gt; with: '{1}'</value>
  </data>
  <data name="MiKo_2081_Title" xml:space="preserve">
    <value>&lt;summary&gt; documentation of public-visible read-only fields should have a default ending phrase</value>
  </data>
  <data name="MiKo_2082_CodeFixTitle" xml:space="preserve">
    <value>Fix enum member starting phrase</value>
  </data>
  <data name="MiKo_2082_Description" xml:space="preserve">
    <value>The &lt;summary&gt; documentation of an Enum member should avoid phrases used in the Enum's own summary - like 'Defines', 'Indicates', or 'Specifies.' Instead, it should focus on describing the meaning and purpose of the individual member, providing clear and specific details.
This ensures the documentation is precise and informative, helping developers understand each member's role and functionality.</value>
  </data>
  <data name="MiKo_2082_MessageFormat" xml:space="preserve">
    <value>Do not start &lt;summary&gt; with: '{0}'</value>
  </data>
  <data name="MiKo_2082_Title" xml:space="preserve">
    <value>&lt;summary&gt; documentation of Enum members should not start with default starting phrases of Enum &lt;summary&gt; documentation</value>
  </data>
  <data name="MiKo_2090_CodeFixTitle" xml:space="preserve">
    <value>Apply standard comment</value>
  </data>
  <data name="MiKo_2090_Description" xml:space="preserve">
    <value>For smoother development and usage, XML documentation for equality operators should use a standard default phrase, like in the .NET framework. This keeps things consistent and makes it easier for developers to understand and implement these operators correctly.</value>
  </data>
  <data name="MiKo_2090_MessageFormat" xml:space="preserve">
    <value>&lt;{1}&gt; should be: '{2}'</value>
  </data>
  <data name="MiKo_2090_Title" xml:space="preserve">
    <value>Documentation for equality operator shall have default phrase</value>
  </data>
  <data name="MiKo_2091_CodeFixTitle" xml:space="preserve">
    <value>Apply standard comment</value>
  </data>
  <data name="MiKo_2091_Description" xml:space="preserve">
    <value>For smoother development and usage, XML documentation for inequality operators should use a standard default phrase, like in the .NET framework. This keeps things consistent and makes it easier for developers to understand and implement these operators correctly.</value>
  </data>
  <data name="MiKo_2091_MessageFormat" xml:space="preserve">
    <value>&lt;{1}&gt; should be: '{2}'</value>
  </data>
  <data name="MiKo_2091_Title" xml:space="preserve">
    <value>Documentation for inequality operator shall have default phrase</value>
  </data>
  <data name="MiKo_2100_CodeFixTitle" xml:space="preserve">
    <value>Start comment with '{0}'</value>
  </data>
  <data name="MiKo_2100_Description" xml:space="preserve">
    <value>To make example documentation more user-friendly, it should begin with a brief phrase that explains what the example demonstrates. This provides clarity and helps developers quickly understand the purpose of the example.</value>
  </data>
  <data name="MiKo_2100_MessageFormat" xml:space="preserve">
    <value>Start &lt;example&gt; with: '{1}'</value>
  </data>
  <data name="MiKo_2100_Title" xml:space="preserve">
    <value>&lt;example&gt; documentation should start with descriptive default phrase</value>
  </data>
  <data name="MiKo_2101_CodeFixTitle" xml:space="preserve">
    <value>Surround sample code with '&lt;code&gt;'</value>
  </data>
  <data name="MiKo_2101_Description" xml:space="preserve">
    <value>For better readability, example documentation should enclose code samples within &lt;code&gt; tags. This allows IntelliSense or any XML documentation tool to format them properly, making the examples easier to understand and visually distinct.</value>
  </data>
  <data name="MiKo_2101_MessageFormat" xml:space="preserve">
    <value>Place sample code in &lt;example&gt; inside '&lt;code&gt;' tags</value>
  </data>
  <data name="MiKo_2101_Title" xml:space="preserve">
    <value>&lt;example&gt; documentation should show code example in &lt;code&gt; tags</value>
  </data>
  <data name="MiKo_2200_CodeFixTitle" xml:space="preserve">
    <value>Use capitalized letter</value>
  </data>
  <data name="MiKo_2200_Description" xml:space="preserve">
    <value>Documentation should always start with a capitalized letter to form a complete sentence. This ensures clarity and professionalism, making the documentation easy to read and understand. Full sentences convey complete thoughts, which is essential for accurate and effective communication.</value>
  </data>
  <data name="MiKo_2200_MessageFormat" xml:space="preserve">
    <value>Start &lt;{1}&gt; with capitalized letter</value>
  </data>
  <data name="MiKo_2200_Title" xml:space="preserve">
    <value>Use a capitalized letter to start the comment</value>
  </data>
  <data name="MiKo_2201_Description" xml:space="preserve">
    <value>Sentences within documentation should always begin with a capitalized letter to form a complete sentence. This ensures clarity, readability, and professionalism, making the documentation easier to understand and more effective. Full sentences convey clear, complete thoughts, which is essential for precise communication.</value>
  </data>
  <data name="MiKo_2201_MessageFormat" xml:space="preserve">
    <value>Start the sentence(s) in &lt;{1}&gt; with capitalized letter</value>
  </data>
  <data name="MiKo_2201_Title" xml:space="preserve">
    <value>Use a capitalized letter to start the sentences in the comment</value>
  </data>
  <data name="MiKo_2202_CodeFixTitle" xml:space="preserve">
    <value>Change 'id' into 'identifier'</value>
  </data>
  <data name="MiKo_2202_Description" xml:space="preserve">
    <value>XML documentation should avoid using the abbreviation 'id' and instead clearly state 'identifier' as they actually are identifiers. This ensures clarity and precision, making the documentation more understandable and accessible for developers.</value>
  </data>
  <data name="MiKo_2202_MessageFormat" xml:space="preserve">
    <value>Use 'identifier' instead of 'id'</value>
  </data>
  <data name="MiKo_2202_Title" xml:space="preserve">
    <value>Documentation should use the term 'identifier' instead of 'id'</value>
  </data>
  <data name="MiKo_2203_CodeFixTitle" xml:space="preserve">
    <value>Change 'GUID' into 'unique identifier'</value>
  </data>
  <data name="MiKo_2203_Description" xml:space="preserve">
    <value>XML documentation should avoid using the abbreviation 'guid' and instead clearly state 'unique identifier' as they actually are globally unique identifiers. This ensures clarity and precision, making the documentation more understandable and accessible for developers.</value>
  </data>
  <data name="MiKo_2203_MessageFormat" xml:space="preserve">
    <value>Use 'unique identifier' instead of 'guid'</value>
  </data>
  <data name="MiKo_2203_Title" xml:space="preserve">
    <value>Documentation should use the term 'unique identifier' instead of 'guid'</value>
  </data>
  <data name="MiKo_2204_CodeFixTitle" xml:space="preserve">
    <value>Use &lt;list&gt; to list items</value>
  </data>
  <data name="MiKo_2204_Description" xml:space="preserve">
    <value>XML documentation should use the &lt;list&gt; tag for enumerating items. Avoid using terms like 1.), 2.), etc., directly because IntelliSense and XML documentation tools cannot recognize these and may format comments awkwardly.
Using &lt;list&gt; allows IntelliSense to format content as tables, numbered lists, ordered lists, etc., making documentation clear and easy to read.</value>
  </data>
  <data name="MiKo_2204_HelpLinkUri" xml:space="preserve">
    <value>https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/xmldoc/list</value>
  </data>
  <data name="MiKo_2204_MessageFormat" xml:space="preserve">
    <value>Use &lt;list&gt; to list items in documentation</value>
  </data>
  <data name="MiKo_2204_Title" xml:space="preserve">
    <value>Documentation should use &lt;list&gt; for enumerations</value>
  </data>
  <data name="MiKo_2205_Description" xml:space="preserve">
    <value>XML documentation should utilize the &lt;note&gt; tag for important information. Avoid using terms like 'Important' or 'Attention' directly. This approach allows XML documentation tools to recognize and format the information in a distinct and noticeable way, ensuring clarity and emphasis.</value>
  </data>
  <data name="MiKo_2205_MessageFormat" xml:space="preserve">
    <value>Use &lt;note&gt; for important information in documentation</value>
  </data>
  <data name="MiKo_2205_Title" xml:space="preserve">
    <value>Documentation should use &lt;note&gt; for important information</value>
  </data>
  <data name="MiKo_2206_Description" xml:space="preserve">
    <value>Documentation should avoid using the term 'flag' for boolean values. Instead, rephrase the documentation to eliminate the need for this term. This ensures clarity and precision, making it easier for developers to understand the context and purpose of the boolean value.</value>
  </data>
  <data name="MiKo_2206_MessageFormat" xml:space="preserve">
    <value>Remove '{0}' from documentation</value>
  </data>
  <data name="MiKo_2206_Title" xml:space="preserve">
    <value>Documentation should not use the term 'flag'</value>
  </data>
  <data name="MiKo_2207_Description" xml:space="preserve">
    <value>The &lt;summary&gt; documentation should be brief and descriptive, providing an overview of the functionality. For more detailed information, use the &lt;remarks&gt; section. This keeps the summary concise and the documentation well-organized, making it easier for developers to understand.</value>
  </data>
  <data name="MiKo_2207_MessageFormat" xml:space="preserve">
    <value>&lt;summary&gt; is too long, use &lt;remarks&gt; section for all the details</value>
  </data>
  <data name="MiKo_2207_Title" xml:space="preserve">
    <value>&lt;summary&gt; documentation shall be short</value>
  </data>
  <data name="MiKo_2208_CodeFixTitle" xml:space="preserve">
    <value>Remove 'an instance of'</value>
  </data>
  <data name="MiKo_2208_Description" xml:space="preserve">
    <value>Documentation should use a more meaningful description than 'an instance of'. A concrete description helps developers better understand the meaning. Clear and specific language enhances comprehension and usability.</value>
  </data>
  <data name="MiKo_2208_MessageFormat" xml:space="preserve">
    <value>Use a better description than '{0}'</value>
  </data>
  <data name="MiKo_2208_Title" xml:space="preserve">
    <value>Documentation should not use the term 'an instance of'</value>
  </data>
  <data name="MiKo_2209_CodeFixTitle" xml:space="preserve">
    <value>Remove '..' from documentation</value>
  </data>
  <data name="MiKo_2209_Description" xml:space="preserve">
    <value>XML documentation is for other developers and should be clear and easy to read. It must include all important information without any typos or confusing comments to avoid misleading developers.</value>
  </data>
  <data name="MiKo_2209_MessageFormat" xml:space="preserve">
    <value>Remove '..' from documentation</value>
  </data>
  <data name="MiKo_2209_Title" xml:space="preserve">
    <value>Do not use double periods in documentation</value>
  </data>
  <data name="MiKo_2210_CodeFixTitle" xml:space="preserve">
    <value>Change 'info' into 'information'</value>
  </data>
  <data name="MiKo_2210_Description" xml:space="preserve">
    <value>XML documentation should avoid the abbreviation 'info' and instead use 'information'. This practice ensures clarity and professionalism in documentation, making it easier for developers to understand and follow.</value>
  </data>
  <data name="MiKo_2210_MessageFormat" xml:space="preserve">
    <value>Use 'information' instead of 'info'</value>
  </data>
  <data name="MiKo_2210_Title" xml:space="preserve">
    <value>Documentation should use the term 'information' instead of 'info'</value>
  </data>
  <data name="MiKo_2211_CodeFixTitle" xml:space="preserve">
    <value>Move remarks comment into summary</value>
  </data>
  <data name="MiKo_2211_Description" xml:space="preserve">
    <value>Tools like Sandcastle cannot process &lt;remarks&gt; sections on enum members, meaning the resulting output (CHM, HTML, etc.) will not include these sections. Since developers often use HTML/CHM documentation when working with third-party frameworks, crucial information in the &lt;remarks&gt; section may be inaccessible.

To ensure developers have all the necessary information, it's best to place this information inside the &lt;summary&gt; section instead. This guarantees that all essential details are included in the output documentation.</value>
  </data>
  <data name="MiKo_2211_MessageFormat" xml:space="preserve">
    <value>Use &lt;summary&gt; instead of &lt;remarks&gt;</value>
  </data>
  <data name="MiKo_2211_Title" xml:space="preserve">
    <value>Enum members should not have &lt;remarks&gt; sections</value>
  </data>
  <data name="MiKo_2212_CodeFixTitle" xml:space="preserve">
    <value>Change 'was not successful' to 'failed'</value>
  </data>
  <data name="MiKo_2212_Description" xml:space="preserve">
    <value>To make documentation concise and precise, use 'failed' instead of 'was not successful'. This keeps it brief and straight to the point, making it easier for developers to understand quickly.</value>
  </data>
  <data name="MiKo_2212_MessageFormat" xml:space="preserve">
    <value>Use 'failed' instead of 'was not successful'</value>
  </data>
  <data name="MiKo_2212_Title" xml:space="preserve">
    <value>Documentation should use the phrase 'failed' instead of 'was not successful'</value>
  </data>
  <data name="MiKo_2213_CodeFixTitle" xml:space="preserve">
    <value>Change "n't" to " not"</value>
  </data>
  <data name="MiKo_2213_Description" xml:space="preserve">
    <value>Sometimes, contractions are missed, causing unintentional errors. To prevent this, it's best to avoid them entirely.</value>
  </data>
  <data name="MiKo_2213_MessageFormat" xml:space="preserve">
    <value>Do not use contraction "n't"</value>
  </data>
  <data name="MiKo_2213_Title" xml:space="preserve">
    <value>Documentation should not use the contraction "n't"</value>
  </data>
  <data name="MiKo_2214_CodeFixTitle" xml:space="preserve">
    <value>Replace empty line with &lt;para/&gt;</value>
  </data>
  <data name="MiKo_2214_Description" xml:space="preserve">
    <value>To avoid dense text in generated documentation (e.g., IntelliSense), empty lines should not be used. Developers often insert them to create paragraphs, but they get ignored and removed.
Instead, use &lt;para&gt; tags, which are designed to mark paragraphs properly, ensuring the generated documentation remains clear and well-structured.</value>
  </data>
  <data name="MiKo_2214_MessageFormat" xml:space="preserve">
    <value>Replace empty line with &lt;para/&gt;</value>
  </data>
  <data name="MiKo_2214_Title" xml:space="preserve">
    <value>Documentation should not contain empty lines</value>
  </data>
  <data name="MiKo_2215_Description" xml:space="preserve">
    <value>Keep documentation sentences up to 15 words. Shorter sentences are clearer and more descriptive. Longer sentences can be hard to read and may bore readers. This approach ensures effective communication.</value>
  </data>
  <data name="MiKo_2215_MessageFormat" xml:space="preserve">
    <value>Shorten sentences to contain up to 15 words each</value>
  </data>
  <data name="MiKo_2215_Title" xml:space="preserve">
    <value>Sentences in documentation shall be short</value>
  </data>
  <data name="MiKo_2216_CodeFixTitle" xml:space="preserve">
    <value>Change &lt;param&gt; to &lt;paramref&gt;</value>
  </data>
  <data name="MiKo_2216_Description" xml:space="preserve">
    <value>The &lt;param&gt; tag is for describing parameters, whereas the &lt;paramref&gt; tag is used to indicate that a word in the code comments refers to a parameter. When referencing a parameter in sections like &lt;remarks&gt;, use the &lt;paramref&gt; tag to maintain clarity and proper documentation standards.</value>
  </data>
  <data name="MiKo_2216_MessageFormat" xml:space="preserve">
    <value>Use &lt;paramref&gt; instead of &lt;param&gt;</value>
  </data>
  <data name="MiKo_2216_Title" xml:space="preserve">
    <value>Use &lt;paramref&gt; instead of &lt;param&gt; to reference parameters</value>
  </data>
  <data name="MiKo_2217_CodeFixTitle" xml:space="preserve">
    <value>Fix '&lt;list&gt;'</value>
  </data>
  <data name="MiKo_2217_Description" xml:space="preserve">
    <value>The documentation of a &lt;list&gt; can be ambiguous, as there are three types: 'number', 'bullet', and 'table'.

- Only 'table' lists can have a single &lt;listheader&gt; and multiple &lt;item&gt; entries. 'Number' and 'bullet' lists only have &lt;item&gt; entries.

- For 'table' lists, each &lt;listheader&gt; and &lt;item&gt; can contain either a single, optional &lt;term&gt; and a single, required &lt;description&gt;, or multiple &lt;term&gt; entries.

- For 'bullet' or 'number' lists, each &lt;item&gt; can contain a single, optional &lt;term&gt; and a single, required &lt;description&gt;.

- An &lt;item&gt; should never contain multiple &lt;description&gt; entries.

This ensures your list documentation is clear and accurately structured.</value>
  </data>
  <data name="MiKo_2217_HelpLinkUri" xml:space="preserve">
    <value>http://www.blackwasp.co.uk/DocumentationLists.aspx</value>
  </data>
  <data name="MiKo_2217_MessageArgument_MissingDescription" xml:space="preserve">
    <value>&lt;description&gt; is missing</value>
  </data>
  <data name="MiKo_2217_MessageArgument_MissingTermOrDescription" xml:space="preserve">
    <value>&lt;description&gt; or &lt;term&gt; is missing</value>
  </data>
  <data name="MiKo_2217_MessageArgument_NoHeaderAllowed" xml:space="preserve">
    <value>&lt;listheader&gt; is not allowed for this type of &lt;list&gt;</value>
  </data>
  <data name="MiKo_2217_MessageArgument_OnlySingleDescriptionAllowed" xml:space="preserve">
    <value>&lt;description&gt; is not allowed to occur multiple times for this type of &lt;list&gt;</value>
  </data>
  <data name="MiKo_2217_MessageArgument_OnlySingleTermAllowed" xml:space="preserve">
    <value>&lt;term&gt; is not allowed to occur multiple times for this type of &lt;list&gt;</value>
  </data>
  <data name="MiKo_2217_MessageArgument_UnknownTypeSpecified" xml:space="preserve">
    <value>The 'type' attribute contains the unknown type {0}</value>
  </data>
  <data name="MiKo_2217_MessageFormat" xml:space="preserve">
    <value>Use &lt;list&gt; properly: {1}</value>
  </data>
  <data name="MiKo_2217_Title" xml:space="preserve">
    <value>&lt;list&gt; documentation is done properly</value>
  </data>
  <data name="MiKo_2218_CodeFixTitle" xml:space="preserve">
    <value>Shorten term</value>
  </data>
  <data name="MiKo_2218_Description" xml:space="preserve">
    <value>Phrases like 'that is used to' or 'which shall be used to' are unnecessarily wordy. They should be shortened to the more concise term 'to'. This enhances readability and streamlines documentation, making it clearer and more direct for developers.</value>
  </data>
  <data name="MiKo_2218_MessageFormat" xml:space="preserve">
    <value>Replace '{0}' with '{1}'</value>
  </data>
  <data name="MiKo_2218_Title" xml:space="preserve">
    <value>Documentation should use shorter terms instead of longer term 'used to/in/by'</value>
  </data>
  <data name="MiKo_2219_Description" xml:space="preserve">
    <value>XML documentation should be clear and comprehensive for developers. It must contain all important information in an easily readable and understandable format.

- Avoid ending texts with exclamation marks; instead, use tags like &lt;note type="important"&gt; for emphasis.

- Documentation should state facts, not question them. Therefore, avoid ending sentences with question marks.

This ensures clarity and usability in your documentation, making it straightforward for developers to follow.</value>
  </data>
  <data name="MiKo_2219_MessageFormat" xml:space="preserve">
    <value>Do not use '{0}' in documentation</value>
  </data>
  <data name="MiKo_2219_Title" xml:space="preserve">
    <value>Do not use question or explamation marks in documentation</value>
  </data>
  <data name="MiKo_2220_CodeFixTitle" xml:space="preserve">
    <value>Replace with 'to seek'</value>
  </data>
  <data name="MiKo_2220_Description" xml:space="preserve">
    <value>Phrases like 'to look for', 'to inspect for', or 'to test for' all convey the same idea: to seek something. Therefore, they should be replaced with the term 'to seek'. This streamlines documentation, making it clearer and more concise for developers.</value>
  </data>
  <data name="MiKo_2220_MessageFormat" xml:space="preserve">
    <value>Use 'to seek' instead</value>
  </data>
  <data name="MiKo_2220_Title" xml:space="preserve">
    <value>Documentation should use 'to seek' instead of 'to look for', 'to inspect for' or 'to test for'</value>
  </data>
  <data name="MiKo_2221_Description" xml:space="preserve">
    <value>An empty documentation is a code smell. It indicates that the developer created the XML documentation tag intentionally but failed to provide any actual content. This suggests a potential oversight or lack of attention to detail. Proper documentation is crucial for code clarity and maintenance.</value>
  </data>
  <data name="MiKo_2221_MessageFormat" xml:space="preserve">
    <value>Provide a documentation for &lt;{1}/&gt;</value>
  </data>
  <data name="MiKo_2221_Title" xml:space="preserve">
    <value>Documentation should not use empty XML tags</value>
  </data>
  <data name="MiKo_2222_CodeFixTitle" xml:space="preserve">
    <value>Change 'ident' into identification'</value>
  </data>
  <data name="MiKo_2222_Description" xml:space="preserve">
    <value>XML documentation should avoid the abbreviation 'ident' and instead use the term 'identification'. This ensures clarity and precision, making the documentation more understandable and professional. Clear terminology helps prevent confusion and enhances readability for developers.</value>
  </data>
  <data name="MiKo_2222_MessageFormat" xml:space="preserve">
    <value>Use 'identification' instead of 'ident'</value>
  </data>
  <data name="MiKo_2222_Title" xml:space="preserve">
    <value>Documentation should use the term 'identification' instead of 'ident'</value>
  </data>
  <data name="MiKo_2223_Description" xml:space="preserve">
    <value>XML documentation should link references like methods or types using &lt;see cref="..."/&gt; instead of plain text. This approach ensures refactoring tools can update these references during renames, preventing the documentation from pointing to non-existent code.</value>
  </data>
  <data name="MiKo_2223_MessageFormat" xml:space="preserve">
    <value>Use '&lt;see cref="{0}"/&gt;' instead</value>
  </data>
  <data name="MiKo_2223_Title" xml:space="preserve">
    <value>Documentation links references via &lt;see cref="..."/&gt;</value>
  </data>
  <data name="MiKo_2224_CodeFixTitle" xml:space="preserve">
    <value>Place on separate line</value>
  </data>
  <data name="MiKo_2224_Description" xml:space="preserve">
    <value>To improve usability and readability, place XML tags and their corresponding texts on separate lines in your documentation. This formatting makes it easier for developers to read and navigate the documentation, ensuring clarity and better organization.</value>
  </data>
  <data name="MiKo_2224_MessageFormat" xml:space="preserve">
    <value>Place '{0}' on separate line</value>
  </data>
  <data name="MiKo_2224_Title" xml:space="preserve">
    <value>Documentation should have XML tags and texts placed on separate lines</value>
  </data>
  <data name="MiKo_2225_CodeFixTitle" xml:space="preserve">
    <value>Place on same line</value>
  </data>
  <data name="MiKo_2225_Description" xml:space="preserve">
    <value>Use the &lt;c&gt; tag to mark text within a description as code, but only for single lines. For multiple lines of code, you should use the &lt;code&gt; tag. This ensures the formatting is clear and the documentation remains organized and readable.</value>
  </data>
  <data name="MiKo_2225_HelpLinkUri" xml:space="preserve">
    <value>https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/xmldoc/recommended-tags#c</value>
  </data>
  <data name="MiKo_2225_MessageFormat" xml:space="preserve">
    <value>Place '&lt;c&gt;' tag with its content on same line</value>
  </data>
  <data name="MiKo_2225_Title" xml:space="preserve">
    <value>Code marked with &lt;c&gt; tags should be placed on single line</value>
  </data>
  <data name="MiKo_2226_Description" xml:space="preserve">
    <value>Instead of simply stating *that* an intention exists, documentation should clearly explain *what* the intention actually is. This provides developers with valuable background information, enabling them to make more informed decisions based on that context.
Clear intentions help convey the purpose and reasoning behind code, which is crucial for effective collaboration and maintenance.</value>
  </data>
  <data name="MiKo_2226_MessageFormat" xml:space="preserve">
    <value>Explain what the intention behind actually is</value>
  </data>
  <data name="MiKo_2226_Title" xml:space="preserve">
    <value>Documentation should explain the 'Why' and not the 'That'</value>
  </data>
  <data name="MiKo_2227_Description" xml:space="preserve">
    <value>ReSharper allows you to suppress certain rules using inline comments like // ReSharper disable or // ReSharper disable once. These suppressions can apply either once or until the document's end, or until the rule is re-enabled.
However, these suppressions should remain inline comments and must not be part of the XML documentation. This keeps your documentation clean and professional, ensuring it's not cluttered with tool-specific directives.</value>
  </data>
  <data name="MiKo_2227_MessageFormat" xml:space="preserve">
    <value>Remove from documentation and use inline comment instead</value>
  </data>
  <data name="MiKo_2227_Title" xml:space="preserve">
    <value>Documentation should not contain ReSharper suppressions</value>
  </data>
  <data name="MiKo_2228_Description" xml:space="preserve">
    <value>Negative wording can be confusing, especially when combined with other negative terms (e.g., "You cannot do this if it is not empty"). Positive wording is clearer and more direct, making the documentation straightforward and to the point. This approach enhances readability and comprehension, helping developers easily grasp the information.</value>
  </data>
  <data name="MiKo_2228_MessageFormat" xml:space="preserve">
    <value>Use positive wording instead of negative</value>
  </data>
  <data name="MiKo_2228_Title" xml:space="preserve">
    <value>Documentation should use positive wording instead of negative</value>
  </data>
  <data name="MiKo_2229_CodeFixTitle" xml:space="preserve">
    <value>Delete XML fragment</value>
  </data>
  <data name="MiKo_2229_Description" xml:space="preserve">
    <value>XML fragments in documentation often go unnoticed by developers but can end up in publicly available documentation. Therefore, it's best to avoid them to ensure clean, professional, and comprehensible documentation. This approach keeps the documentation neat and free from unwanted remnants.</value>
  </data>
  <data name="MiKo_2229_MessageFormat" xml:space="preserve">
    <value>Delete XML fragment '{0}'</value>
  </data>
  <data name="MiKo_2229_Title" xml:space="preserve">
    <value>Documentation should not contain left-over XML fragments</value>
  </data>
  <data name="MiKo_2231_CodeFixTitle" xml:space="preserve">
    <value>Use &lt;inheritdoc/&gt;</value>
  </data>
  <data name="MiKo_2231_Description" xml:space="preserve">
    <value>The main role of overridden 'GetHashCode()' methods is to provide a hash code. Therefore, there's no need to create separate documentation for them. Instead, use the '&lt;inheritdoc/&gt;' marker to keep it simple and clean. This ensures the method inherits the documentation from its base class, maintaining consistency and clarity.</value>
  </data>
  <data name="MiKo_2231_MessageFormat" xml:space="preserve">
    <value>Use &lt;inheritdoc/&gt; instead</value>
  </data>
  <data name="MiKo_2231_Title" xml:space="preserve">
    <value>Documentation of overridden 'GetHashCode()' methods shall use '&lt;inheritdoc /&gt;' marker</value>
  </data>
  <data name="MiKo_2232_CodeFixTitle" xml:space="preserve">
    <value>Remove empty &lt;summary&gt;</value>
  </data>
  <data name="MiKo_2232_Description" xml:space="preserve">
    <value>Empty &lt;summary&gt; documentation adds no value and should be removed. It creates clutter and does not aid developers in understanding the code. Proper documentation should always provide meaningful and useful information.</value>
  </data>
  <data name="MiKo_2232_MessageFormat" xml:space="preserve">
    <value>Remove empty &lt;summary&gt;</value>
  </data>
  <data name="MiKo_2232_Title" xml:space="preserve">
    <value>&lt;summary&gt; documentation should not be empty</value>
  </data>
  <data name="MiKo_2233_CodeFixTitle" xml:space="preserve">
    <value>Place on same line</value>
  </data>
  <data name="MiKo_2233_Description" xml:space="preserve">
    <value>Code readability improves when XML tags span a single line. This makes the code clearer and easier to follow.</value>
  </data>
  <data name="MiKo_2233_MessageFormat" xml:space="preserve">
    <value>Place XML tag on single line</value>
  </data>
  <data name="MiKo_2233_Title" xml:space="preserve">
    <value>XML tags should be placed on single line</value>
  </data>
  <data name="MiKo_2300_Description" xml:space="preserve">
    <value>Comments should provide the deeper reasons behind the code, explaining why it is written that way. Avoid detailing how the code works—let the code itself do that.
This approach ensures comments are insightful and add real value by giving context and rationale, helping developers understand the reasoning behind the implementation.</value>
  </data>
  <data name="MiKo_2300_MessageFormat" xml:space="preserve">
    <value>Remove comment or describe why exactly the code is the way it is</value>
  </data>
  <data name="MiKo_2300_Title" xml:space="preserve">
    <value>Comments should explain the 'Why' and not the 'How'</value>
  </data>
  <data name="MiKo_2301_CodeFixTitle" xml:space="preserve">
    <value>Remove obvious AAA comment</value>
  </data>
  <data name="MiKo_2301_Description" xml:space="preserve">
    <value>In test code following the Arrange/Act/Assert style, comments like '// arrange', '// act', and '// assert' are redundant. They do not add any value since the structure is already clear. Removing them keeps your code clean and focused on the actual logic, enhancing readability and maintainability.</value>
  </data>
  <data name="MiKo_2301_MessageFormat" xml:space="preserve">
    <value>Remove obvious AAA comment</value>
  </data>
  <data name="MiKo_2301_Title" xml:space="preserve">
    <value>Do not use obvious comments in AAA-Tests</value>
  </data>
  <data name="MiKo_2302_Description" xml:space="preserve">
    <value>The longer code remains commented out, the more likely it becomes outdated and un-compilable. Since code should be committed to Source Control Systems, developers can rely on the SCS history to retrieve older versions if needed.
Therefore, there's no need to keep commented-out code in the codebase, keeping the code clean and maintainable.</value>
  </data>
  <data name="MiKo_2302_MessageFormat" xml:space="preserve">
    <value>Remove commented out code</value>
  </data>
  <data name="MiKo_2302_Title" xml:space="preserve">
    <value>Do not keep code that is commented out</value>
  </data>
  <data name="MiKo_2303_CodeFixTitle" xml:space="preserve">
    <value>Remove ending period from comment</value>
  </data>
  <data name="MiKo_2303_Description" xml:space="preserve">
    <value>Inline comments are meant for team members, unlike API documentation. They should be concise and to the point, not full sentences or paragraphs. This emphasis on brevity helps maintain clarity within the team, keeping communication streamlined and effective.

This rule contradicts MiKo_2306.</value>
  </data>
  <data name="MiKo_2303_MessageFormat" xml:space="preserve">
    <value>Do not end comment with period</value>
  </data>
  <data name="MiKo_2303_Title" xml:space="preserve">
    <value>Do not end comments with a period</value>
  </data>
  <data name="MiKo_2304_Description" xml:space="preserve">
    <value>Comments should clarify the code and the reasoning behind it, never posing questions. If questions appear in comments, it signals unresolved issues and makes the code hard to maintain over time, as these questions often remain unanswered. Proper documentation ensures long-term clarity and maintainability.</value>
  </data>
  <data name="MiKo_2304_MessageFormat" xml:space="preserve">
    <value>Comment should explain, not ask</value>
  </data>
  <data name="MiKo_2304_Title" xml:space="preserve">
    <value>Do not formulate comments as questions</value>
  </data>
  <data name="MiKo_2305_CodeFixTitle" xml:space="preserve">
    <value>Remove '..' from comment</value>
  </data>
  <data name="MiKo_2305_Description" xml:space="preserve">
    <value>Inline comments are meant for team members, unlike API documentation. They should be concise and contain important information, avoiding double dots at the end. This keeps the communication clear and efficient for quick understanding within the team.</value>
  </data>
  <data name="MiKo_2305_MessageFormat" xml:space="preserve">
    <value>Remove '..' from comment</value>
  </data>
  <data name="MiKo_2305_Title" xml:space="preserve">
    <value>Do not use double periods in comments</value>
  </data>
  <data name="MiKo_2306_Description" xml:space="preserve">
    <value>Inline comments are meant for team members, not for API documentation. They should deliver important information concisely but still be complete sentences. This helps maintain clarity and effective communication within the team. 

This rule contradicts MiKo_2303.</value>
  </data>
  <data name="MiKo_2306_MessageFormat" xml:space="preserve">
    <value>End comment with period</value>
  </data>
  <data name="MiKo_2306_Title" xml:space="preserve">
    <value>End comments with a period</value>
  </data>
  <data name="MiKo_2307_CodeFixTitle" xml:space="preserve">
    <value>Replace with 'failed'</value>
  </data>
  <data name="MiKo_2307_Description" xml:space="preserve">
    <value>To make comments concise and precise, use 'failed' instead of 'was not successful'. This keeps it brief and straight to the point, making it easier for developers to understand quickly.</value>
  </data>
  <data name="MiKo_2307_MessageFormat" xml:space="preserve">
    <value>Use 'failed' instead of 'was not successful'</value>
  </data>
  <data name="MiKo_2307_Title" xml:space="preserve">
    <value>Comments should use the phrase 'failed' instead of 'was not successful'</value>
  </data>
  <data name="MiKo_2308_CodeFixTitle" xml:space="preserve">
    <value>Place comment before code</value>
  </data>
  <data name="MiKo_2308_Description" xml:space="preserve">
    <value>Comments typically describe something related to an operation. Therefore, they should be placed before the operation, not after. This placement ensures that the reader can easily associate the comment with the corresponding operation, eliminating any guesswork about their relation and keeping everything clear and straightforward.</value>
  </data>
  <data name="MiKo_2308_MessageFormat" xml:space="preserve">
    <value>Place comment before code</value>
  </data>
  <data name="MiKo_2308_Title" xml:space="preserve">
    <value>Do not place comment on single line before closing brace but after code</value>
  </data>
  <data name="MiKo_2309_CodeFixTitle" xml:space="preserve">
    <value>Change "n't" to " not"</value>
  </data>
  <data name="MiKo_2309_Description" xml:space="preserve">
    <value>Sometimes, contractions are missed, causing unintentional errors. To prevent this, it's best to avoid them entirely.</value>
  </data>
  <data name="MiKo_2309_MessageFormat" xml:space="preserve">
    <value>Do not use contraction "n't"</value>
  </data>
  <data name="MiKo_2309_Title" xml:space="preserve">
    <value>Comments should not use the contraction "n't"</value>
  </data>
  <data name="MiKo_2310_Description" xml:space="preserve">
    <value>Instead of simply stating *that* an intention exists, documentation should clearly explain *what* the intention actually is. This provides developers with valuable background information, enabling them to make more informed decisions based on that context.
Clear intentions help convey the purpose and reasoning behind code, which is crucial for effective collaboration and maintenance.</value>
  </data>
  <data name="MiKo_2310_MessageFormat" xml:space="preserve">
    <value>Explain what the intention behind actually is</value>
  </data>
  <data name="MiKo_2310_Title" xml:space="preserve">
    <value>Comments should explain the 'Why' and not the 'That'</value>
  </data>
  <data name="MiKo_2311_CodeFixTitle" xml:space="preserve">
    <value>Remove separator comment</value>
  </data>
  <data name="MiKo_2311_Description" xml:space="preserve">
    <value>Comments should provide insight into the rationale behind the code, explaining why it is written that way. Using comments to separate code is not their intended purpose.
Instead, comments should enhance understanding, giving context and reasoning for better comprehension and maintainability and keeping everything focused and informative.</value>
  </data>
  <data name="MiKo_2311_MessageFormat" xml:space="preserve">
    <value>Remove separator comment</value>
  </data>
  <data name="MiKo_2311_Title" xml:space="preserve">
    <value>Do not use separator comments</value>
  </data>
  <data name="MiKo_3000_Description" xml:space="preserve">
    <value>If #region directives are used, avoid any empty #region. They just clutter the code without adding any value. When regions are truly needed, keep them meaningful and populated to ensure the code remains clean and efficient. This approach maintains clarity and organization in the codebase.</value>
  </data>
  <data name="MiKo_3000_MessageFormat" xml:space="preserve">
    <value>Remove empty {0}</value>
  </data>
  <data name="MiKo_3000_Title" xml:space="preserve">
    <value>Do not use empty regions</value>
  </data>
  <data name="MiKo_3001_Description" xml:space="preserve">
    <value>To ease maintenance, use the pre-defined .NET Framework delegate types such as 'Action', 'Func' or 'Expression' instead of custom delegates.</value>
  </data>
  <data name="MiKo_3001_HelpLinkUri" xml:space="preserve">
    <value>https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/events-and-callbacks</value>
  </data>
  <data name="MiKo_3001_MessageFormat" xml:space="preserve">
    <value>Use 'Action', 'Func' or 'Expression' instead</value>
  </data>
  <data name="MiKo_3001_Title" xml:space="preserve">
    <value>Custom delegates should not be used</value>
  </data>
  <data name="MiKo_3002_Description" xml:space="preserve">
    <value>If a class has too many dependencies, it's taking on too many responsibilities and violating the Single Responsibility Principle (SRP). This indicates a need for refactoring the class into smaller, more focused units, ensuring the codebase remains clean and manageable.</value>
  </data>
  <data name="MiKo_3002_MessageFormat" xml:space="preserve">
    <value>Too many MEF dependencies: {1,4} (allowed are max. {2})</value>
  </data>
  <data name="MiKo_3002_Title" xml:space="preserve">
    <value>Classes should not have too many dependencies</value>
  </data>
  <data name="MiKo_3003_Description" xml:space="preserve">
    <value>To ease usage, events should follow the .NET Framework Design Guidelines for Event Design.</value>
  </data>
  <data name="MiKo_3003_HelpLinkUri" xml:space="preserve">
    <value>https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/event</value>
  </data>
  <data name="MiKo_3003_MessageFormat" xml:space="preserve">
    <value>Use 'EventHandler' or 'EventHandler&lt;T&gt;' instead</value>
  </data>
  <data name="MiKo_3003_Title" xml:space="preserve">
    <value>Events should follow .NET Framework Design Guidelines for events</value>
  </data>
  <data name="MiKo_3004_Description" xml:space="preserve">
    <value>EventArgs are meant solely for raising events and passing data to event handlers. If the event data changes between handlers, it leads to unpredictable behavior and potential race conditions.

To prevent this, make EventArgs properties read-only or only privately settable. If you need to set the event data, provide a method that acts as a circuit breaker, allowing the data to be set only once. This approach ensures consistent and reliable behavior.</value>
  </data>
  <data name="MiKo_3004_MessageFormat" xml:space="preserve">
    <value>Make setter private or property read-only</value>
  </data>
  <data name="MiKo_3004_Title" xml:space="preserve">
    <value>Property setters of EventArgs shall be private</value>
  </data>
  <data name="MiKo_3005_Description" xml:space="preserve">
    <value>'Try' methods should follow the Try-Doer pattern to ease maintenance. They should return a Boolean and use the last parameter as an [out] parameter for the result. If successful, the method returns 'true' and provides valid output; otherwise, it returns 'false'.
This pattern keeps methods consistent and predictable, enhancing readability and reliability.</value>
  </data>
  <data name="MiKo_3005_MessageFormat" xml:space="preserve">
    <value>Follow the Trier-Doer-Pattern</value>
  </data>
  <data name="MiKo_3005_Title" xml:space="preserve">
    <value>Methods named 'Try' should follow the Trier-Doer-Pattern</value>
  </data>
  <data name="MiKo_3006_Description" xml:space="preserve">
    <value>To ensure consistency with .NET Framework classes and ease maintenance, place 'CancellationToken' parameters after all other method parameters. This practice keeps your codebase predictable and aligned with established conventions, making it easier for developers to understand and maintain.</value>
  </data>
  <data name="MiKo_3006_MessageFormat" xml:space="preserve">
    <value>Place '{0}' as last parameter</value>
  </data>
  <data name="MiKo_3006_Title" xml:space="preserve">
    <value>'CancellationToken' parameter should be last method parameter</value>
  </data>
  <data name="MiKo_3007_Description" xml:space="preserve">
    <value>To improve maintainability and readability, stick to a single language when writing methods. Avoid mixing LINQ method syntax with declarative query syntax within the same method. This practice ensures consistency, making the code clean, easier to read, and more straightforward to maintain.</value>
  </data>
  <data name="MiKo_3007_MessageFormat" xml:space="preserve">
    <value>Do not mix LINQ syntax</value>
  </data>
  <data name="MiKo_3007_Title" xml:space="preserve">
    <value>Do not use LINQ method and declarative query syntax in same method</value>
  </data>
  <data name="MiKo_3008_Description" xml:space="preserve">
    <value>Methods should avoid returning mutable collections like 'ICollection&lt;T&gt;' since these can be modified from outside the method. Instead, they should return read-only variants like 'IReadOnlyCollection&lt;T&gt;'. This practice ensures data integrity and encapsulation, making the code more secure and predictable.</value>
  </data>
  <data name="MiKo_3008_MessageFormat" xml:space="preserve">
    <value>Use a read-only immutable variant or 'IEnumerable&lt;T&gt;' instead</value>
  </data>
  <data name="MiKo_3008_Title" xml:space="preserve">
    <value>Method should not return collections that can be changed from outside</value>
  </data>
  <data name="MiKo_3009_Description" xml:space="preserve">
    <value>Avoid using anonymous lambdas for methods invoked by commands. They can be hard to read, understand, and maintain. Instead, use named methods with meaningful names. This practice enhances code readability and maintainability, making the code clear and straightforward for developers.</value>
  </data>
  <data name="MiKo_3009_MessageFormat" xml:space="preserve">
    <value>Use named method instead</value>
  </data>
  <data name="MiKo_3009_Title" xml:space="preserve">
    <value>Commands should invoke only named methods and no lambda expressions</value>
  </data>
  <data name="MiKo_3010_Description" xml:space="preserve">
    <value>Certain exceptions are reserved for and thrown by the Common Language Runtime (CLR) and often signal bugs. Developers should not throw these exceptions themselves to maintain code cleanliness and avoid confusion. Following this principle ensures clear and robust code management.</value>
  </data>
  <data name="MiKo_3010_HelpLinkUri" xml:space="preserve">
    <value>https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/using-standard-exception-types</value>
  </data>
  <data name="MiKo_3010_MessageFormat" xml:space="preserve">
    <value>Do not create a '{0}'</value>
  </data>
  <data name="MiKo_3010_Title" xml:space="preserve">
    <value>Do not create or throw reserved exception types</value>
  </data>
  <data name="MiKo_3011_CodeFixTitle" xml:space="preserve">
    <value>Add 'paramName' parameter</value>
  </data>
  <data name="MiKo_3011_Description" xml:space="preserve">
    <value>Thrown ArgumentExceptions (or its subtypes) should always include the name of the parameter that caused the exception. This practice helps other developers quickly identify the problematic argument, facilitating easier debugging and improving overall code maintainability.</value>
  </data>
  <data name="MiKo_3011_HelpLinkUri" xml:space="preserve">
    <value>https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/using-standard-exception-types#argumentexception-argumentnullexception-and-argumentoutofrangeexception</value>
  </data>
  <data name="MiKo_3011_MessageFormat" xml:space="preserve">
    <value>Change 'paramName' parameter to {1}</value>
  </data>
  <data name="MiKo_3011_Title" xml:space="preserve">
    <value>Thrown ArgumentExceptions (or its subtypes) shall provide the correct parameter name</value>
  </data>
  <data name="MiKo_3012_CodeFixTitle" xml:space="preserve">
    <value>Provide actual value</value>
  </data>
  <data name="MiKo_3012_Description" xml:space="preserve">
    <value>Thrown ArgumentOutOfRangeExceptions (or its subtypes) should always include the actual value of the parameter that caused the exception. This practice helps other developers quickly identify the problematic argument, facilitating easier debugging and improving overall code maintainability.</value>
  </data>
  <data name="MiKo_3012_MessageFormat" xml:space="preserve">
    <value>Provide the actual value that causes the exception to be thrown</value>
  </data>
  <data name="MiKo_3012_Title" xml:space="preserve">
    <value>Thrown ArgumentOutOfRangeExceptions (or its subtypes) shall provide the actual value that causes the exception to be thrown</value>
  </data>
  <data name="MiKo_3013_CodeFixTitle" xml:space="preserve">
    <value>Change to 'ArgumentOutOfRangeException'</value>
  </data>
  <data name="MiKo_3013_Description" xml:space="preserve">
    <value>In 'switch' statements, the 'default' clause should throw an ArgumentOutOfRangeException (or subtype) instead of an ArgumentException. This indicates that the argument provided is outside the expected range, ensuring error handling is clear and accurate. Keeps the code precise and informative for developers.</value>
  </data>
  <data name="MiKo_3013_MessageFormat" xml:space="preserve">
    <value>Throw an 'ArgumentOutOfRangeException' instead</value>
  </data>
  <data name="MiKo_3013_Title" xml:space="preserve">
    <value>The 'default' clause in 'switch' statements should throw an ArgumentOutOfRangeException (or subtype), but no ArgumentException</value>
  </data>
  <data name="MiKo_3014_CodeFixTitle" xml:space="preserve">
    <value>Add a default reason</value>
  </data>
  <data name="MiKo_3014_Description" xml:space="preserve">
    <value>For easier maintenance, include a reason when throwing an InvalidOperationException, NotImplementedException, or NotSupportedException. This reason should explain the circumstances of the exception and ideally provide guidance on how to resolve it.
This practice ensures that developers understand why the exception was thrown and how to address it, making the code easier to maintain and debug.</value>
  </data>
  <data name="MiKo_3014_MessageFormat" xml:space="preserve">
    <value>Provide a reason for the thrown '{0}'</value>
  </data>
  <data name="MiKo_3014_Title" xml:space="preserve">
    <value>InvalidOperationException, NotImplementedException and NotSupportedException should have a reason as message</value>
  </data>
  <data name="MiKo_3015_CodeFixTitle" xml:space="preserve">
    <value>Change to 'InvalidOperationException'</value>
  </data>
  <data name="MiKo_3015_Description" xml:space="preserve">
    <value>Avoid throwing ArgumentException (or its subtypes) in parameterless methods. If a method does not take any arguments, or if the failure is not related to the arguments themselves, use InvalidOperationException instead. This keeps exception handling logical and context-appropriate, making the code cleaner and easier to maintain.</value>
  </data>
  <data name="MiKo_3015_HelpLinkUri" xml:space="preserve">
    <value>https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/using-standard-exception-types</value>
  </data>
  <data name="MiKo_3015_MessageFormat" xml:space="preserve">
    <value>Throw an 'InvalidOperationException' instead</value>
  </data>
  <data name="MiKo_3015_Title" xml:space="preserve">
    <value>Throw InvalidOperationExceptions (instead of ArgumentExceptions or its subtypes) to indicate inappropriate states of parameterless methods</value>
  </data>
  <data name="MiKo_3016_CodeFixTitle" xml:space="preserve">
    <value>Change to 'ArgumentException' or 'InvalidOperationException'</value>
  </data>
  <data name="MiKo_3016_Description" xml:space="preserve">
    <value>ArgumentNullExceptions should not be thrown for values of properties returned by parameters.

- If there's an issue with the parameter, throw an ArgumentException.
- If the problem isn't with the parameter itself, throw an InvalidOperationException instead.

This approach ensures that the exception thrown accurately reflects the nature of the issue, making your code more robust and understandable.</value>
  </data>
  <data name="MiKo_3016_HelpLinkUri" xml:space="preserve">
    <value>https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/using-standard-exception-types</value>
  </data>
  <data name="MiKo_3016_MessageFormat" xml:space="preserve">
    <value>Throw an 'ArgumentException' or 'InvalidOperationException' instead</value>
  </data>
  <data name="MiKo_3016_Title" xml:space="preserve">
    <value>Do not throw ArgumentNullException for inappropriate states of property return values</value>
  </data>
  <data name="MiKo_3017_CodeFixTitle" xml:space="preserve">
    <value>Add inner exception</value>
  </data>
  <data name="MiKo_3017_Description" xml:space="preserve">
    <value>When catching an exception and throwing a new one, include the caught exception as an inner exception. This approach makes debugging easier by preserving the original exception, helping to trace the root cause efficiently.</value>
  </data>
  <data name="MiKo_3017_MessageFormat" xml:space="preserve">
    <value>Provide exception as inner exception</value>
  </data>
  <data name="MiKo_3017_Title" xml:space="preserve">
    <value>Do not swallow exceptions when throwing new exceptions</value>
  </data>
  <data name="MiKo_3018_Description" xml:space="preserve">
    <value>Already disposed instances of disposable types should throw ObjectDisposedExceptions when methods are invoked on them. This practice makes it easier to identify bugs, as user code should never access already disposed types. Ensuring this indication helps maintain code integrity and prevents unintended errors.</value>
  </data>
  <data name="MiKo_3018_HelpLinkUri" xml:space="preserve">
    <value>https://learn.microsoft.com/en-us/dotnet/standard/garbage-collection/implementing-dispose</value>
  </data>
  <data name="MiKo_3018_MessageFormat" xml:space="preserve">
    <value>Throw ObjectDisposedException if disposed</value>
  </data>
  <data name="MiKo_3018_Title" xml:space="preserve">
    <value>Throw ObjectDisposedExceptions on publicly visible methods of disposable types</value>
  </data>
  <data name="MiKo_3020_CodeFixTitle" xml:space="preserve">
    <value>Use 'Task.CompletedTask'</value>
  </data>
  <data name="MiKo_3020_Description" xml:space="preserve">
    <value>For better performance, use 'Task.CompletedTask' instead of 'Task.FromResult()', as the returned task is internally cached. This helps improve efficiency in your code.</value>
  </data>
  <data name="MiKo_3020_MessageFormat" xml:space="preserve">
    <value>Use 'Task.CompletedTask' instead</value>
  </data>
  <data name="MiKo_3020_Title" xml:space="preserve">
    <value>Use 'Task.CompletedTask' instead of 'Task.FromResult'</value>
  </data>
  <data name="MiKo_3021_Description" xml:space="preserve">
    <value>If you're using 'Task.Run' to return a Task for a long-running operation, you're likely making a mistake. Instead, use 'Task.Run' to actually call the long-running operation. This approach aligns better with proper asynchronous programming practices and keeps your code efficient and manageable.</value>
  </data>
  <data name="MiKo_3021_HelpLinkUri" xml:space="preserve">
    <value>https://blog.stephencleary.com/2013/11/taskrun-etiquette-examples-dont-use.html</value>
  </data>
  <data name="MiKo_3021_MessageFormat" xml:space="preserve">
    <value>Use '{0}' to invoke method '{1}', but not inside</value>
  </data>
  <data name="MiKo_3021_Title" xml:space="preserve">
    <value>Do not use 'Task.Run' in the implementation</value>
  </data>
  <data name="MiKo_3022_Description" xml:space="preserve">
    <value>If a method returns 'Task&lt;IEnumerable&gt;' or 'Task&lt;IEnumerable&lt;T&gt;&gt;', the enumerable is likely not evaluated until accessed in a foreach or LINQ call. This evaluation likely occurs on another thread (e.g., the main thread), which contradicts the idea of returning a dedicated task.</value>
  </data>
  <data name="MiKo_3022_MessageFormat" xml:space="preserve">
    <value>Do not return '{1}'</value>
  </data>
  <data name="MiKo_3022_Title" xml:space="preserve">
    <value>Do not return Task&lt;IEnumerable&gt; or Task&lt;IEnumerable&lt;T&gt;&gt;</value>
  </data>
  <data name="MiKo_3023_Description" xml:space="preserve">
    <value>Avoid passing around a 'CancellationTokenSource'. Instead, pass the 'CancellationToken' to propagate notifications for canceling operations. This approach keeps the code cleaner and maintains proper encapsulation, ensuring more manageable and readable code.</value>
  </data>
  <data name="MiKo_3023_MessageFormat" xml:space="preserve">
    <value>Use a '{1}' instead</value>
  </data>
  <data name="MiKo_3023_Title" xml:space="preserve">
    <value>Do not use 'CancellationTokenSource' as parameter</value>
  </data>
  <data name="MiKo_3024_Description" xml:space="preserve">
    <value>The [ref] keyword allows changing the storage location of a variable, enabling re-assignment of values and altering the variable.
For reference types, this means the object reference is changed. Consequently, all subsequent access to the variable gets the updated reference, similar to using an [out] parameter.

Generally, this behavior is not desirable. The object reference should remain the same, with only the object itself being altered.</value>
  </data>
  <data name="MiKo_3024_MessageFormat" xml:space="preserve">
    <value>Do not use 'ref'</value>
  </data>
  <data name="MiKo_3024_Title" xml:space="preserve">
    <value>Do not use the [ref] keyword on reference parameters</value>
  </data>
  <data name="MiKo_3025_Description" xml:space="preserve">
    <value>Treat method parameters as read-only. Avoid re-assigning them to other values. If another value is needed, use a local variable instead. This approach keeps the method clean and predictable.</value>
  </data>
  <data name="MiKo_3025_MessageFormat" xml:space="preserve">
    <value>Do not re-assign '{0}'</value>
  </data>
  <data name="MiKo_3025_Title" xml:space="preserve">
    <value>Do not re-assign method parameters</value>
  </data>
  <data name="MiKo_3026_Description" xml:space="preserve">
    <value>Unused parameters clutter the codebase and provide no benefit. They should be removed to keep the code clean and efficient. This ensures the code remains easy to read and maintain, enhancing overall quality and performance. Keeps everything lean and purposeful.</value>
  </data>
  <data name="MiKo_3026_MessageFormat" xml:space="preserve">
    <value>Parameter is not used and can be safely removed</value>
  </data>
  <data name="MiKo_3026_Title" xml:space="preserve">
    <value>Unused parameters should be removed</value>
  </data>
  <data name="MiKo_3027_Description" xml:space="preserve">
    <value>Marking parameters for future use results in poor design. It's uncertain if the parameter will ever be used or if its type will fit future needs. Instead, override methods and add new parameters as needed. This approach maintains clarity and adaptability in your code, avoiding unnecessary clutter and potential issues. Keeps your codebase clean and efficient.</value>
  </data>
  <data name="MiKo_3027_HelpLinkUri" xml:space="preserve">
    <value>https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/parameter-design</value>
  </data>
  <data name="MiKo_3027_MessageFormat" xml:space="preserve">
    <value>Do not reserve '{0}' for future usage</value>
  </data>
  <data name="MiKo_3027_Title" xml:space="preserve">
    <value>Parameters should not be marked to be reserved for future usage</value>
  </data>
  <data name="MiKo_3028_Description" xml:space="preserve">
    <value>To clear a collection, use 'Clear()'. Assigning 'null' to a parameter will not work because the parameter is just a copy (reference) of the original. 'Clear()' effectively empties the collection, maintaining clarity and correct functionality. Keeps everything working as expected.</value>
  </data>
  <data name="MiKo_3028_MessageFormat" xml:space="preserve">
    <value>Do not assign null (is cleanup wanted here?)</value>
  </data>
  <data name="MiKo_3028_Title" xml:space="preserve">
    <value>Do not assign null to lambda parameters</value>
  </data>
  <data name="MiKo_3029_Description" xml:space="preserve">
    <value>Forgetting to unregister from an event can lead to memory leaks, especially when the event is static or belongs to an object with a long lifetime. Always ensure you unregister from events to prevent these issues. Proper event handling maintains memory efficiency and keeps your applications running smoothly.</value>
  </data>
  <data name="MiKo_3029_MessageFormat" xml:space="preserve">
    <value>Assignment causes potential memory leak</value>
  </data>
  <data name="MiKo_3029_Title" xml:space="preserve">
    <value>Event registrations should not cause memory leaks</value>
  </data>
  <data name="MiKo_3030_Description" xml:space="preserve">
    <value>To ease maintenance, methods should make minimal assumptions about the structure or properties of the objects they use. They should work only with objects they receive directly and avoid reaching through these objects to access other objects or their services. This practice keeps methods focused, modular, and easier to maintain.</value>
  </data>
  <data name="MiKo_3030_HelpLinkUri" xml:space="preserve">
    <value>https://en.wikipedia.org/wiki/Law_of_Demeter</value>
  </data>
  <data name="MiKo_3030_MessageFormat" xml:space="preserve">
    <value>Avoid to violate the Law of Demeter</value>
  </data>
  <data name="MiKo_3030_Title" xml:space="preserve">
    <value>Methods should follow the Law of Demeter</value>
  </data>
  <data name="MiKo_3031_Description" xml:space="preserve">
    <value>Avoid implementing 'ICloneable.Clone()' because the method does not specify whether it returns a deep or shallow copy, leading to potential inconsistencies. This ambiguity makes it unreliable, as there's a significant difference between deep and shallow copies. Ensuring clear, predictable behavior in your code is crucial.</value>
  </data>
  <data name="MiKo_3031_MessageFormat" xml:space="preserve">
    <value>Do not implement 'ICloneable.Clone()'</value>
  </data>
  <data name="MiKo_3031_Title" xml:space="preserve">
    <value>ICloneable.Clone() should not be implemented</value>
  </data>
  <data name="MiKo_3032_CodeFixTitle" xml:space="preserve">
    <value>Use 'nameof'</value>
  </data>
  <data name="MiKo_3032_Description" xml:space="preserve">
    <value>Use the 'nameof' operator for property names passed into 'PropertyChangedEventArgs' constructors, instead of strings. This avoids typos and invalid names and makes refactoring easier, as 'nameof' ensures property names are automatically updated during renames, unlike strings.</value>
  </data>
  <data name="MiKo_3032_MessageFormat" xml:space="preserve">
    <value>Use '{1}' instead</value>
  </data>
  <data name="MiKo_3032_Title" xml:space="preserve">
    <value>Use 'nameof' instead of Cinch for names of properties for created 'PropertyChangedEventArgs' instances</value>
  </data>
  <data name="MiKo_3033_CodeFixTitle" xml:space="preserve">
    <value>Use 'nameof'</value>
  </data>
  <data name="MiKo_3033_Description" xml:space="preserve">
    <value>Use the 'nameof' operator for property names passed into 'PropertyChangingEventArgs' and 'PropertyChangedEventArgs' constructors, instead of strings. This avoids typos and invalid names and makes refactoring easier, as 'nameof' ensures property names are automatically updated during renames, unlike strings.</value>
  </data>
  <data name="MiKo_3033_MessageFormat" xml:space="preserve">
    <value>Use 'nameof'</value>
  </data>
  <data name="MiKo_3033_Title" xml:space="preserve">
    <value>Use 'nameof' for names of properties for created 'PropertyChangingEventArgs' and 'PropertyChangedEventArgs' instances</value>
  </data>
  <data name="MiKo_3034_CodeFixTitle" xml:space="preserve">
    <value>Apply [CallerMemberName]</value>
  </data>
  <data name="MiKo_3034_Description" xml:space="preserve">
    <value>When raising 'PropertyChanging' or 'PropertyChanged' events, use the [CallerMemberNameAttribute] to automatically specify the property name. This avoids using string arguments and ensures that the rename refactoring will update the property names correctly. This technique prevents errors and makes the code more maintainable and robust.</value>
  </data>
  <data name="MiKo_3034_MessageFormat" xml:space="preserve">
    <value>Apply [CallerMemberName] attribute</value>
  </data>
  <data name="MiKo_3034_Title" xml:space="preserve">
    <value>PropertyChanged event raiser shall use [CallerMemberName] attribute</value>
  </data>
  <data name="MiKo_3035_Description" xml:space="preserve">
    <value>'WaitOne' methods are used to wait for a specific situation to occur. Waiting indefinitely can lead to deadlocks or livelocks. To prevent this, provide a TimeSpan to 'WaitOne' to allow the wait to time out. This ensures better control and avoids potential blocking issues, keeping the system responsive and efficient.</value>
  </data>
  <data name="MiKo_3035_MessageFormat" xml:space="preserve">
    <value>Provide a timeout value</value>
  </data>
  <data name="MiKo_3035_Title" xml:space="preserve">
    <value>Do not invoke 'WaitOne' methods without timeouts</value>
  </data>
  <data name="MiKo_3036_CodeFixTitle" xml:space="preserve">
    <value>Use factory method</value>
  </data>
  <data name="MiKo_3036_Description" xml:space="preserve">
    <value>The 'TimeSpan' .NET struct has many constructors with varying parameters, making its invocations hard to read. Instead, prefer static factory methods like 'FromMinutes' or 'FromDays'. These are more explicit and easier to understand.

Please note:
It would be even better to use extension methods like 'Minutes()' or 'Days()'. This approach allows for more natural usage, such as ' var x = 5.Days(); '.</value>
  </data>
  <data name="MiKo_3036_MessageFormat" xml:space="preserve">
    <value>Use factory or extension method instead</value>
  </data>
  <data name="MiKo_3036_Title" xml:space="preserve">
    <value>Prefer to use 'TimeSpan' factory methods instead of constructors</value>
  </data>
  <data name="MiKo_3037_Description" xml:space="preserve">
    <value>Classes often have methods like 'WaitForExit' or 'WaitOne' that use an 'int' parameter for timeouts. This 'magic' number makes it unclear if the value is in milliseconds, seconds, etc. To improve readability and maintenance, avoid hard-coding these numbers. Instead, use a 'TimeSpan', which clarifies the duration and is easier to read.

Please note:
It would be even better to use extension methods like 'Minutes()' or 'Days()'. This approach allows for more natural usage, such as ' xyz.WaitForExit(5.Days()); '.</value>
  </data>
  <data name="MiKo_3037_MessageFormat" xml:space="preserve">
    <value>Do not use magic number</value>
  </data>
  <data name="MiKo_3037_Title" xml:space="preserve">
    <value>Do not use magic numbers for timeouts</value>
  </data>
  <data name="MiKo_3038_Description" xml:space="preserve">
    <value>Hard-coded numbers, often called 'magic' numbers, can be unclear. To improve maintenance, avoid them. Instead, define these numbers as constants with meaningful names.
This approach makes the code easier to read and understand, helping developers grasp the numbers' purpose and context.</value>
  </data>
  <data name="MiKo_3038_MessageFormat" xml:space="preserve">
    <value>Introduce constant for magic number {1}</value>
  </data>
  <data name="MiKo_3038_Title" xml:space="preserve">
    <value>Do not use magic numbers</value>
  </data>
  <data name="MiKo_3039_Description" xml:space="preserve">
    <value>Properties using LINQ internally can behave unpredictably when accessed multiple times. Properties are meant to access fields with some safety checks, so this behavior contradicts their purpose and can cause unwanted side effects.
Instead, use methods to make it clear that the behavior might differ between calls. This keeps your code predictable and maintains the intended functionality.</value>
  </data>
  <data name="MiKo_3039_MessageFormat" xml:space="preserve">
    <value>Do not use '{1}' inside property</value>
  </data>
  <data name="MiKo_3039_Title" xml:space="preserve">
    <value>Properties should not use Linq or yield</value>
  </data>
  <data name="MiKo_3040_Description" xml:space="preserve">
    <value>To ease maintenance and improve readability, avoid using Booleans as parameters unless absolutely sure the value will never exceed two options. Instead, use an Enum. This practice ensures the code remains clear, flexible, and easier to maintain.</value>
  </data>
  <data name="MiKo_3040_HelpLinkUri" xml:space="preserve">
    <value>https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/parameter-design</value>
  </data>
  <data name="MiKo_3040_MessageFormat" xml:space="preserve">
    <value>Use an Enum instead</value>
  </data>
  <data name="MiKo_3040_Title" xml:space="preserve">
    <value>Do not use Booleans unless you are absolutely sure that you will never ever need more than 2 values</value>
  </data>
  <data name="MiKo_3041_Description" xml:space="preserve">
    <value>Avoid using delegates like 'Action' or 'Func' in 'EventArgs'. The callee must understand exactly how the delegate behaves. Failures within the delegate are difficult to debug, as exceptions are thrown in unrelated areas.</value>
  </data>
  <data name="MiKo_3041_MessageFormat" xml:space="preserve">
    <value>Do not use a delegate</value>
  </data>
  <data name="MiKo_3041_Title" xml:space="preserve">
    <value>EventArgs shall not use delegates</value>
  </data>
  <data name="MiKo_3042_Description" xml:space="preserve">
    <value>EventArgs are standalone contracts. They should not implement any additional interfaces. This keeps their purpose clear and their usage straightforward, avoiding unnecessary complexity. Keeps the code clean and maintains the integrity of the event handling mechanism.</value>
  </data>
  <data name="MiKo_3042_MessageFormat" xml:space="preserve">
    <value>Do not implement interface</value>
  </data>
  <data name="MiKo_3042_Title" xml:space="preserve">
    <value>EventArgs shall not implement interfaces</value>
  </data>
  <data name="MiKo_3043_CodeFixTitle" xml:space="preserve">
    <value>Use 'nameof'</value>
  </data>
  <data name="MiKo_3043_Description" xml:space="preserve">
    <value>Use the 'nameof' operator for event names registered on the 'WeakEventManager' instead of strings. This prevents typos, ensures valid names, and makes rename refactoring much easier, as 'nameof' ensures property names are automatically updated during renames, unlike strings.</value>
  </data>
  <data name="MiKo_3043_MessageFormat" xml:space="preserve">
    <value>Use 'nameof'</value>
  </data>
  <data name="MiKo_3043_Title" xml:space="preserve">
    <value>Use 'nameof' for WeakEventManager event (de-)registrations</value>
  </data>
  <data name="MiKo_3044_CodeFixTitle" xml:space="preserve">
    <value>Use 'nameof'</value>
  </data>
  <data name="MiKo_3044_Description" xml:space="preserve">
    <value>Use the 'nameof' operator to compare property names provided by 'PropertyChangingEventArgs' and 'PropertyChangedEventArgs'. This avoids typos and invalid names and makes refactoring easier, as 'nameof' ensures property names are automatically updated during renames, unlike strings.</value>
  </data>
  <data name="MiKo_3044_MessageFormat" xml:space="preserve">
    <value>Use 'nameof'</value>
  </data>
  <data name="MiKo_3044_Title" xml:space="preserve">
    <value>Use 'nameof' to compare property names of 'PropertyChangingEventArgs' and 'PropertyChangedEventArgs'</value>
  </data>
  <data name="MiKo_3045_CodeFixTitle" xml:space="preserve">
    <value>Use 'nameof'</value>
  </data>
  <data name="MiKo_3045_Description" xml:space="preserve">
    <value>Use the 'nameof' operator for event names registered on the 'EventManager' instead of strings. This prevents typos, ensures valid names, and makes rename refactoring much easier, as 'nameof' ensures property names are automatically updated during renames, unlike strings.</value>
  </data>
  <data name="MiKo_3045_MessageFormat" xml:space="preserve">
    <value>Use 'nameof'</value>
  </data>
  <data name="MiKo_3045_Title" xml:space="preserve">
    <value>Use 'nameof' for EventManager event registrations</value>
  </data>
  <data name="MiKo_3046_CodeFixTitle" xml:space="preserve">
    <value>Use 'nameof'</value>
  </data>
  <data name="MiKo_3046_Description" xml:space="preserve">
    <value>Use the 'nameof' operator instead of strings to define the properties for event raising methods like 'OnPropertyChanged'. This prevents typos, ensures valid names, and makes rename refactoring much easier, as 'nameof' ensures property names are automatically updated during renames, unlike strings.</value>
  </data>
  <data name="MiKo_3046_MessageFormat" xml:space="preserve">
    <value>Use 'nameof'</value>
  </data>
  <data name="MiKo_3046_Title" xml:space="preserve">
    <value>Use 'nameof' for property names of property raising methods</value>
  </data>
  <data name="MiKo_3047_CodeFixTitle" xml:space="preserve">
    <value>Use 'nameof'</value>
  </data>
  <data name="MiKo_3047_Description" xml:space="preserve">
    <value>Use the 'nameof' operator instead of strings to define the properties for any applied [ContentProperty] attribute. This prevents typos, ensures valid names, and makes rename refactoring much easier, as 'nameof' ensures property names are automatically updated during renames, unlike strings.</value>
  </data>
  <data name="MiKo_3047_MessageFormat" xml:space="preserve">
    <value>Use 'nameof'</value>
  </data>
  <data name="MiKo_3047_Title" xml:space="preserve">
    <value>Use 'nameof' for applied [ContentProperty] attributes</value>
  </data>
  <data name="MiKo_3048_Description" xml:space="preserve">
    <value>Decorate implementations of the IValueConverter interface with the [ValueConversion] attribute to signal to development tools the data types involved in a conversion. This practice enhances clarity and improves tool support, making the code easier to work with and maintain.</value>
  </data>
  <data name="MiKo_3048_MessageFormat" xml:space="preserve">
    <value>Apply the [ValueConversion] attribute</value>
  </data>
  <data name="MiKo_3048_Title" xml:space="preserve">
    <value>ValueConverters shall have the [ValueConversion] attribute applied</value>
  </data>
  <data name="MiKo_3049_Description" xml:space="preserve">
    <value>In C#, you might need a string description for an enum value. Achieve this by using the 'System.ComponentModel.DescriptionAttribute' to decorate the enum member. This method associates descriptive text with enum values, enhancing both readability and usability.</value>
  </data>
  <data name="MiKo_3049_MessageFormat" xml:space="preserve">
    <value>Apply a [Description] attribute with a proper description</value>
  </data>
  <data name="MiKo_3049_Title" xml:space="preserve">
    <value>Enum members shall have the [Description] attribute applied</value>
  </data>
  <data name="MiKo_3050_CodeFixTitle" xml:space="preserve">
    <value>Make DependencyProperty 'public static readonly'</value>
  </data>
  <data name="MiKo_3050_Description" xml:space="preserve">
    <value>Fields that are the back of a DependencyProperty should be made 'public static readonly' to allow the .NET framework and other clients to find and access those fields.</value>
  </data>
  <data name="MiKo_3050_HelpLinkUri" xml:space="preserve">
    <value>https://learn.microsoft.com/en-us/dotnet/framework/wpf/advanced/how-to-implement-a-dependency-property</value>
  </data>
  <data name="MiKo_3050_MessageFormat" xml:space="preserve">
    <value>Make it 'public static readonly'</value>
  </data>
  <data name="MiKo_3050_Title" xml:space="preserve">
    <value>DependencyProperty fields should be 'public static readonly'</value>
  </data>
  <data name="MiKo_3051_CodeFixTitle" xml:space="preserve">
    <value>Use 'nameof'</value>
  </data>
  <data name="MiKo_3051_Description" xml:space="preserve">
    <value>To avoid typos, register fields backing a DependencyProperty using 'DependencyProperty.Register()' and the 'nameof' operator. Ensure you provide the correct property names, property types, and owning types.</value>
  </data>
  <data name="MiKo_3051_HelpLinkUri" xml:space="preserve">
    <value>https://learn.microsoft.com/en-us/dotnet/framework/wpf/advanced/how-to-implement-a-dependency-property</value>
  </data>
  <data name="MiKo_3051_MessageFormat" xml:space="preserve">
    <value>Use '{1}' instead</value>
  </data>
  <data name="MiKo_3051_Title" xml:space="preserve">
    <value>DependencyProperty fields should be properly registered</value>
  </data>
  <data name="MiKo_3052_CodeFixTitle" xml:space="preserve">
    <value>Make DependencyPropertyKey 'private static readonly'</value>
  </data>
  <data name="MiKo_3052_Description" xml:space="preserve">
    <value>Make fields backing a DependencyPropertyKey non-public, static, and readonly. This prevents clients from finding and accessing these fields, ensuring your code stays secure and well-encapsulated.</value>
  </data>
  <data name="MiKo_3052_HelpLinkUri" xml:space="preserve">
    <value>https://learn.microsoft.com/en-us/dotnet/api/system.windows.dependencypropertykey</value>
  </data>
  <data name="MiKo_3052_MessageFormat" xml:space="preserve">
    <value>Make it non-public 'static readonly'</value>
  </data>
  <data name="MiKo_3052_Title" xml:space="preserve">
    <value>DependencyPropertyKey fields should be non-public 'static readonly'</value>
  </data>
  <data name="MiKo_3053_Description" xml:space="preserve">
    <value>To prevent typos, register fields that are the key of a DependencyProperty using 'DependencyProperty.RegisterReadOnly()' and the 'nameof' operator. Also, ensure you provide the correct property names, property types, and owning types.</value>
  </data>
  <data name="MiKo_3053_HelpLinkUri" xml:space="preserve">
    <value>https://learn.microsoft.com/en-us/dotnet/api/system.windows.dependencyproperty.registerreadonly</value>
  </data>
  <data name="MiKo_3053_MessageFormat" xml:space="preserve">
    <value>Use '{1}' instead</value>
  </data>
  <data name="MiKo_3053_Title" xml:space="preserve">
    <value>DependencyPropertyKey fields should be properly registered</value>
  </data>
  <data name="MiKo_3054_CodeFixTitle" xml:space="preserve">
    <value>Expose DependencyProperty identifier</value>
  </data>
  <data name="MiKo_3054_Description" xml:space="preserve">
    <value>Read-only dependency properties are defined by DependencyPropertyKey fields and should remain non-public. To make them accessible, expose a dependency property identifier for the read-only property. Do this by exposing the value of 'DependencyPropertyKey.DependencyProperty' as a 'public static readonly' field in the specific class.
This maintains encapsulation while allowing access to the property.</value>
  </data>
  <data name="MiKo_3054_HelpLinkUri" xml:space="preserve">
    <value>https://learn.microsoft.com/en-us/dotnet/api/system.windows.dependencyproperty.registerreadonly</value>
  </data>
  <data name="MiKo_3054_MessageFormat" xml:space="preserve">
    <value>Expose a DependencyProperty identifier for the read-only dependency property '{0}'</value>
  </data>
  <data name="MiKo_3054_Title" xml:space="preserve">
    <value>A read-only DependencyProperty should have an exposed DependencyProperty identifier</value>
  </data>
  <data name="MiKo_3055_Description" xml:space="preserve">
    <value>In WPF, view models use bindings. If a view model does not implement 'INotifyPropertyChanged', WPF uses reflection to detect changes, causing a memory leak. The binding instance (descriptor) stays in a static hash table for the app's lifetime.
To avoid this, make sure types implement 'INotifyPropertyChanged' and raise the corresponding events when changes occur.</value>
  </data>
  <data name="MiKo_3055_MessageFormat" xml:space="preserve">
    <value>Implement INotifyPropertyChanged to avoid WPF binding memory leaks</value>
  </data>
  <data name="MiKo_3055_Title" xml:space="preserve">
    <value>ViewModels should implement INotifyPropertyChanged</value>
  </data>
  <data name="MiKo_3060_CodeFixTitle" xml:space="preserve">
    <value>Remove Assert call</value>
  </data>
  <data name="MiKo_3060_Description" xml:space="preserve">
    <value>Using 'Debug.Assert()' or 'Trace.Assert()' to ensure something has several drawbacks:

1. 'Debug.Assert()' does not work in Release mode, while 'Trace.Assert()' does.

2. These assertions only confirm the situation; no action can be taken.

3. There is no failure handling mechanism.

4. Calling code is unaware of the issue and cannot handle it properly.

Instead of using 'Debug.Assert()' or 'Trace.Assert()', throw an exception like 'InvalidOperationException'. This provides proper failure handling and informs the calling code.

Never use 'Debug.Assert()' or 'Trace.Assert()' in (unit) test code. Let the test fail naturally in cases where these assertions would apply, as that's the purpose of test code.</value>
  </data>
  <data name="MiKo_3060_MessageFormat" xml:space="preserve">
    <value>Do not use '{1}'</value>
  </data>
  <data name="MiKo_3060_Title" xml:space="preserve">
    <value>Debug.Assert or Trace.Assert shall not be used</value>
  </data>
  <data name="MiKo_3061_Description" xml:space="preserve">
    <value>Loggers are often requested via a type, which results in logs lacking useful categories. Developers might control log output using different severities (Debug, Info, etc.), leading to cluttered logs. This makes it unclear which log statement belongs to which category.

Instead, request the logger via a string as the category. This approach ensures clear and organized logs, making analysis easier and more effective.</value>
  </data>
  <data name="MiKo_3061_MessageFormat" xml:space="preserve">
    <value>Use a string as category instead</value>
  </data>
  <data name="MiKo_3061_Title" xml:space="preserve">
    <value>Loggers shall use a proper log category</value>
  </data>
  <data name="MiKo_3062_CodeFixTitle" xml:space="preserve">
    <value>End log message with colon</value>
  </data>
  <data name="MiKo_3062_Description" xml:space="preserve">
    <value>End log messages that log exceptions with a colon. This clearly indicates that an exception follows, making it easier for developers to identify and understand the context.</value>
  </data>
  <data name="MiKo_3062_MessageFormat" xml:space="preserve">
    <value>End log message with colon</value>
  </data>
  <data name="MiKo_3062_Title" xml:space="preserve">
    <value>End log messages for exceptions with a colon</value>
  </data>
  <data name="MiKo_3063_CodeFixTitle" xml:space="preserve">
    <value>End log message with dot</value>
  </data>
  <data name="MiKo_3063_Description" xml:space="preserve">
    <value>End log messages that do not include exceptions with a dot. This keeps the focus clear and consistent, ensuring that logs are easy to read and understand. It helps distinguish between general log messages and those that include exception details, maintaining clarity in your logging practices.</value>
  </data>
  <data name="MiKo_3063_MessageFormat" xml:space="preserve">
    <value>End log message with dot</value>
  </data>
  <data name="MiKo_3063_Title" xml:space="preserve">
    <value>End non-exceptional log messages with a dot</value>
  </data>
  <data name="MiKo_3064_CodeFixTitle" xml:space="preserve">
    <value>Change "n't" to " not"</value>
  </data>
  <data name="MiKo_3064_Description" xml:space="preserve">
    <value>Sometimes, contractions are missed, causing unintentional errors. To prevent this, it's best to avoid them entirely.</value>
  </data>
  <data name="MiKo_3064_MessageFormat" xml:space="preserve">
    <value>Do not use contraction "n't"</value>
  </data>
  <data name="MiKo_3064_Title" xml:space="preserve">
    <value>Log messages should not use the contraction "n't"</value>
  </data>
  <data name="MiKo_3065_CodeFixTitle" xml:space="preserve">
    <value>Change interpolated string into normal string</value>
  </data>
  <data name="MiKo_3065_Description" xml:space="preserve">
    <value>The Microsoft Logging API supports Semantic or Structured Logging via message templates, which include named placeholders for arguments. These templates look like interpolated strings but without the '$' and with added arguments, which can be confusing.

The arguments are passed to the logging system, not just the formatted message. This allows logging providers to store parameter values as fields for filtering.

Using interpolated strings instead of message templates prevents this filtering and contradicts the Semantic or Structured Logging approach.</value>
  </data>
  <data name="MiKo_3065_MessageFormat" xml:space="preserve">
    <value>Do not use interpolated string</value>
  </data>
  <data name="MiKo_3065_Title" xml:space="preserve">
    <value>Microsoft Logging calls should not use interpolated strings</value>
  </data>
  <data name="MiKo_3070_Description" xml:space="preserve">
    <value>Methods returning 'IEnumerable' are meant for foreach loops or LINQ queries. These methods should never return null, as it could lead to NullReferenceException or ArgumentNullException. Ensuring they do not return null keeps your code predictable and safe from unexpected runtime errors.</value>
  </data>
  <data name="MiKo_3070_MessageFormat" xml:space="preserve">
    <value>Do not return null</value>
  </data>
  <data name="MiKo_3070_Title" xml:space="preserve">
    <value>Do not return null for an IEnumerable</value>
  </data>
  <data name="MiKo_3071_Description" xml:space="preserve">
    <value>Methods that return 'Task' are intended for async calls. These methods should never return null, as this could lead to a NullReferenceException. Ensuring they do not return null keeps your code predictable and safe from unexpected runtime errors, maintaining reliability and smooth functionality.</value>
  </data>
  <data name="MiKo_3071_MessageFormat" xml:space="preserve">
    <value>Do not return null</value>
  </data>
  <data name="MiKo_3071_Title" xml:space="preserve">
    <value>Do not return null for a Task</value>
  </data>
  <data name="MiKo_3072_Description" xml:space="preserve">
    <value>Public methods should return interfaces like 'IList&lt;&gt;' or 'IDictionary&lt;&gt;' instead of concrete types like 'List&lt;&gt;' or 'Dictionary&lt;&gt;'. This approach provides flexibility, allowing you to change the implementation of the return value without affecting the method's signature, keeping your code adaptable and maintainable.</value>
  </data>
  <data name="MiKo_3072_MessageFormat" xml:space="preserve">
    <value>Do not return {1}&lt;&gt;</value>
  </data>
  <data name="MiKo_3072_Title" xml:space="preserve">
    <value>Non-private methods should not return 'List&lt;&gt;' or 'Dictionary&lt;&gt;'</value>
  </data>
  <data name="MiKo_3073_Description" xml:space="preserve">
    <value>Avoid returning from within a constructor. Constructors should execute fully, ensuring the objects are completely initialized. Partial initialization can lead to unpredictable behavior and inconsistencies.</value>
  </data>
  <data name="MiKo_3073_MessageFormat" xml:space="preserve">
    <value>Do not return inside constructor</value>
  </data>
  <data name="MiKo_3073_Title" xml:space="preserve">
    <value>Do not leave objects partially initialized</value>
  </data>
  <data name="MiKo_3074_Description" xml:space="preserve">
    <value>A constructor's main purpose is to create an initialized instance of its specific type. It should not be used to create instances of other types.
Therefore, including [ref] or [out] parameters in a constructor contradicts this concept. These parameters should not exist to provide instances of other types, in addition to the instance created and initialized by the constructor.</value>
  </data>
  <data name="MiKo_3074_MessageFormat" xml:space="preserve">
    <value>Do not use '{0}'</value>
  </data>
  <data name="MiKo_3074_Title" xml:space="preserve">
    <value>Do not define 'ref' or 'out' parameters on constructors</value>
  </data>
  <data name="MiKo_3075_CodeFixTitle" xml:space="preserve">
    <value>Seal class or make it static</value>
  </data>
  <data name="MiKo_3075_Description" xml:space="preserve">
    <value>To ease maintenance, internal and private types should be either 'static' or 'sealed' unless there's a need for derivation.

These types can be modified later if derivation becomes necessary. Keeping them static or sealed by default ensures clearer and more manageable code, still being adaptable for future changes.</value>
  </data>
  <data name="MiKo_3075_MessageFormat" xml:space="preserve">
    <value>Seal class or make it static</value>
  </data>
  <data name="MiKo_3075_Title" xml:space="preserve">
    <value>Internal and private types should be either static or sealed unless derivation from them is required</value>
  </data>
  <data name="MiKo_3076_Description" xml:space="preserve">
    <value>If a static member initializer uses another member defined below or in another type part, it might get initialized with the wrong value at runtime. This happens because the static member initializes before the other referenced member.

This can cause subtle bugs like 'TypeInitializerException's or incorrect values.</value>
  </data>
  <data name="MiKo_3076_MessageFormat" xml:space="preserve">
    <value>Static member initializer refers to static member(s) {1} below or in other type part</value>
  </data>
  <data name="MiKo_3076_Title" xml:space="preserve">
    <value>Do not initialize static member with static member below or in other type part</value>
  </data>
  <data name="MiKo_3077_CodeFixTitle" xml:space="preserve">
    <value>Apply a default value</value>
  </data>
  <data name="MiKo_3077_Description" xml:space="preserve">
    <value>Explicitly setting values for properties that return an Enum helps easily identify the default value and any changes.
This practice aids in ensuring the value is the intended one, keeping the code clear and helping to spot unintended changes quickly.</value>
  </data>
  <data name="MiKo_3077_MessageFormat" xml:space="preserve">
    <value>Set a default value</value>
  </data>
  <data name="MiKo_3077_Title" xml:space="preserve">
    <value>Properties that return an Enum should have a default value</value>
  </data>
  <data name="MiKo_3078_CodeFixTitle" xml:space="preserve">
    <value>Apply a default value</value>
  </data>
  <data name="MiKo_3078_Description" xml:space="preserve">
    <value>Explicitly setting values for 'Enum' members prevents changes in meaning when the Enum is modified, whether by adding, removing, renaming, or reordering values.
This approach ensures stability and clarity, keeping the Enum's behavior consistent as it evolves. It makes everything reliable and easy to understand.</value>
  </data>
  <data name="MiKo_3078_MessageFormat" xml:space="preserve">
    <value>Set a default value</value>
  </data>
  <data name="MiKo_3078_Title" xml:space="preserve">
    <value>Enum members should have a default value</value>
  </data>
  <data name="MiKo_3079_CodeFixTitle" xml:space="preserve">
    <value>Replace with hex value</value>
  </data>
  <data name="MiKo_3079_Description" xml:space="preserve">
    <value>Write HResults in hexadecimal, not as negative integers. It's much easier to recognize and search for '0x80070005' than '-2147024891'. Keeps the code clean and user-friendly.</value>
  </data>
  <data name="MiKo_3079_MessageFormat" xml:space="preserve">
    <value>Use 'unchecked((int)0x{1})' instead for HResult</value>
  </data>
  <data name="MiKo_3079_Title" xml:space="preserve">
    <value>HResults should be written in hexadecimal</value>
  </data>
  <data name="MiKo_3080_Description" xml:space="preserve">
    <value>Using switch statements to assign variables within methods increases complexity and reduces readability. Simplify this by refactoring the switch statement into its own method.
Let each section of the switch return values directly, instead of assigning them to a shared variable and using break statements.
This approach enhances clarity and maintainability.</value>
  </data>
  <data name="MiKo_3080_MessageFormat" xml:space="preserve">
    <value>Place switch statement in separate method and return value within case blocks</value>
  </data>
  <data name="MiKo_3080_Title" xml:space="preserve">
    <value>Use 'switch ... return' instead of 'switch ... break' when assigning variables</value>
  </data>
  <data name="MiKo_3081_CodeFixTitle" xml:space="preserve">
    <value>Apply 'is false' pattern</value>
  </data>
  <data name="MiKo_3081_Description" xml:space="preserve">
    <value>Logical NOT conditions using '!' can be hard to recognize. Use is false instead; it's easier to read and understand.</value>
  </data>
  <data name="MiKo_3081_MessageFormat" xml:space="preserve">
    <value>Use pattern 'is false' instead of ' ! '</value>
  </data>
  <data name="MiKo_3081_Title" xml:space="preserve">
    <value>Prefer pattern matching over a logical NOT condition</value>
  </data>
  <data name="MiKo_3082_CodeFixTitle" xml:space="preserve">
    <value>Apply 'is' pattern</value>
  </data>
  <data name="MiKo_3082_Description" xml:space="preserve">
    <value>Using the 'is' pattern matching for logical comparisons is more natural and easier to read than the '==' equality operator. This approach enhances code clarity and comprehension, making your code cleaner and more intuitive.</value>
  </data>
  <data name="MiKo_3082_MessageFormat" xml:space="preserve">
    <value>Use 'is' instead of '=='</value>
  </data>
  <data name="MiKo_3082_Title" xml:space="preserve">
    <value>Prefer pattern matching over a logical comparison with 'true' or 'false'</value>
  </data>
  <data name="MiKo_3083_CodeFixTitle" xml:space="preserve">
    <value>Apply 'is null' pattern</value>
  </data>
  <data name="MiKo_3083_Description" xml:space="preserve">
    <value>Using 'is' pattern matching for null checks is more natural and easier to read than the '==' equality operator. This approach enhances code clarity and comprehension, making your code cleaner and more intuitive.</value>
  </data>
  <data name="MiKo_3083_MessageFormat" xml:space="preserve">
    <value>Use 'is' instead of '=='</value>
  </data>
  <data name="MiKo_3083_Title" xml:space="preserve">
    <value>Prefer pattern matching for null checks</value>
  </data>
  <data name="MiKo_3084_CodeFixTitle" xml:space="preserve">
    <value>Place constant value on right side</value>
  </data>
  <data name="MiKo_3084_Description" xml:space="preserve">
    <value>To increase readability, place constants on the right side of an operator, not the left. This makes the code look more intuitive and easier to understand.</value>
  </data>
  <data name="MiKo_3084_MessageFormat" xml:space="preserve">
    <value>Place it on right side of '{1}'</value>
  </data>
  <data name="MiKo_3084_Title" xml:space="preserve">
    <value>Do not place constants on the left side for comparisons</value>
  </data>
  <data name="MiKo_3085_Description" xml:space="preserve">
    <value>Long conditional statements are hard to read and maintain. Keep them short for easy understanding at a glance, or refactor into if-else statements for clarity. This approach keeps your code clean and maintainable.</value>
  </data>
  <data name="MiKo_3085_MessageFormat" xml:space="preserve">
    <value>Shorten conditional or use 'if ... else ...' instead</value>
  </data>
  <data name="MiKo_3085_Title" xml:space="preserve">
    <value>Conditional statements should be short</value>
  </data>
  <data name="MiKo_3086_Description" xml:space="preserve">
    <value>Nested conditional or coalesce statements are difficult to read and understand. Avoid nesting them. Instead, use if-else statements to improve clarity. This approach keeps your code clean and maintainable.</value>
  </data>
  <data name="MiKo_3086_MessageFormat" xml:space="preserve">
    <value>Do not nest conditional</value>
  </data>
  <data name="MiKo_3086_Title" xml:space="preserve">
    <value>Do not nest conditional statements</value>
  </data>
  <data name="MiKo_3087_Description" xml:space="preserve">
    <value>Complex conditions with negative logic are difficult to understand, cumbersome, and error-prone. Change them to positive logic to improve readability, simplify the code, and reduce errors. This approach ensures your code is clear and easier to maintain.</value>
  </data>
  <data name="MiKo_3087_MessageFormat" xml:space="preserve">
    <value>Condition is difficult to understand, simplify or convert to positive logic</value>
  </data>
  <data name="MiKo_3087_Title" xml:space="preserve">
    <value>Do not use negative complex conditions</value>
  </data>
  <data name="MiKo_3088_CodeFixTitle" xml:space="preserve">
    <value>Apply 'is not null' pattern</value>
  </data>
  <data name="MiKo_3088_Description" xml:space="preserve">
    <value>Null checks using 'is not' pattern matching are more intuitive and easier to read than the '!=' inequality operator. This makes them the preferred choice for clarity and comprehension.</value>
  </data>
  <data name="MiKo_3088_MessageFormat" xml:space="preserve">
    <value>Use 'is not' instead of '!='</value>
  </data>
  <data name="MiKo_3088_Title" xml:space="preserve">
    <value>Prefer pattern matching for not-null checks</value>
  </data>
  <data name="MiKo_3089_CodeFixTitle" xml:space="preserve">
    <value>Convert property pattern condition into normal condition</value>
  </data>
  <data name="MiKo_3089_Description" xml:space="preserve">
    <value>Normal conditions are easier to understand than property pattern conditions with constants. Therefore, convert these property conditions into normal ones. This approach keeps your code clear and readable.</value>
  </data>
  <data name="MiKo_3089_MessageFormat" xml:space="preserve">
    <value>Convert property pattern condition into normal condition</value>
  </data>
  <data name="MiKo_3089_Title" xml:space="preserve">
    <value>Do not use simple constant property patterns as conditions of 'if' statements</value>
  </data>
  <data name="MiKo_3090_Description" xml:space="preserve">
    <value>Throw exceptions inside try or catch blocks, not within finally blocks. Finally blocks are meant for cleanup or to ensure certain code runs regardless of other factors. This maintains their intended purpose and keeps your code clear.</value>
  </data>
  <data name="MiKo_3090_MessageFormat" xml:space="preserve">
    <value>Do not throw from finally block</value>
  </data>
  <data name="MiKo_3090_Title" xml:space="preserve">
    <value>Do not throw exceptions in finally blocks</value>
  </data>
  <data name="MiKo_3091_Description" xml:space="preserve">
    <value>Raise events within try or catch blocks, not finally blocks. Finally blocks are meant for cleanup, ensuring certain code always runs. This maintains their intended purpose and keeps your code clear.</value>
  </data>
  <data name="MiKo_3091_MessageFormat" xml:space="preserve">
    <value>Do not raise '{1}' from finally block</value>
  </data>
  <data name="MiKo_3091_Title" xml:space="preserve">
    <value>Do not raise events in finally blocks</value>
  </data>
  <data name="MiKo_3092_Description" xml:space="preserve">
    <value>To avoid deadlocks, do not raise events inside lock statements. Instead, collect the event handlers and raise the event outside the lock. This practice ensures smooth and efficient code execution while avoiding potential deadlocks.</value>
  </data>
  <data name="MiKo_3092_MessageFormat" xml:space="preserve">
    <value>Do not raise event inside lock</value>
  </data>
  <data name="MiKo_3092_Title" xml:space="preserve">
    <value>Do not raise events in locks</value>
  </data>
  <data name="MiKo_3093_Description" xml:space="preserve">
    <value>To avoid deadlocks, do not invoke delegates within lock statements. Collect the necessary information inside the lock, then invoke the delegate outside the lock. This practice ensures smooth and efficient code execution while avoiding potential deadlocks.</value>
  </data>
  <data name="MiKo_3093_MessageFormat" xml:space="preserve">
    <value>Do not invoke delegate inside lock</value>
  </data>
  <data name="MiKo_3093_Title" xml:space="preserve">
    <value>Do not invoke delegates inside locks</value>
  </data>
  <data name="MiKo_3094_Description" xml:space="preserve">
    <value>To avoid deadlocks, do not invoke methods or properties of parameters within lock statements. This practice ensures smooth and efficient code execution while avoiding potential deadlocks.</value>
  </data>
  <data name="MiKo_3094_MessageFormat" xml:space="preserve">
    <value>Do not invoke method or property inside lock</value>
  </data>
  <data name="MiKo_3094_Title" xml:space="preserve">
    <value>Do not invoke methods or properties of parameters inside locks</value>
  </data>
  <data name="MiKo_3095_Description" xml:space="preserve">
    <value>Empty code blocks should include a comment explaining why they are empty. This helps developers understand the reason and ensures the block is not empty by mistake.</value>
  </data>
  <data name="MiKo_3095_MessageFormat" xml:space="preserve">
    <value>Provide a comment that reasons why the block is empty</value>
  </data>
  <data name="MiKo_3095_Title" xml:space="preserve">
    <value>Code blocks should not be empty</value>
  </data>
  <data name="MiKo_3096_Description" xml:space="preserve">
    <value>For switch statements with many cases that map values, use a dictionary instead. This approach makes the code easier to read and maintain.</value>
  </data>
  <data name="MiKo_3096_MessageFormat" xml:space="preserve">
    <value>Use dictionary as map instead of switch</value>
  </data>
  <data name="MiKo_3096_Title" xml:space="preserve">
    <value>Use dictionaries instead of large switch statements</value>
  </data>
  <data name="MiKo_3097_Description" xml:space="preserve">
    <value>Casting a value to a specific type and returning it when the return type is 'object' offers no benefit. The cast is unnecessary and adds complexity without any gain.</value>
  </data>
  <data name="MiKo_3097_MessageFormat" xml:space="preserve">
    <value>Do not cast to type when returning object</value>
  </data>
  <data name="MiKo_3097_Title" xml:space="preserve">
    <value>Do not cast to type and return object</value>
  </data>
  <data name="MiKo_3098_Description" xml:space="preserve">
    <value>When suppressing messages with the [SuppressMessage] attribute, a justification must be provided. This justification should explain why the message was suppressed, helping future developers understand the reasoning. Just writing "Reviewed." or providing no explanation is not sufficient.
This practice ensures clarity and transparency in your codebase.</value>
  </data>
  <data name="MiKo_3098_MessageFormat" xml:space="preserve">
    <value>Explain the reason why the message is suppressed</value>
  </data>
  <data name="MiKo_3098_Title" xml:space="preserve">
    <value>Justifications of suppressed messages shall explain</value>
  </data>
  <data name="MiKo_3099_CodeFixTitle" xml:space="preserve">
    <value>Fix comparison to null</value>
  </data>
  <data name="MiKo_3099_Description" xml:space="preserve">
    <value>Comparing enum values to 'null' is pointless because enums are value types and can never be 'null'. Such comparisons will always fail.</value>
  </data>
  <data name="MiKo_3099_MessageFormat" xml:space="preserve">
    <value>Enum can never be null</value>
  </data>
  <data name="MiKo_3099_Title" xml:space="preserve">
    <value>Do not compare enum values with null</value>
  </data>
  <data name="MiKo_3100_Description" xml:space="preserve">
    <value>To ease maintenance, place test classes in the same namespace as the type they test. This approach eliminates arbitrary 'using' directives, mirrors the project structure, and makes discovering tests much easier.</value>
  </data>
  <data name="MiKo_3100_MessageFormat" xml:space="preserve">
    <value>Place test class in namespace '{1}'</value>
  </data>
  <data name="MiKo_3100_Title" xml:space="preserve">
    <value>Test classes and types under test belong in same namespace</value>
  </data>
  <data name="MiKo_3101_Description" xml:space="preserve">
    <value>A unit test class should contain unit tests. This ensures the class fulfills its purpose and maintains clarity in your codebase.</value>
  </data>
  <data name="MiKo_3101_MessageFormat" xml:space="preserve">
    <value>Test class should contain tests</value>
  </data>
  <data name="MiKo_3101_Title" xml:space="preserve">
    <value>Test classes should contain tests</value>
  </data>
  <data name="MiKo_3102_Description" xml:space="preserve">
    <value>Tests should focus on a specific scenario. Including a condition in a test means it's testing more than one scenario, which is a code smell. Keep tests simple and specific to ensure clarity and maintainability.</value>
  </data>
  <data name="MiKo_3102_MessageFormat" xml:space="preserve">
    <value>Refactor test to remove condition</value>
  </data>
  <data name="MiKo_3102_Title" xml:space="preserve">
    <value>Test methods should not contain conditional statements (such as 'if', 'switch', etc.)</value>
  </data>
  <data name="MiKo_3103_CodeFixTitle" xml:space="preserve">
    <value>Use hard-coded GUID</value>
  </data>
  <data name="MiKo_3103_Description" xml:space="preserve">
    <value>Tests should be specific to be reproducible and easy to maintain. Generated GUIDs are not reproducible and hard to track if a test fails. Instead, use a hard-coded GUID for consistency. This ensures tests are clear and reliable.</value>
  </data>
  <data name="MiKo_3103_MessageFormat" xml:space="preserve">
    <value>Use a hard-coded GUID instead</value>
  </data>
  <data name="MiKo_3103_Title" xml:space="preserve">
    <value>Test methods should not use 'Guid.NewGuid()'</value>
  </data>
  <data name="MiKo_3104_CodeFixTitle" xml:space="preserve">
    <value>Remove [Combinatorial] attribute</value>
  </data>
  <data name="MiKo_3104_Description" xml:space="preserve">
    <value>Use NUnit's [Combinatorial] attribute only when a test method has at least two parameters for combinatorial testing. If there's only one parameter, this attribute is unnecessary and adds no value.</value>
  </data>
  <data name="MiKo_3104_MessageFormat" xml:space="preserve">
    <value>Wrong usage of [Combinatorial]</value>
  </data>
  <data name="MiKo_3104_Title" xml:space="preserve">
    <value>Use NUnit's [Combinatorial] attribute properly</value>
  </data>
  <data name="MiKo_3105_CodeFixTitle" xml:space="preserve">
    <value>Use 'Assert.That'</value>
  </data>
  <data name="MiKo_3105_Description" xml:space="preserve">
    <value>NUnit's constraint-based Assert model uses a single 'Assert.That' method for all assertions, making it easier to understand. This helps developers avoid mixing up 'actual' and 'expected' values and makes the code more readable and intuitive.</value>
  </data>
  <data name="MiKo_3105_HelpLinkUri" xml:space="preserve">
    <value>https://docs.nunit.org/articles/nunit/writing-tests/assertions/assertion-models/constraint.html</value>
  </data>
  <data name="MiKo_3105_MessageFormat" xml:space="preserve">
    <value>Use 'Assert.That' instead</value>
  </data>
  <data name="MiKo_3105_Title" xml:space="preserve">
    <value>Test methods should use NUnit's fluent Assert approach</value>
  </data>
  <data name="MiKo_3106_Description" xml:space="preserve">
    <value>Assertions like 'Assert.That(...)' with operators (==, !=, &lt;=, &lt;, &gt;=, &gt;) assert for booleans. Patterns like 'is true', type checks via 'is', or 'Equals()' method also do the same.

When such a test fails, it's hard to understand why. The failure message doesn't help much (e.g., 'true' expected but 'false' received), requiring careful inspection or even debugging, which is frustrating, especially with unstable tests.

Instead, tests should immediately state the expected value (e.g., '5' was expected but '12' was received) for clarity and easier troubleshooting.</value>
  </data>
  <data name="MiKo_3106_MessageFormat" xml:space="preserve">
    <value>Do not use '{1}' in assertion</value>
  </data>
  <data name="MiKo_3106_Title" xml:space="preserve">
    <value>Assertions should not use equality or comparison operators</value>
  </data>
  <data name="MiKo_3107_CodeFixTitle" xml:space="preserve">
    <value>Change Moq call to default value</value>
  </data>
  <data name="MiKo_3107_Description" xml:space="preserve">
    <value>Using Moq mocks improperly can cause issues. Use condition matchers on mocks to set up or verify conditions. Avoid using them on constructors or methods of non-mocks, as they don't make sense there. This ensures your mocking is effective and your code stays clear and accurate.</value>
  </data>
  <data name="MiKo_3107_MessageFormat" xml:space="preserve">
    <value>Use a mock instead</value>
  </data>
  <data name="MiKo_3107_Title" xml:space="preserve">
    <value>Moq Mock condition matchers should be used on mocks only</value>
  </data>
  <data name="MiKo_3108_Description" xml:space="preserve">
    <value>Tests need assertions to verify code behavior. Without an assertion, the test does not check anything and is not useful. This ensures tests are effective and your code works as expected.</value>
  </data>
  <data name="MiKo_3108_MessageFormat" xml:space="preserve">
    <value>Add assertion to test</value>
  </data>
  <data name="MiKo_3108_Title" xml:space="preserve">
    <value>Test methods should use assertions</value>
  </data>
  <data name="MiKo_3109_CodeFixTitle" xml:space="preserve">
    <value>Add default assertion message</value>
  </data>
  <data name="MiKo_3109_Description" xml:space="preserve">
    <value>Assertions should include messages explaining why something was expected but failed. This makes it easier to understand why a test failed, helping you quickly identify the issue.</value>
  </data>
  <data name="MiKo_3109_MessageFormat" xml:space="preserve">
    <value>Provide an assertion message</value>
  </data>
  <data name="MiKo_3109_Title" xml:space="preserve">
    <value>Multiple assertions shall use assertion messages</value>
  </data>
  <data name="MiKo_3110_CodeFixTitle" xml:space="preserve">
    <value>Use 'Assert.That(..., Has...)'</value>
  </data>
  <data name="MiKo_3110_Description" xml:space="preserve">
    <value>Assertions using 'Assert.That(...)' with 'Count' or 'Length' check for exact values. When such a test fails, the error message is not very helpful (e.g., '5' expected but '3' received).

This means you need to inspect the failure closely. Debugging might even be necessary, which is frustrating, especially if the test is unreliable.

In contrast, tests should state exactly what was expected and found (e.g., 'Expected items A, B, and C but found B and D'). This approach makes failures much easier to understand and fix.</value>
  </data>
  <data name="MiKo_3110_MessageFormat" xml:space="preserve">
    <value>Do not use '{0}' in assertion</value>
  </data>
  <data name="MiKo_3110_Title" xml:space="preserve">
    <value>Assertions should not use 'Count' or 'Length'</value>
  </data>
  <data name="MiKo_3111_CodeFixTitle" xml:space="preserve">
    <value>Use 'Zero'</value>
  </data>
  <data name="MiKo_3111_Description" xml:space="preserve">
    <value>To improve clarity, use 'Is.Zero' instead of 'Is.EqualTo(0)' when asserting for zero in tests. This makes the code easier to read and understand.</value>
  </data>
  <data name="MiKo_3111_MessageFormat" xml:space="preserve">
    <value>Use 'Zero' instead</value>
  </data>
  <data name="MiKo_3111_Title" xml:space="preserve">
    <value>Assertions should use 'Is.Zero' instead of 'Is.EqualTo(0)'</value>
  </data>
  <data name="MiKo_3112_CodeFixTitle" xml:space="preserve">
    <value>Use 'Is.Empty'</value>
  </data>
  <data name="MiKo_3112_Description" xml:space="preserve">
    <value>To improve clarity, use 'Is.Empty' instead of 'Has.Count.Zero' when asserting on collections for emptiness in tests. This makes the code easier to read and understand.</value>
  </data>
  <data name="MiKo_3112_MessageFormat" xml:space="preserve">
    <value>Use 'Is.Empty' instead</value>
  </data>
  <data name="MiKo_3112_Title" xml:space="preserve">
    <value>Assertions should use 'Is.Empty' instead of 'Has.Count.Zero'</value>
  </data>
  <data name="MiKo_3113_CodeFixTitle" xml:space="preserve">
    <value>Use 'Assert.That'</value>
  </data>
  <data name="MiKo_3113_Description" xml:space="preserve">
    <value>FluentAssertions uses a 'Should' method followed by the assertion, which can make assertions harder to read and spot. In contrast, NUnit's fluent assertion approach using 'Assert.That' is easier to spot and read. This makes NUnit's approach more user-friendly and accessible.</value>
  </data>
  <data name="MiKo_3113_MessageFormat" xml:space="preserve">
    <value>Use 'Assert.That' instead of 'Should'</value>
  </data>
  <data name="MiKo_3113_Title" xml:space="preserve">
    <value>Do not use FluentAssertions</value>
  </data>
  <data name="MiKo_3114_CodeFixTitle" xml:space="preserve">
    <value>Use 'Mock.Of&lt;T&gt;()'</value>
  </data>
  <data name="MiKo_3114_Description" xml:space="preserve">
    <value>Use 'Mock.Of&lt;T&gt;()' in tests instead of 'new Mock&lt;T&gt;().Object'. This makes it easier to spot necessary but unimportant mocks and keeps the code cleaner and easier to read.</value>
  </data>
  <data name="MiKo_3114_MessageFormat" xml:space="preserve">
    <value>Use 'Mock.Of&lt;T&gt;()' instead</value>
  </data>
  <data name="MiKo_3114_Title" xml:space="preserve">
    <value>Use 'Mock.Of&lt;T&gt;()' instead of 'new Mock&lt;T&gt;().Object'</value>
  </data>
  <data name="MiKo_3115_Description" xml:space="preserve">
    <value>Empty test methods mislead developers into thinking they test something. In reality, they don't test anything, giving a false sense of "having it tested".

Commented-out code within these methods raises questions. If uncommented, it might cause the test to fail, indicating either a problem with the test code or an uncovered bug that needs addressing.</value>
  </data>
  <data name="MiKo_3115_MessageFormat" xml:space="preserve">
    <value>Delete empty test method or implement a test</value>
  </data>
  <data name="MiKo_3115_Title" xml:space="preserve">
    <value>Test methods should contain code</value>
  </data>
  <data name="MiKo_3116_Description" xml:space="preserve">
    <value>Empty unit test initialization methods clutter the codebase and serve no purpose. They can be safely removed to keep the code clean and maintainable.</value>
  </data>
  <data name="MiKo_3116_MessageFormat" xml:space="preserve">
    <value>Delete empty test initialization method</value>
  </data>
  <data name="MiKo_3116_Title" xml:space="preserve">
    <value>Test initialization methods should contain code</value>
  </data>
  <data name="MiKo_3117_Description" xml:space="preserve">
    <value>Empty unit test cleanup methods clutter the codebase and serve no purpose. They can be safely removed to keep the code clean and maintainable.</value>
  </data>
  <data name="MiKo_3117_MessageFormat" xml:space="preserve">
    <value>Delete empty test cleanup method</value>
  </data>
  <data name="MiKo_3117_Title" xml:space="preserve">
    <value>Test cleanup methods should contain code</value>
  </data>
  <data name="MiKo_3118_Description" xml:space="preserve">
    <value>Make tests as explicit as possible.
LINQ calls like 'Skip', 'Take', or 'FirstOrDefault' are useful in production but can be unclear in tests. Using 'Skip' in a test, for example, can confuse readers about why values are being skipped. This ambiguity requires extra effort to understand.
Avoid this by being more explicit about the expected outcome.</value>
  </data>
  <data name="MiKo_3118_MessageFormat" xml:space="preserve">
    <value>Do not use ambiguous Linq call '{0}'</value>
  </data>
  <data name="MiKo_3118_Title" xml:space="preserve">
    <value>Test methods should not use ambiguous Linq calls</value>
  </data>
  <data name="MiKo_3119_CodeFixTitle" xml:space="preserve">
    <value>Change return type of test method to 'void'</value>
  </data>
  <data name="MiKo_3119_Description" xml:space="preserve">
    <value>Test methods returning non-generic tasks are meant to test asynchronous behavior. They should not return 'Task.CompletedTask'. If they do, simply have them return void instead.</value>
  </data>
  <data name="MiKo_3119_MessageFormat" xml:space="preserve">
    <value>Return void instead of Task</value>
  </data>
  <data name="MiKo_3119_Title" xml:space="preserve">
    <value>Test methods should not simply return completed task</value>
  </data>
  <data name="MiKo_3120_CodeFixTitle" xml:space="preserve">
    <value>Use value directly instead of condition matcher</value>
  </data>
  <data name="MiKo_3120_Description" xml:space="preserve">
    <value>Moq's condition matchers are meant to verify that parts of an argument meet specific criteria. However, they should not be used to test for exact value matches. In those cases, provide the exact values instead of using a condition matcher.
This ensures precision in your tests and maintains clear expectations.</value>
  </data>
  <data name="MiKo_3120_MessageFormat" xml:space="preserve">
    <value>Use value directly instead of condition matcher</value>
  </data>
  <data name="MiKo_3120_Title" xml:space="preserve">
    <value>Moq mocks should use values instead of 'It.Is&lt;&gt;(...)' condition matcher to verify exact values</value>
  </data>
  <data name="MiKo_3121_Description" xml:space="preserve">
    <value>For easier development and direct code access, use a concrete type for the object under test, not an interface. Otherwise, developers end up at the interface and have to find the actual implementation.</value>
  </data>
  <data name="MiKo_3121_MessageFormat" xml:space="preserve">
    <value>Test concrete type instead of interface</value>
  </data>
  <data name="MiKo_3121_Title" xml:space="preserve">
    <value>Tests should test concrete implementations and no interfaces</value>
  </data>
  <data name="MiKo_3122_Description" xml:space="preserve">
    <value>Test methods with more than 2 parameters are often combined tests and can be hard to read. To improve readability, split these tests into separate ones. This makes them easier to understand and maintain.</value>
  </data>
  <data name="MiKo_3122_MessageFormat" xml:space="preserve">
    <value>Split into multiple tests so that you do not need more than 2 parameters</value>
  </data>
  <data name="MiKo_3122_Title" xml:space="preserve">
    <value>Test methods should not use more than 2 parameters</value>
  </data>
  <data name="MiKo_3201_CodeFixTitle" xml:space="preserve">
    <value>Invert if to simplify</value>
  </data>
  <data name="MiKo_3201_Description" xml:space="preserve">
    <value>If a method has just a few statements and an 'if' statement that returns, invert the 'if' statement. This makes the method easier to read and understand.</value>
  </data>
  <data name="MiKo_3201_MessageFormat" xml:space="preserve">
    <value>Invert if to simplify</value>
  </data>
  <data name="MiKo_3201_Title" xml:space="preserve">
    <value>If statements can be inverted in short methods</value>
  </data>
  <data name="MiKo_3202_CodeFixTitle" xml:space="preserve">
    <value>Invert condition into positive</value>
  </data>
  <data name="MiKo_3202_Description" xml:space="preserve">
    <value>Code is easier to read when using 'if' statements or conditionals with positive conditions. This approach enhances readability and clarity.</value>
  </data>
  <data name="MiKo_3202_MessageFormat" xml:space="preserve">
    <value>Invert condition into positive</value>
  </data>
  <data name="MiKo_3202_Title" xml:space="preserve">
    <value>Use positive conditions when returning in all paths</value>
  </data>
  <data name="MiKo_3203_CodeFixTitle" xml:space="preserve">
    <value>Invert if to simplify</value>
  </data>
  <data name="MiKo_3203_Description" xml:space="preserve">
    <value>If an 'if' statement contains only a 'continue' statement and is followed by a single line of code, invert the 'if' statement. This makes the method easier to read and understand.</value>
  </data>
  <data name="MiKo_3203_MessageFormat" xml:space="preserve">
    <value>Invert if to simplify</value>
  </data>
  <data name="MiKo_3203_Title" xml:space="preserve">
    <value>If-continue statements can be inverted when followed by single line</value>
  </data>
  <data name="MiKo_3204_CodeFixTitle" xml:space="preserve">
    <value>Invert if to simplify</value>
  </data>
  <data name="MiKo_3204_Description" xml:space="preserve">
    <value>If an 'if' statement has a negative condition and an 'else' clause, invert it into a positive condition. This makes the method easier to read and understand.</value>
  </data>
  <data name="MiKo_3204_MessageFormat" xml:space="preserve">
    <value>Invert if to simplify</value>
  </data>
  <data name="MiKo_3204_Title" xml:space="preserve">
    <value>Negative If statements can be inverted when they have an else clause</value>
  </data>
  <data name="MiKo_3210_Description" xml:space="preserve">
    <value>Overloads are methods with the same name within a type. Generally, those with fewer parameters call the ones with more parameters, providing default values.

When inheritance requires overriding such methods, override the overload with the most parameters. The same rule applies to abstract methods. This approach maintains consistency and clarity in your code.</value>
  </data>
  <data name="MiKo_3210_MessageFormat" xml:space="preserve">
    <value>Do not make method '{0}'</value>
  </data>
  <data name="MiKo_3210_Title" xml:space="preserve">
    <value>Only the longest overloads should be virtual or abstract</value>
  </data>
  <data name="MiKo_3211_Description" xml:space="preserve">
    <value>If a public type contains a finalizable resource, use a private nested type (or an internal type for multiple classes) as the finalizable resource holder.

Finalizers are challenging to implement correctly because they can't assume the state of the system during execution. This approach ensures proper management of finalizable resources.</value>
  </data>
  <data name="MiKo_3211_MessageFormat" xml:space="preserve">
    <value>Do not use a finalizer</value>
  </data>
  <data name="MiKo_3211_Title" xml:space="preserve">
    <value>Public types should not have finalizers</value>
  </data>
  <data name="MiKo_3212_Description" xml:space="preserve">
    <value>Stick to the basic Dispose pattern to avoid confusing developers. The only methods named 'Dispose' should be void 'IDisposable.Dispose()' and 'void Dispose(bool disposing)'. Any other methods would deviate from the Dispose pattern and cause confusion.</value>
  </data>
  <data name="MiKo_3212_MessageFormat" xml:space="preserve">
    <value>Do not provide such Dispose method</value>
  </data>
  <data name="MiKo_3212_Title" xml:space="preserve">
    <value>Do not confuse developers by providing other Dispose methods</value>
  </data>
  <data name="MiKo_3213_Description" xml:space="preserve">
    <value>The public 'Dispose()' method should only call 'Dispose(bool disposing)' with 'disposing' set to 'true'. All other disposal logic should reside in the 'Dispose(bool disposing)' method. This keeps the Dispose pattern consistent and clear.</value>
  </data>
  <data name="MiKo_3213_MessageFormat" xml:space="preserve">
    <value>Only invoke 'Dispose(false)' but nothing more</value>
  </data>
  <data name="MiKo_3213_Title" xml:space="preserve">
    <value>Parameterless Dispose method follows Basic Dispose pattern</value>
  </data>
  <data name="MiKo_3214_Description" xml:space="preserve">
    <value>Methods starting with 'Begin' or 'Enter' often have counterparts like 'End' or 'Exit', defining a scope (e.g., 'BeginUpdate' and 'EndUpdate'). Public access to these methods can lead to errors if 'End' methods are not correctly invoked.

Instead, provide a method that returns an 'IDisposable'. This way, developers can use a 'using' statement to ensure the 'End' method is always called, keeping everything clean and error-free.</value>
  </data>
  <data name="MiKo_3214_MessageFormat" xml:space="preserve">
    <value>Rename scope-defining method to not start with '{1}'</value>
  </data>
  <data name="MiKo_3214_Title" xml:space="preserve">
    <value>Interfaces do not contain 'Begin/End' or 'Enter/Exit' scope-defining methods</value>
  </data>
  <data name="MiKo_3215_CodeFixTitle" xml:space="preserve">
    <value>Convert 'Predicate' into 'Func'</value>
  </data>
  <data name="MiKo_3215_Description" xml:space="preserve">
    <value>To standardize delegates and adhere to .NET Framework Design Guidelines, use 'Func&lt;T, bool&gt;' for callbacks instead of 'Predicate&lt;T&gt;'. This approach ensures consistency and aligns with best practices.</value>
  </data>
  <data name="MiKo_3215_HelpLinkUri" xml:space="preserve">
    <value>https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/events-and-callbacks</value>
  </data>
  <data name="MiKo_3215_MessageFormat" xml:space="preserve">
    <value>Use 'Func&lt;{0}, bool&gt;' instead of 'Predicate&lt;{0}&gt;'</value>
  </data>
  <data name="MiKo_3215_Title" xml:space="preserve">
    <value>Callbacks should be 'Func&lt;T, bool&gt;' instead of 'Predicate&lt;bool&gt;'</value>
  </data>
  <data name="MiKo_3216_CodeFixTitle" xml:space="preserve">
    <value>Make field read-only</value>
  </data>
  <data name="MiKo_3216_Description" xml:space="preserve">
    <value>Static fields with pre-assigned values are likely meant to remain unchanged. Therefore, make these fields 'readonly'. This ensures their values remain constant and clearly communicates their intended use.</value>
  </data>
  <data name="MiKo_3216_MessageFormat" xml:space="preserve">
    <value>Make field read-only</value>
  </data>
  <data name="MiKo_3216_Title" xml:space="preserve">
    <value>Static fields with initializers should be read-only</value>
  </data>
  <data name="MiKo_3217_Description" xml:space="preserve">
    <value>Generic types with other generic types as type arguments are hard to understand and maintain. This complexity makes it difficult to interpret their purpose and suggests hidden type information due to primitive obsession.

Instead, use non-generic types as type arguments. This approach makes the code's intent clearer and easier to follow.</value>
  </data>
  <data name="MiKo_3217_MessageFormat" xml:space="preserve">
    <value>Do not use generic type with generic type arguments</value>
  </data>
  <data name="MiKo_3217_Title" xml:space="preserve">
    <value>Do not use generic types that have other generic types as type arguments</value>
  </data>
  <data name="MiKo_3218_Description" xml:space="preserve">
    <value>Extension methods should only be in static types designed for that purpose. Avoid placing them in other types, as this can cause confusion. Keeping extension methods where they belong ensures clarity and consistency in your code.</value>
  </data>
  <data name="MiKo_3218_MessageFormat" xml:space="preserve">
    <value>Change from extension method into normal static method</value>
  </data>
  <data name="MiKo_3218_Title" xml:space="preserve">
    <value>Do not define extension methods in unexpected places</value>
  </data>
  <data name="MiKo_3219_Description" xml:space="preserve">
    <value>Public members should offer the correct functionality for class consumers. If extensibility is needed, they should call a 'protected virtual' member with the same name suffixed by 'Core'. These serve as clear, easily identifiable extensibility points.</value>
  </data>
  <data name="MiKo_3219_MessageFormat" xml:space="preserve">
    <value>Remove 'virtual' and provide a 'protected virtual {0}' member instead</value>
  </data>
  <data name="MiKo_3219_Title" xml:space="preserve">
    <value>Public members should not be 'virtual'</value>
  </data>
  <data name="MiKo_3220_CodeFixTitle" xml:space="preserve">
    <value>Simplify condition</value>
  </data>
  <data name="MiKo_3220_Description" xml:space="preserve">
    <value>Simplify logical '&amp;&amp;' or '||' conditions by removing direct uses of 'true' or 'false'. This makes your code cleaner and easier to read.</value>
  </data>
  <data name="MiKo_3220_MessageFormat" xml:space="preserve">
    <value>Simplify condition</value>
  </data>
  <data name="MiKo_3220_Title" xml:space="preserve">
    <value>Logical '&amp;&amp;' or '||' conditions using 'true' or 'false' should be simplified</value>
  </data>
  <data name="MiKo_3221_CodeFixTitle" xml:space="preserve">
    <value>Use 'HashCode.Combine'</value>
  </data>
  <data name="MiKo_3221_Description" xml:space="preserve">
    <value>To improve the quality of the hash code returned by 'GetHashCode', use the 'HashCode.Combine' method. This is especially useful when dealing with simple underlying data types like integers and keeps your hash codes robust and efficient.</value>
  </data>
  <data name="MiKo_3221_MessageFormat" xml:space="preserve">
    <value>Use 'HashCode.Combine' instead</value>
  </data>
  <data name="MiKo_3221_Title" xml:space="preserve">
    <value>GetHashCode overrides should use 'HashCode.Combine'</value>
  </data>
  <data name="MiKo_3222_CodeFixTitle" xml:space="preserve">
    <value>Simplify comparison</value>
  </data>
  <data name="MiKo_3222_Description" xml:space="preserve">
    <value>Simplify string comparisons for equality by using specific methods from the .NET framework. This makes your code more readable and easier to understand.</value>
  </data>
  <data name="MiKo_3222_MessageFormat" xml:space="preserve">
    <value>String comparison can be simplified</value>
  </data>
  <data name="MiKo_3222_Title" xml:space="preserve">
    <value>String comparisons can be simplified</value>
  </data>
  <data name="MiKo_3223_CodeFixTitle" xml:space="preserve">
    <value>Simplify comparison</value>
  </data>
  <data name="MiKo_3223_Description" xml:space="preserve">
    <value>Simplify equality comparisons on reference types by using specific .NET framework methods. This approach makes the code easier to read and understand.</value>
  </data>
  <data name="MiKo_3223_MessageFormat" xml:space="preserve">
    <value>Comparison can be simplified</value>
  </data>
  <data name="MiKo_3223_Title" xml:space="preserve">
    <value>Reference comparisons can be simplified</value>
  </data>
  <data name="MiKo_3224_CodeFixTitle" xml:space="preserve">
    <value>Simplify comparison</value>
  </data>
  <data name="MiKo_3224_Description" xml:space="preserve">
    <value>Simplify equality comparisons on value types by using specific .NET framework methods. This approach makes the code easier to read and understand.</value>
  </data>
  <data name="MiKo_3224_MessageFormat" xml:space="preserve">
    <value>Comparison can be simplified</value>
  </data>
  <data name="MiKo_3224_Title" xml:space="preserve">
    <value>Value comparisons can be simplified</value>
  </data>
  <data name="MiKo_3225_CodeFixTitle" xml:space="preserve">
    <value>Simplify redundant comparison</value>
  </data>
  <data name="MiKo_3225_Description" xml:space="preserve">
    <value>Boolean comparisons that check the same values on both sides are redundant. Simplify them by using just one side. This makes the code easier to read and understand.</value>
  </data>
  <data name="MiKo_3225_MessageFormat" xml:space="preserve">
    <value>Redundant comparison can be simplified</value>
  </data>
  <data name="MiKo_3225_Title" xml:space="preserve">
    <value>Redundant comparisons can be simplified</value>
  </data>
  <data name="MiKo_3301_CodeFixTitle" xml:space="preserve">
    <value>Use lambda expression body</value>
  </data>
  <data name="MiKo_3301_Description" xml:space="preserve">
    <value>For single-statement blocks, use lambda expressions with expression bodies instead of parenthesized ones. This avoids the noise of parentheses, making your code cleaner and easier to read.</value>
  </data>
  <data name="MiKo_3301_MessageFormat" xml:space="preserve">
    <value>Use lambda expression body instead</value>
  </data>
  <data name="MiKo_3301_Title" xml:space="preserve">
    <value>Favor lambda expression bodies instead of parenthesized lambda expression blocks for single statements</value>
  </data>
  <data name="MiKo_3302_CodeFixTitle" xml:space="preserve">
    <value>Remove braces around parameter</value>
  </data>
  <data name="MiKo_3302_Description" xml:space="preserve">
    <value>For single-parameter lambda expressions, avoid using parentheses. Use simple lambda expressions with expression bodies instead. This keeps your code cleaner and easier to read.</value>
  </data>
  <data name="MiKo_3302_MessageFormat" xml:space="preserve">
    <value>Use simple lambda expression body instead</value>
  </data>
  <data name="MiKo_3302_Title" xml:space="preserve">
    <value>Favor simple lambda expression bodies instead of parenthesized lambda expression bodies for single parameters</value>
  </data>
  <data name="MiKo_3401_Description" xml:space="preserve">
    <value>Keep namespace hierarchies shallow. If a namespace hierarchy becomes too deep, it likely means the namespaces are too specific or specialized. Flatten such namespaces to keep your codebase understandable and manageable.</value>
  </data>
  <data name="MiKo_3401_MessageFormat" xml:space="preserve">
    <value>Namespace hierarchy too deep: {1,4} (max. {2})</value>
  </data>
  <data name="MiKo_3401_Title" xml:space="preserve">
    <value>Namespace hierarchies should not be too deep</value>
  </data>
  <data name="MiKo_3501_CodeFixTitle" xml:space="preserve">
    <value>Remove suppressed nullable warning</value>
  </data>
  <data name="MiKo_3501_Description" xml:space="preserve">
    <value>Suppressing nullable warnings on null-conditional operators confuses developers. A value is either nullable or it's not; it can't be both.</value>
  </data>
  <data name="MiKo_3501_MessageFormat" xml:space="preserve">
    <value>Do not suppress nullable warning</value>
  </data>
  <data name="MiKo_3501_Title" xml:space="preserve">
    <value>Do not suppress nullable warnings on Null-conditional operators</value>
  </data>
  <data name="MiKo_3502_CodeFixTitle" xml:space="preserve">
    <value>Remove suppressed nullable warning</value>
  </data>
  <data name="MiKo_3502_Description" xml:space="preserve">
    <value>Suppressing nullable warnings on LINQ calls that can return 'null' confuses developers. A value is either nullable or it's not; it can't be both.</value>
  </data>
  <data name="MiKo_3502_MessageFormat" xml:space="preserve">
    <value>Do not suppress nullable warning</value>
  </data>
  <data name="MiKo_3502_Title" xml:space="preserve">
    <value>Do not suppress nullable warnings on Linq calls</value>
  </data>
  <data name="MiKo_4001_CodeFixTitle" xml:space="preserve">
    <value>Place and order method side-by-side with overloads</value>
  </data>
  <data name="MiKo_4001_Description" xml:space="preserve">
    <value>Order methods with the same name but different parameters so that those with fewer parameters come first. This shows all overloads in logical order and improves readability, making the code easier to understand and maintain.</value>
  </data>
  <data name="MiKo_4001_MessageFormat" xml:space="preserve">
    <value>Order methods in following way:
{1}
</value>
  </data>
  <data name="MiKo_4001_Title" xml:space="preserve">
    <value>Methods with same name should be ordered based on the number of their parameters</value>
  </data>
  <data name="MiKo_4002_CodeFixTitle" xml:space="preserve">
    <value>Place method side-by-side with overloads</value>
  </data>
  <data name="MiKo_4002_Description" xml:space="preserve">
    <value>Place methods with the same name and accessibility side-by-side. This keeps them grouped together, making the code easier to find, understand, and maintain.</value>
  </data>
  <data name="MiKo_4002_MessageFormat" xml:space="preserve">
    <value>Place method '{0}' side-by-side with following other methods:
{1}
</value>
  </data>
  <data name="MiKo_4002_Title" xml:space="preserve">
    <value>Methods with same name and accessibility should be placed side-by-side</value>
  </data>
  <data name="MiKo_4003_CodeFixTitle" xml:space="preserve">
    <value>Place 'Dispose' directly after all ctors and finalizers</value>
  </data>
  <data name="MiKo_4003_Description" xml:space="preserve">
    <value>Constructors, finalizers, and Dispose methods are all tied to an object's lifetime. They should be placed side by side to keep related code together.
This organization ensures clarity and makes the code easier to find, understand and maintain.</value>
  </data>
  <data name="MiKo_4003_MessageFormat" xml:space="preserve">
    <value>Place 'Dispose' directly after all ctors and finalizers</value>
  </data>
  <data name="MiKo_4003_Title" xml:space="preserve">
    <value>Dispose methods should be placed directly after constructors and finalizers</value>
  </data>
  <data name="MiKo_4004_CodeFixTitle" xml:space="preserve">
    <value>Place 'Dispose' method first</value>
  </data>
  <data name="MiKo_4004_Description" xml:space="preserve">
    <value>Dispose methods are tied to the object's lifetime. Therefore, place them before all other methods of the same accessibility to keep related code together.
This organization ensures clarity and makes the code easier to find, understand and maintain.</value>
  </data>
  <data name="MiKo_4004_MessageFormat" xml:space="preserve">
    <value>Place 'Dispose' method first</value>
  </data>
  <data name="MiKo_4004_Title" xml:space="preserve">
    <value>Dispose methods should be placed before all other methods of the same accessibility</value>
  </data>
  <data name="MiKo_4005_CodeFixTitle" xml:space="preserve">
    <value>Place interface directly after type declaration</value>
  </data>
  <data name="MiKo_4005_Description" xml:space="preserve">
    <value>List the interface that gives the type its name first, followed by all other implemented interfaces. This organization ensures clarity and makes the code easier to understand.</value>
  </data>
  <data name="MiKo_4005_MessageFormat" xml:space="preserve">
    <value>Place '{1}' as first interface directly after type declaration</value>
  </data>
  <data name="MiKo_4005_Title" xml:space="preserve">
    <value>The interface that gives a type its name should be placed directly after the type's declaration</value>
  </data>
  <data name="MiKo_4007_CodeFixTitle" xml:space="preserve">
    <value>Place operator before methods</value>
  </data>
  <data name="MiKo_4007_Description" xml:space="preserve">
    <value>Operators are special static methods. They should be placed before all other methods and grouped together. This ensures clarity and makes the code easier to understand.</value>
  </data>
  <data name="MiKo_4007_MessageFormat" xml:space="preserve">
    <value>Place operator before methods</value>
  </data>
  <data name="MiKo_4007_Title" xml:space="preserve">
    <value>Operators should be placed before methods</value>
  </data>
  <data name="MiKo_4008_CodeFixTitle" xml:space="preserve">
    <value>Place 'GetHashCode' after 'Equals'</value>
  </data>
  <data name="MiKo_4008_Description" xml:space="preserve">
    <value>'GetHashCode' and 'Equals' are used together to manage instances in dictionaries or hashsets. 'GetHashCode' computes a hash, and if a collision occurs, 'Equals' identifies the instance. Because they are closely related, they should be located near each other in your code.</value>
  </data>
  <data name="MiKo_4008_MessageFormat" xml:space="preserve">
    <value>Place 'GetHashCode' after 'Equals'</value>
  </data>
  <data name="MiKo_4008_Title" xml:space="preserve">
    <value>GetHashCode methods should be placed directly after Equals methods</value>
  </data>
  <data name="MiKo_4101_CodeFixTitle" xml:space="preserve">
    <value>Place method after one-time methods and before test cleanup and all other test methods</value>
  </data>
  <data name="MiKo_4101_Description" xml:space="preserve">
    <value>Test initialization methods define the common parts of tests. To make them easy to find, place them directly after all one-time test initialization/cleanup methods and before all test methods.</value>
  </data>
  <data name="MiKo_4101_MessageFormat" xml:space="preserve">
    <value>Place test initialization method after [OneTimeSetUp] / [OneTimeTearDown] methods and before test cleanup and all other test methods</value>
  </data>
  <data name="MiKo_4101_Title" xml:space="preserve">
    <value>Test initialization methods should be ordered directly after One-Time methods</value>
  </data>
  <data name="MiKo_4102_CodeFixTitle" xml:space="preserve">
    <value>Place method after test initialization methods and before all test methods</value>
  </data>
  <data name="MiKo_4102_Description" xml:space="preserve">
    <value>Test cleanup methods define common tasks to be executed after any test finishes. To make them easy to find, place them directly after any test initialization method and before all test methods.</value>
  </data>
  <data name="MiKo_4102_MessageFormat" xml:space="preserve">
    <value>Place test cleanup method after test initialization methods and before all test methods</value>
  </data>
  <data name="MiKo_4102_Title" xml:space="preserve">
    <value>Test cleanup methods should be ordered after test initialization methods and before test methods</value>
  </data>
  <data name="MiKo_4103_CodeFixTitle" xml:space="preserve">
    <value>Place method before all other methods</value>
  </data>
  <data name="MiKo_4103_Description" xml:space="preserve">
    <value>One-time test initialization methods set up the key parts of the test environment. To make them easy to find, place these methods first.</value>
  </data>
  <data name="MiKo_4103_MessageFormat" xml:space="preserve">
    <value>Place [OneTimeSetUp] method before all other methods</value>
  </data>
  <data name="MiKo_4103_Title" xml:space="preserve">
    <value>One-Time test initialization methods should be ordered before all other methods</value>
  </data>
  <data name="MiKo_4104_CodeFixTitle" xml:space="preserve">
    <value>Place method directly after [OneTimeSetUp] method and before all other methods</value>
  </data>
  <data name="MiKo_4104_Description" xml:space="preserve">
    <value>One-time test cleanup methods handle the common tasks that must be executed after all tests are done to clean up the test environment. To make them easy to find, place them directly after the one-time test initialization methods.</value>
  </data>
  <data name="MiKo_4104_MessageFormat" xml:space="preserve">
    <value>Place [OneTimeTearDown] method directly after [OneTimeSetUp] method and before all other methods</value>
  </data>
  <data name="MiKo_4104_Title" xml:space="preserve">
    <value>One-Time test cleanup methods should be ordered directly after One-Time test initialization methods</value>
  </data>
  <data name="MiKo_5001_CodeFixTitle" xml:space="preserve">
    <value>Place inside 'if'</value>
  </data>
  <data name="MiKo_5001_Description" xml:space="preserve">
    <value>To improve performance, call 'IsDebugEnabled' before invoking 'Debug' or 'DebugFormat'. This prevents creating unnecessary messages and garbage collection if the 'Debug' log level isn't set.</value>
  </data>
  <data name="MiKo_5001_MessageFormat" xml:space="preserve">
    <value>Invoke '{2}' before invoking '{1}'</value>
  </data>
  <data name="MiKo_5001_Title" xml:space="preserve">
    <value>'Debug' and 'DebugFormat' methods should be invoked only after 'IsDebugEnabled'</value>
  </data>
  <data name="MiKo_5002_CodeFixTitle" xml:space="preserve">
    <value>Replace with non-'Format' method</value>
  </data>
  <data name="MiKo_5002_Description" xml:space="preserve">
    <value>To improve performance, use 'xxxFormat' methods (like 'DebugFormat') only with arguments for formatting the string. Otherwise, use the non-formatting methods (like 'Debug'). This approach avoids unnecessary overhead and keeps your code efficient.</value>
  </data>
  <data name="MiKo_5002_MessageFormat" xml:space="preserve">
    <value>Invoke '{2}' instead</value>
  </data>
  <data name="MiKo_5002_Title" xml:space="preserve">
    <value>'xxxFormat' methods should be invoked with multiple arguments only</value>
  </data>
  <data name="MiKo_5003_Description" xml:space="preserve">
    <value>When logging exceptions, use Log methods that accept an exception parameter (like 'Debug', 'Info', 'Warn', etc.). This allows the Log framework to capture not just the exception name but also additional details like the stack trace, keeping your logs detailed and informative.</value>
  </data>
  <data name="MiKo_5003_MessageFormat" xml:space="preserve">
    <value>Invoke '{1}' overload with exception parameter</value>
  </data>
  <data name="MiKo_5003_Title" xml:space="preserve">
    <value>Correct Log methods should be invoked for exceptions</value>
  </data>
  <data name="MiKo_5010_CodeFixTitle" xml:space="preserve">
    <value>Replace 'Equals' by '=='</value>
  </data>
  <data name="MiKo_5010_Description" xml:space="preserve">
    <value>Using 'object.Equals()' on value types causes unnecessary boxing and unboxing, which pressures the garbage collector. Instead, use the equality operator for comparing value types. This improves performance by avoiding temporary object creation and garbage collection.</value>
  </data>
  <data name="MiKo_5010_MessageFormat" xml:space="preserve">
    <value>Use '==' operator instead of '{1}'</value>
  </data>
  <data name="MiKo_5010_Title" xml:space="preserve">
    <value>Do not use 'object.Equals()' on value types</value>
  </data>
  <data name="MiKo_5011_Description" xml:space="preserve">
    <value>Do not use += for string concatenation. It creates unnecessary string allocations, putting pressure on the garbage collector. Instead, use 'string.Concat()', 'string.Join()', or 'StringBuilder' to boost performance and reduce garbage collector load.</value>
  </data>
  <data name="MiKo_5011_MessageFormat" xml:space="preserve">
    <value>Use 'string.Concat()' or 'string.Join()' instead</value>
  </data>
  <data name="MiKo_5011_Title" xml:space="preserve">
    <value>Do not concatenate strings with += operator</value>
  </data>
  <data name="MiKo_5012_Description" xml:space="preserve">
    <value>To improve performance, avoid letting methods with yield call themselves recursively. This causes the underlying iterators to be called more times than expected, resulting in poor runtime performance.</value>
  </data>
  <data name="MiKo_5012_HelpLinkUri" xml:space="preserve">
    <value>https://stackoverflow.com/questions/3969963/when-not-to-use-yield-return</value>
  </data>
  <data name="MiKo_5012_MessageFormat" xml:space="preserve">
    <value>Do not use yield recursively</value>
  </data>
  <data name="MiKo_5012_Title" xml:space="preserve">
    <value>Do not use 'yield return' for recursively defined structures</value>
  </data>
  <data name="MiKo_5013_CodeFixTitle" xml:space="preserve">
    <value>Use 'Array.Empty&lt;&gt;()'</value>
  </data>
  <data name="MiKo_5013_Description" xml:space="preserve">
    <value>Avoid creating empty arrays manually to prevent unnecessary memory consumption and garbage collector pressure. Use 'Array.Empty&lt;T&gt;()' or '[]' instead. This approach is more efficient.</value>
  </data>
  <data name="MiKo_5013_MessageFormat" xml:space="preserve">
    <value>Do not create empty array</value>
  </data>
  <data name="MiKo_5013_Title" xml:space="preserve">
    <value>Do not create empty arrays</value>
  </data>
  <data name="MiKo_5014_CodeFixTitle" xml:space="preserve">
    <value>Use 'Array.Empty&lt;&gt;()'</value>
  </data>
  <data name="MiKo_5014_Description" xml:space="preserve">
    <value>Avoid creating empty lists manually to prevent unnecessary memory consumption and garbage collector pressure. Use 'Array.Empty&lt;T&gt;()' or '[]' instead. This approach is more efficient.</value>
  </data>
  <data name="MiKo_5014_MessageFormat" xml:space="preserve">
    <value>Do not create empty lists</value>
  </data>
  <data name="MiKo_5014_Title" xml:space="preserve">
    <value>Do not create empty lists if the return value is read-only</value>
  </data>
  <data name="MiKo_5015_CodeFixTitle" xml:space="preserve">
    <value>Remove unneeded call to string.Intern()</value>
  </data>
  <data name="MiKo_5015_Description" xml:space="preserve">
    <value>Do not intern string literals. They're already interned, so doing it again does not add any value.</value>
  </data>
  <data name="MiKo_5015_MessageFormat" xml:space="preserve">
    <value>Do not intern string literal</value>
  </data>
  <data name="MiKo_5015_Title" xml:space="preserve">
    <value>Do not intern string literals</value>
  </data>
  <data name="MiKo_5016_Description" xml:space="preserve">
    <value>To improve performance, use 'Contains()' on a 'HashSet' inside 'List.RemoveAll(...)' calls. HashSet lookup is O(1) while list lookup is O(n), which leads to better runtime performance. Using '.Contains()' on a list requires looping over it repeatedly, slowing things down.</value>
  </data>
  <data name="MiKo_5016_MessageFormat" xml:space="preserve">
    <value>Use a HashSet for the lookup</value>
  </data>
  <data name="MiKo_5016_Title" xml:space="preserve">
    <value>Use a HashSet for lookups in 'List.RemoveAll'</value>
  </data>
  <data name="MiKo_5017_CodeFixTitle" xml:space="preserve">
    <value>Convert to constant</value>
  </data>
  <data name="MiKo_5017_Description" xml:space="preserve">
    <value>To avoid unnecessary memory consumption, make string literals used as field or variable values constant. This keeps memory usage efficient and ensures better performance.</value>
  </data>
  <data name="MiKo_5017_MessageFormat" xml:space="preserve">
    <value>Convert to constant</value>
  </data>
  <data name="MiKo_5017_Title" xml:space="preserve">
    <value>Fields or variables assigned with string literals should be constant</value>
  </data>
  <data name="MiKo_6001_CodeFixTitle" xml:space="preserve">
    <value>Surround with blank lines</value>
  </data>
  <data name="MiKo_6001_Description" xml:space="preserve">
    <value>Surround logging calls with blank lines to visually separate them from business code. This improves readability and makes the code easier to follow.</value>
  </data>
  <data name="MiKo_6001_MessageFormat" xml:space="preserve">
    <value>Surround log statement(s) with blank lines</value>
  </data>
  <data name="MiKo_6001_Title" xml:space="preserve">
    <value>Log statements should be surrounded by blank lines</value>
  </data>
  <data name="MiKo_6002_CodeFixTitle" xml:space="preserve">
    <value>Surround with blank lines</value>
  </data>
  <data name="MiKo_6002_Description" xml:space="preserve">
    <value>Surround assertions with blank lines to visually separate them from the test code. This improves readability and makes the code easier to follow.</value>
  </data>
  <data name="MiKo_6002_MessageFormat" xml:space="preserve">
    <value>Surround assertion statement(s) with blank lines</value>
  </data>
  <data name="MiKo_6002_Title" xml:space="preserve">
    <value>Assertion statements should be surrounded by blank lines</value>
  </data>
  <data name="MiKo_6003_CodeFixTitle" xml:space="preserve">
    <value>Precede with blank line</value>
  </data>
  <data name="MiKo_6003_Description" xml:space="preserve">
    <value>Precede local variables with blank lines to visually separate them from executing code. This improves readability and makes the code easier to follow.</value>
  </data>
  <data name="MiKo_6003_MessageFormat" xml:space="preserve">
    <value>Precede local variable with a blank line</value>
  </data>
  <data name="MiKo_6003_Title" xml:space="preserve">
    <value>Local variable statements should be preceded by blank lines</value>
  </data>
  <data name="MiKo_6004_CodeFixTitle" xml:space="preserve">
    <value>Precede with blank line</value>
  </data>
  <data name="MiKo_6004_Description" xml:space="preserve">
    <value>Precede variable assignments with blank lines to visually separate them from executing code. This improves readability and makes the code easier to follow.</value>
  </data>
  <data name="MiKo_6004_MessageFormat" xml:space="preserve">
    <value>Precede variable assignment with a blank line</value>
  </data>
  <data name="MiKo_6004_Title" xml:space="preserve">
    <value>Variable assignment statements should be preceded by blank lines</value>
  </data>
  <data name="MiKo_6005_CodeFixTitle" xml:space="preserve">
    <value>Precede with blank line</value>
  </data>
  <data name="MiKo_6005_Description" xml:space="preserve">
    <value>Precede 'return' statements with blank lines to visually separate them from the executing code. This improves readability and makes the code easier to follow.</value>
  </data>
  <data name="MiKo_6005_MessageFormat" xml:space="preserve">
    <value>Precede return statement with a blank line</value>
  </data>
  <data name="MiKo_6005_Title" xml:space="preserve">
    <value>Return statements should be preceded by blank lines</value>
  </data>
  <data name="MiKo_6006_CodeFixTitle" xml:space="preserve">
    <value>Surround with blank lines</value>
  </data>
  <data name="MiKo_6006_Description" xml:space="preserve">
    <value>Surround awaited statements with blank lines to visually separate them from other code. This improves readability and makes the code easier to follow.</value>
  </data>
  <data name="MiKo_6006_MessageFormat" xml:space="preserve">
    <value>Surround awaited statement with a blank line</value>
  </data>
  <data name="MiKo_6006_Title" xml:space="preserve">
    <value>Awaited statements should be surrounded by blank lines</value>
  </data>
  <data name="MiKo_6007_CodeFixTitle" xml:space="preserve">
    <value>Surround with blank lines</value>
  </data>
  <data name="MiKo_6007_Description" xml:space="preserve">
    <value>Surround test statements with blank lines to visually separate them from other code. This improves readability and makes the code easier to follow.</value>
  </data>
  <data name="MiKo_6007_MessageFormat" xml:space="preserve">
    <value>Surround test statement with a blank line</value>
  </data>
  <data name="MiKo_6007_Title" xml:space="preserve">
    <value>Test statements should be surrounded by blank lines</value>
  </data>
  <data name="MiKo_6008_CodeFixTitle" xml:space="preserve">
    <value>Precede with blank line</value>
  </data>
  <data name="MiKo_6008_Description" xml:space="preserve">
    <value>Precede using directives for a specific namespace with blank lines to visually separate them from using directives for other namespaces. This improves readability and makes the code easier to follow.</value>
  </data>
  <data name="MiKo_6008_MessageFormat" xml:space="preserve">
    <value>Precede using directive with a blank line</value>
  </data>
  <data name="MiKo_6008_Title" xml:space="preserve">
    <value>Using directives should be preceded by blank lines</value>
  </data>
  <data name="MiKo_6009_CodeFixTitle" xml:space="preserve">
    <value>Surround with blank lines</value>
  </data>
  <data name="MiKo_6009_Description" xml:space="preserve">
    <value>Surround 'try' statements with blank lines to visually separate them from other code. This improves readability and makes the code easier to follow.</value>
  </data>
  <data name="MiKo_6009_MessageFormat" xml:space="preserve">
    <value>Surround 'try' statement with a blank line</value>
  </data>
  <data name="MiKo_6009_Title" xml:space="preserve">
    <value>Try statements should be surrounded by blank lines</value>
  </data>
  <data name="MiKo_6010_CodeFixTitle" xml:space="preserve">
    <value>Surround with blank lines</value>
  </data>
  <data name="MiKo_6010_Description" xml:space="preserve">
    <value>Surround 'if' statements with blank lines to visually separate them from other code. This improves readability and makes the code easier to follow.</value>
  </data>
  <data name="MiKo_6010_MessageFormat" xml:space="preserve">
    <value>Surround 'if' statement with a blank line</value>
  </data>
  <data name="MiKo_6010_Title" xml:space="preserve">
    <value>If statements should be surrounded by blank lines</value>
  </data>
  <data name="MiKo_6011_CodeFixTitle" xml:space="preserve">
    <value>Surround with blank lines</value>
  </data>
  <data name="MiKo_6011_Description" xml:space="preserve">
    <value>Surround 'lock' statements with blank lines to visually separate them from other code. This improves readability and makes the code easier to follow.</value>
  </data>
  <data name="MiKo_6011_MessageFormat" xml:space="preserve">
    <value>Surround 'lock' statement with a blank line</value>
  </data>
  <data name="MiKo_6011_Title" xml:space="preserve">
    <value>Lock statements should be surrounded by blank lines</value>
  </data>
  <data name="MiKo_6012_CodeFixTitle" xml:space="preserve">
    <value>Surround with blank lines</value>
  </data>
  <data name="MiKo_6012_Description" xml:space="preserve">
    <value>Surround 'foreach' loops with blank lines to visually separate them from other code. This improves readability and makes the code easier to follow.</value>
  </data>
  <data name="MiKo_6012_MessageFormat" xml:space="preserve">
    <value>Surround 'foreach' loop with a blank line</value>
  </data>
  <data name="MiKo_6012_Title" xml:space="preserve">
    <value>foreach loops should be surrounded by blank lines</value>
  </data>
  <data name="MiKo_6013_CodeFixTitle" xml:space="preserve">
    <value>Surround with blank lines</value>
  </data>
  <data name="MiKo_6013_Description" xml:space="preserve">
    <value>Surround loops with blank lines to visually separate them from other code. This improves readability and makes the code easier to follow.</value>
  </data>
  <data name="MiKo_6013_MessageFormat" xml:space="preserve">
    <value>Surround 'for' loop with a blank line</value>
  </data>
  <data name="MiKo_6013_Title" xml:space="preserve">
    <value>for loops should be surrounded by blank lines</value>
  </data>
  <data name="MiKo_6014_CodeFixTitle" xml:space="preserve">
    <value>Surround with blank lines</value>
  </data>
  <data name="MiKo_6014_Description" xml:space="preserve">
    <value>Surround 'while' loops with blank lines to visually separate them from other code. This improves readability and makes the code easier to follow.</value>
  </data>
  <data name="MiKo_6014_MessageFormat" xml:space="preserve">
    <value>Surround 'while' loop with a blank line</value>
  </data>
  <data name="MiKo_6014_Title" xml:space="preserve">
    <value>while loops should be surrounded by blank lines</value>
  </data>
  <data name="MiKo_6015_CodeFixTitle" xml:space="preserve">
    <value>Surround with blank lines</value>
  </data>
  <data name="MiKo_6015_Description" xml:space="preserve">
    <value>Surround 'do while' loops with blank lines to visually separate them from other code. This improves readability and makes the code easier to follow.</value>
  </data>
  <data name="MiKo_6015_MessageFormat" xml:space="preserve">
    <value>Surround 'do/while' loop with a blank line</value>
  </data>
  <data name="MiKo_6015_Title" xml:space="preserve">
    <value>do/while loops should be surrounded by blank lines</value>
  </data>
  <data name="MiKo_6016_CodeFixTitle" xml:space="preserve">
    <value>Surround with blank lines</value>
  </data>
  <data name="MiKo_6016_Description" xml:space="preserve">
    <value>Surround 'using' statements with blank lines to visually separate them from other code. This improves readability and makes the code easier to follow.</value>
  </data>
  <data name="MiKo_6016_MessageFormat" xml:space="preserve">
    <value>Surround 'using' with a blank line</value>
  </data>
  <data name="MiKo_6016_Title" xml:space="preserve">
    <value>using statements should be surrounded by blank lines</value>
  </data>
  <data name="MiKo_6017_CodeFixTitle" xml:space="preserve">
    <value>Surround with blank lines</value>
  </data>
  <data name="MiKo_6017_Description" xml:space="preserve">
    <value>Surround 'switch' statements with blank lines to visually separate them from other code. This improves readability and makes the code easier to follow.</value>
  </data>
  <data name="MiKo_6017_MessageFormat" xml:space="preserve">
    <value>Surround 'switch' with a blank line</value>
  </data>
  <data name="MiKo_6017_Title" xml:space="preserve">
    <value>switch statements should be surrounded by blank lines</value>
  </data>
  <data name="MiKo_6018_CodeFixTitle" xml:space="preserve">
    <value>Surround with blank lines</value>
  </data>
  <data name="MiKo_6018_Description" xml:space="preserve">
    <value>Surround 'break' statements with blank lines to visually separate them from other code. This improves readability and makes the code easier to follow.</value>
  </data>
  <data name="MiKo_6018_MessageFormat" xml:space="preserve">
    <value>Surround 'break' with a blank line</value>
  </data>
  <data name="MiKo_6018_Title" xml:space="preserve">
    <value>break statements should be surrounded by blank lines</value>
  </data>
  <data name="MiKo_6019_CodeFixTitle" xml:space="preserve">
    <value>Surround with blank lines</value>
  </data>
  <data name="MiKo_6019_Description" xml:space="preserve">
    <value>Surround 'continue' statements with blank lines to visually separate them from other code. This improves readability and makes the code easier to follow.</value>
  </data>
  <data name="MiKo_6019_MessageFormat" xml:space="preserve">
    <value>Surround 'continue' with a blank line</value>
  </data>
  <data name="MiKo_6019_Title" xml:space="preserve">
    <value>continue statements should be surrounded by blank lines</value>
  </data>
  <data name="MiKo_6020_CodeFixTitle" xml:space="preserve">
    <value>Surround with blank lines</value>
  </data>
  <data name="MiKo_6020_Description" xml:space="preserve">
    <value>Surround 'throw' statements with blank lines to visually separate them from other code. This improves readability and makes the code easier to follow.</value>
  </data>
  <data name="MiKo_6020_MessageFormat" xml:space="preserve">
    <value>Surround 'throw' with a blank line</value>
  </data>
  <data name="MiKo_6020_Title" xml:space="preserve">
    <value>throw statements should be surrounded by blank lines</value>
  </data>
  <data name="MiKo_6021_CodeFixTitle" xml:space="preserve">
    <value>Surround with blank lines</value>
  </data>
  <data name="MiKo_6021_Description" xml:space="preserve">
    <value>Surround 'ArgumentNullException.ThrowIfNull' statements with blank lines to visually separate them from other code. This improves readability and makes the code easier to follow.</value>
  </data>
  <data name="MiKo_6021_MessageFormat" xml:space="preserve">
    <value>Surround 'ThrowIfNull' with a blank line</value>
  </data>
  <data name="MiKo_6021_Title" xml:space="preserve">
    <value>ArgumentNullException.ThrowIfNull statements should be surrounded by blank lines</value>
  </data>
  <data name="MiKo_6022_CodeFixTitle" xml:space="preserve">
    <value>Surround with blank lines</value>
  </data>
  <data name="MiKo_6022_Description" xml:space="preserve">
    <value>Surround 'ArgumentException.ThrowIfNullOrEmpty' statements with blank lines to visually separate them from other code. This improves readability and makes the code easier to follow.</value>
  </data>
  <data name="MiKo_6022_MessageFormat" xml:space="preserve">
    <value>Surround 'ThrowIfNullOrEmpty' with a blank line</value>
  </data>
  <data name="MiKo_6022_Title" xml:space="preserve">
    <value>ArgumentException.ThrowIfNullOrEmpty statements should be surrounded by blank lines</value>
  </data>
  <data name="MiKo_6023_CodeFixTitle" xml:space="preserve">
    <value>Surround with blank lines</value>
  </data>
  <data name="MiKo_6023_Description" xml:space="preserve">
    <value>Surround 'ArgumentOutOfRangeException.ThrowIf' statements with blank lines to visually separate them from other code. This improves readability and makes the code easier to follow.</value>
  </data>
  <data name="MiKo_6023_MessageFormat" xml:space="preserve">
    <value>Surround 'ThrowIf' with a blank line</value>
  </data>
  <data name="MiKo_6023_Title" xml:space="preserve">
    <value>ArgumentOutOfRangeException.ThrowIf statements should be surrounded by blank lines</value>
  </data>
  <data name="MiKo_6024_CodeFixTitle" xml:space="preserve">
    <value>Surround with blank lines</value>
  </data>
  <data name="MiKo_6024_Description" xml:space="preserve">
    <value>Surround 'ObjectDisposedException.ThrowIf' statements with blank lines to visually separate them from other code. This improves readability and makes the code easier to follow.</value>
  </data>
  <data name="MiKo_6024_MessageFormat" xml:space="preserve">
    <value>Surround 'ThrowIf' with a blank line</value>
  </data>
  <data name="MiKo_6024_Title" xml:space="preserve">
    <value>ObjectDisposedException.ThrowIf statements should be surrounded by blank lines</value>
  </data>
  <data name="MiKo_6030_CodeFixTitle" xml:space="preserve">
    <value>Align open brace directly below type</value>
  </data>
  <data name="MiKo_6030_Description" xml:space="preserve">
    <value>Place the open brace of an initializer directly below the type definition. This makes initializations clear, distinguishes them from other blocks like 'if' blocks, and improves readability, making the code easier to follow.</value>
  </data>
  <data name="MiKo_6030_MessageFormat" xml:space="preserve">
    <value>Align open brace directly below type</value>
  </data>
  <data name="MiKo_6030_Title" xml:space="preserve">
    <value>Open braces of initializers should be placed directly below the corresponding type definition</value>
  </data>
  <data name="MiKo_6031_CodeFixTitle" xml:space="preserve">
    <value>Align ternary operator directly below condition</value>
  </data>
  <data name="MiKo_6031_Description" xml:space="preserve">
    <value>Place the question and colon tokens directly below the condition in ternary operators. This makes the two possibilities easy to spot, improves readability, and makes the code easier to follow.</value>
  </data>
  <data name="MiKo_6031_MessageFormat" xml:space="preserve">
    <value>Align ternary operator directly below condition</value>
  </data>
  <data name="MiKo_6031_Title" xml:space="preserve">
    <value>Question and colon tokens of ternary operators should be placed directly below the corresponding condition</value>
  </data>
  <data name="MiKo_6032_CodeFixTitle" xml:space="preserve">
    <value>Align parameter outdented below method</value>
  </data>
  <data name="MiKo_6032_Description" xml:space="preserve">
    <value>Outdent multi-line parameters below the method declaration to easily spot them. This improves readability and makes the code easier to follow.</value>
  </data>
  <data name="MiKo_6032_MessageFormat" xml:space="preserve">
    <value>Align parameter '{0}' outdented below method</value>
  </data>
  <data name="MiKo_6032_Title" xml:space="preserve">
    <value>Multi-line parameters are positioned outdented at end of method</value>
  </data>
  <data name="MiKo_6033_CodeFixTitle" xml:space="preserve">
    <value>Align open brace directly below case</value>
  </data>
  <data name="MiKo_6033_Description" xml:space="preserve">
    <value>Case sections in a switch statement are like conditions in 'if' statements. When a condition matches, the corresponding block gets executed. Therefore, place the open brace of the block directly below the 'case' keyword, just like 'if' blocks.</value>
  </data>
  <data name="MiKo_6033_MessageFormat" xml:space="preserve">
    <value>Align open brace directly below case</value>
  </data>
  <data name="MiKo_6033_Title" xml:space="preserve">
    <value>Braces of blocks below case sections should be placed directly below the corresponding case keyword</value>
  </data>
  <data name="MiKo_6034_CodeFixTitle" xml:space="preserve">
    <value>Place dot on same line</value>
  </data>
  <data name="MiKo_6034_Description" xml:space="preserve">
    <value>Code readability improves when dots are placed on the same lines as the invoked members. This makes the code easier to follow and understand.</value>
  </data>
  <data name="MiKo_6034_MessageFormat" xml:space="preserve">
    <value>Place dot on same line as member</value>
  </data>
  <data name="MiKo_6034_Title" xml:space="preserve">
    <value>Dots should be placed on same line(s) as invoked members</value>
  </data>
  <data name="MiKo_6035_CodeFixTitle" xml:space="preserve">
    <value>Place parenthesis on same line</value>
  </data>
  <data name="MiKo_6035_Description" xml:space="preserve">
    <value>Code readability improves when the open parenthesis are placed on the same lines as the invoked methods. This makes the code easier to follow and understand.</value>
  </data>
  <data name="MiKo_6035_MessageFormat" xml:space="preserve">
    <value>Place open parenthesis on same line as invocation</value>
  </data>
  <data name="MiKo_6035_Title" xml:space="preserve">
    <value>Open parenthesis should be placed on same line(s) as invoked methods</value>
  </data>
  <data name="MiKo_6036_CodeFixTitle" xml:space="preserve">
    <value>Align block directly below arrow</value>
  </data>
  <data name="MiKo_6036_Description" xml:space="preserve">
    <value>To easily distinguish lambda blocks from other code blocks, position them either in line with or directly below the corresponding arrow. This makes the code clearer and easier to follow.</value>
  </data>
  <data name="MiKo_6036_MessageFormat" xml:space="preserve">
    <value>Align lambda block directly below arrow</value>
  </data>
  <data name="MiKo_6036_Title" xml:space="preserve">
    <value>Lambda blocks should be placed directly below the corresponding arrow(s)</value>
  </data>
  <data name="MiKo_6037_CodeFixTitle" xml:space="preserve">
    <value>Place argument on same line as invocation</value>
  </data>
  <data name="MiKo_6037_Description" xml:space="preserve">
    <value>Code readability improves when single arguments are placed on the same lines as the invoked methods. This makes the code clearer and easier to follow.</value>
  </data>
  <data name="MiKo_6037_MessageFormat" xml:space="preserve">
    <value>Place argument on same line as invocation</value>
  </data>
  <data name="MiKo_6037_Title" xml:space="preserve">
    <value>Single arguments should be placed on same line(s) as invoked methods</value>
  </data>
  <data name="MiKo_6038_CodeFixTitle" xml:space="preserve">
    <value>Place cast on same line</value>
  </data>
  <data name="MiKo_6038_Description" xml:space="preserve">
    <value>Code readability improves when casts are placed on the same lines. This makes the code clearer and easier to follow.</value>
  </data>
  <data name="MiKo_6038_MessageFormat" xml:space="preserve">
    <value>Place cast on same line</value>
  </data>
  <data name="MiKo_6038_Title" xml:space="preserve">
    <value>Casts should be placed on same line(s)</value>
  </data>
  <data name="MiKo_6039_CodeFixTitle" xml:space="preserve">
    <value>Place return value on same line as return keyword</value>
  </data>
  <data name="MiKo_6039_Description" xml:space="preserve">
    <value>Code readability improves when return keywords and return values are placed on the same lines. This makes the code clearer and easier to follow.</value>
  </data>
  <data name="MiKo_6039_MessageFormat" xml:space="preserve">
    <value>Place return value on same line as return keyword</value>
  </data>
  <data name="MiKo_6039_Title" xml:space="preserve">
    <value>Return values should be placed on same line(s) as return keywords</value>
  </data>
  <data name="MiKo_6040_CodeFixTitle" xml:space="preserve">
    <value>Indent dots</value>
  </data>
  <data name="MiKo_6040_Description" xml:space="preserve">
    <value>Code readability improves when consecutive invocations spanning multiple lines are vertically aligned by their dots. This makes the code clearer and easier to follow.</value>
  </data>
  <data name="MiKo_6040_MessageFormat" xml:space="preserve">
    <value>Indent dots</value>
  </data>
  <data name="MiKo_6040_Title" xml:space="preserve">
    <value>Consecutive invocations spaning multiple lines should be aligned by their dots</value>
  </data>
  <data name="MiKo_6041_CodeFixTitle" xml:space="preserve">
    <value>Place assignment on same line</value>
  </data>
  <data name="MiKo_6041_Description" xml:space="preserve">
    <value>Code readability improves when assignments are placed on the same lines. This makes the code clearer and easier to follow.</value>
  </data>
  <data name="MiKo_6041_MessageFormat" xml:space="preserve">
    <value>Place assignment on same line</value>
  </data>
  <data name="MiKo_6041_Title" xml:space="preserve">
    <value>Assignments should be placed on same line(s)</value>
  </data>
  <data name="MiKo_6042_CodeFixTitle" xml:space="preserve">
    <value>Place new keyword on same line as type</value>
  </data>
  <data name="MiKo_6042_Description" xml:space="preserve">
    <value>Code readability improves when object creations are placed on the same lines. This makes the code clearer and easier to follow.</value>
  </data>
  <data name="MiKo_6042_MessageFormat" xml:space="preserve">
    <value>Place new keyword on same line as type</value>
  </data>
  <data name="MiKo_6042_Title" xml:space="preserve">
    <value>'new' keywords should be placed on same line(s) as the types</value>
  </data>
  <data name="MiKo_6043_CodeFixTitle" xml:space="preserve">
    <value>Place lambda on single line</value>
  </data>
  <data name="MiKo_6043_Description" xml:space="preserve">
    <value>Code readability improves when lambdas with expression bodies are placed on a single line. This makes the code clearer and easier to follow.</value>
  </data>
  <data name="MiKo_6043_MessageFormat" xml:space="preserve">
    <value>Place lambda on single line</value>
  </data>
  <data name="MiKo_6043_Title" xml:space="preserve">
    <value>Expression bodies of lambdas should be placed on same line as lambda itself when fitting</value>
  </data>
  <data name="MiKo_6044_CodeFixTitle" xml:space="preserve">
    <value>Place operator on same line as right operand</value>
  </data>
  <data name="MiKo_6044_Description" xml:space="preserve">
    <value>Code readability improves when binary operators like '&amp;&amp;' or '||' are placed on the same lines as their right-hand operands. This makes the code clearer and easier to follow.</value>
  </data>
  <data name="MiKo_6044_MessageFormat" xml:space="preserve">
    <value>Place operator on same line as right operand</value>
  </data>
  <data name="MiKo_6044_Title" xml:space="preserve">
    <value>Operators such as '&amp;&amp;' or '||' should be placed on same line(s) as their (right) operands</value>
  </data>
  <data name="MiKo_6045_CodeFixTitle" xml:space="preserve">
    <value>Place comparison on same line</value>
  </data>
  <data name="MiKo_6045_Description" xml:space="preserve">
    <value>Code readability improves when comparison operators such as '==' or '!=' are placed on the same lines as their operands. This makes the code clearer and easier to follow.</value>
  </data>
  <data name="MiKo_6045_MessageFormat" xml:space="preserve">
    <value>Place comparison on same line</value>
  </data>
  <data name="MiKo_6045_Title" xml:space="preserve">
    <value>Comparisons using operators such as '==' or '!=' should be placed on same line(s)</value>
  </data>
  <data name="MiKo_6046_CodeFixTitle" xml:space="preserve">
    <value>Place calculation on same line</value>
  </data>
  <data name="MiKo_6046_Description" xml:space="preserve">
    <value>Code readability improves when calculations operators such as '+' or '%' are placed on the same lines as their operands. This makes the code clearer and easier to follow.</value>
  </data>
  <data name="MiKo_6046_MessageFormat" xml:space="preserve">
    <value>Place calculation on same line</value>
  </data>
  <data name="MiKo_6046_Title" xml:space="preserve">
    <value>Calculations using operators such as '+' or '%' should be placed on same line(s)</value>
  </data>
  <data name="MiKo_6047_CodeFixTitle" xml:space="preserve">
    <value>Align open brace directly below switch</value>
  </data>
  <data name="MiKo_6047_Description" xml:space="preserve">
    <value>Switch expressions are similar to switch statements. Therefore, the open brace of the expression should be placed directly below the 'switch' keyword. This makes the code clearer and easier to follow.</value>
  </data>
  <data name="MiKo_6047_MessageFormat" xml:space="preserve">
    <value>Align open brace directly below switch</value>
  </data>
  <data name="MiKo_6047_Title" xml:space="preserve">
    <value>Braces of switch expressions should be placed directly below the corresponding switch keyword</value>
  </data>
  <data name="MiKo_6048_CodeFixTitle" xml:space="preserve">
    <value>Place condition on single line</value>
  </data>
  <data name="MiKo_6048_Description" xml:space="preserve">
    <value>Logical conditions that span multiple lines are hard to read and understand. To improve readability, they should span a single line only. This makes the code clearer and easier to follow.</value>
  </data>
  <data name="MiKo_6048_MessageFormat" xml:space="preserve">
    <value>Place condition on single line</value>
  </data>
  <data name="MiKo_6048_Title" xml:space="preserve">
    <value>Logical conditions should be placed on a single line</value>
  </data>
  <data name="MiKo_6049_CodeFixTitle" xml:space="preserve">
    <value>Surround with blank lines</value>
  </data>
  <data name="MiKo_6049_Description" xml:space="preserve">
    <value>Surround event registrations and un-registrations with blank lines to visually separate them from other code. This makes the code clearer and easier to follow.</value>
  </data>
  <data name="MiKo_6049_MessageFormat" xml:space="preserve">
    <value>Surround event (un-)registration with a blank line</value>
  </data>
  <data name="MiKo_6049_Title" xml:space="preserve">
    <value>Event (un-)registrations should be surrounded by blank lines</value>
  </data>
  <data name="MiKo_6050_CodeFixTitle" xml:space="preserve">
    <value>Align argument outdented below method call</value>
  </data>
  <data name="MiKo_6050_Description" xml:space="preserve">
    <value>Outdent multi-line arguments below the corresponding method call to easily spot them. This improves readability and makes the code easier to follow.</value>
  </data>
  <data name="MiKo_6050_MessageFormat" xml:space="preserve">
    <value>Align argument '{0}' outdented below method call</value>
  </data>
  <data name="MiKo_6050_Title" xml:space="preserve">
    <value>Multi-line arguments are positioned outdented at end of method call</value>
  </data>
  <data name="MiKo_6051_CodeFixTitle" xml:space="preserve">
    <value>Place colon on same line as constructor call</value>
  </data>
  <data name="MiKo_6051_Description" xml:space="preserve">
    <value>Code readability improves when colons leading constructor calls are placed on the same lines as the calls themselves. This makes the code clearer and easier to follow.</value>
  </data>
  <data name="MiKo_6051_MessageFormat" xml:space="preserve">
    <value>Place colon on same line as constructor call</value>
  </data>
  <data name="MiKo_6051_Title" xml:space="preserve">
    <value>Colon of constructor call shall be placed on same line as constructor call</value>
  </data>
  <data name="MiKo_6052_CodeFixTitle" xml:space="preserve">
    <value>Place colon on same line as first base type</value>
  </data>
  <data name="MiKo_6052_Description" xml:space="preserve">
    <value>Code readability improves when the colons leading the list of base types are on the same line as the first base types. This makes the code clearer and easier to follow.</value>
  </data>
  <data name="MiKo_6052_MessageFormat" xml:space="preserve">
    <value>Place colon on same line as first base type</value>
  </data>
  <data name="MiKo_6052_Title" xml:space="preserve">
    <value>Colon of list of base types shall be placed on same line as first base type</value>
  </data>
  <data name="MiKo_6053_CodeFixTitle" xml:space="preserve">
    <value>Place argument on single line</value>
  </data>
  <data name="MiKo_6053_Description" xml:space="preserve">
    <value>Code readability improves when single-line arguments are kept on a single line instead of splitting them over multiple lines. This makes the code clearer and easier to follow.</value>
  </data>
  <data name="MiKo_6053_MessageFormat" xml:space="preserve">
    <value>Place argument on single line</value>
  </data>
  <data name="MiKo_6053_Title" xml:space="preserve">
    <value>Single-line arguments shall be placed on single line</value>
  </data>
  <data name="MiKo_6054_CodeFixTitle" xml:space="preserve">
    <value>Place lambda arrow on same line as its parameter(s)</value>
  </data>
  <data name="MiKo_6054_Description" xml:space="preserve">
    <value>Code readability improves when the arrow of lambda expressions is on the same line as the parameters or their expression bodies. Avoid splitting them over multiple lines. This makes the code clearer and easier to follow.</value>
  </data>
  <data name="MiKo_6054_MessageFormat" xml:space="preserve">
    <value>Place lambda arrow on same line as its parameter(s)</value>
  </data>
  <data name="MiKo_6054_Title" xml:space="preserve">
    <value>Lambda arrows shall be placed on same line as the parameter(s) of the lambda</value>
  </data>
  <data name="MiKo_6055_CodeFixTitle" xml:space="preserve">
    <value>Surround with blank lines</value>
  </data>
  <data name="MiKo_6055_Description" xml:space="preserve">
    <value>Surround assignments with blank lines to visually separate them from invocations. This makes the code clearer and easier to follow.</value>
  </data>
  <data name="MiKo_6055_MessageFormat" xml:space="preserve">
    <value>Surround assignment with a blank line</value>
  </data>
  <data name="MiKo_6055_Title" xml:space="preserve">
    <value>Assignment statements should be surrounded by blank lines</value>
  </data>
  <data name="MiKo_6056_CodeFixTitle" xml:space="preserve">
    <value>Align collection expression brackets</value>
  </data>
  <data name="MiKo_6056_Description" xml:space="preserve">
    <value>Collection expressions are similar to collection initializers in terms of readability. Therefore, place their open brackets in the same position as the collection initializer braces. This makes the code clearer and easier to follow.</value>
  </data>
  <data name="MiKo_6056_MessageFormat" xml:space="preserve">
    <value>Align collection expression brackets</value>
  </data>
  <data name="MiKo_6056_Title" xml:space="preserve">
    <value>Brackets of collection expressions should be placed directly at the same place collection initializer braces would be positioned</value>
  </data>
  <data name="MiKo_6057_CodeFixTitle" xml:space="preserve">
    <value>Align type parameter constraint vertically along with others</value>
  </data>
  <data name="MiKo_6057_Description" xml:space="preserve">
    <value>Code readability improves when type parameter constraint clauses are aligned vertically. This makes the code clearer and easier to follow.</value>
  </data>
  <data name="MiKo_6057_MessageFormat" xml:space="preserve">
    <value>Align type parameter constraint vertically along with others</value>
  </data>
  <data name="MiKo_6057_Title" xml:space="preserve">
    <value>Type parameter constraint clauses should be aligned vertically</value>
  </data>
  <data name="MiKo_6058_CodeFixTitle" xml:space="preserve">
    <value>Align type parameter constraint indented below parameter list</value>
  </data>
  <data name="MiKo_6058_Description" xml:space="preserve">
    <value>Code readability improves when type parameter constraint clauses are indented below the parameter list. This makes the code clearer and easier to follow.</value>
  </data>
  <data name="MiKo_6058_MessageFormat" xml:space="preserve">
    <value>Align type parameter constraint indented below parameter list</value>
  </data>
  <data name="MiKo_6058_Title" xml:space="preserve">
    <value>Type parameter constraint clauses should be indented below parameter list</value>
  </data>
  <data name="MiKo_6059_CodeFixTitle" xml:space="preserve">
    <value>Align condition outdented</value>
  </data>
  <data name="MiKo_6059_Description" xml:space="preserve">
    <value>Outdent multi-line conditions below the corresponding call to make them easier to read. This makes the code clearer and easier to follow.</value>
  </data>
  <data name="MiKo_6059_MessageFormat" xml:space="preserve">
    <value>Align condition outdented</value>
  </data>
  <data name="MiKo_6059_Title" xml:space="preserve">
    <value>Multi-line conditions are positioned outdented below associated calls</value>
  </data>
  <data name="MiKo_6060_CodeFixTitle" xml:space="preserve">
    <value>Place switch case label on single line</value>
  </data>
  <data name="MiKo_6060_Description" xml:space="preserve">
    <value>Code readability improves when switch case labels span a single line. This makes the code clearer and easier to follow.</value>
  </data>
  <data name="MiKo_6060_MessageFormat" xml:space="preserve">
    <value>Place switch case label on single line</value>
  </data>
  <data name="MiKo_6060_Title" xml:space="preserve">
    <value>Switch case labels should be placed on same line</value>
  </data>
  <data name="MiKo_6061_CodeFixTitle" xml:space="preserve">
    <value>Place switch expression arm on single line</value>
  </data>
  <data name="MiKo_6061_Description" xml:space="preserve">
    <value>Code readability improves when switch expression arms span a single line. This makes the code clearer and easier to follow.</value>
  </data>
  <data name="MiKo_6061_MessageFormat" xml:space="preserve">
    <value>Place switch expression arm on single line</value>
  </data>
  <data name="MiKo_6061_Title" xml:space="preserve">
    <value>Switch expression arms should be placed on same line</value>
  </data>
  <data name="MiKo_6070_CodeFixTitle" xml:space="preserve">
    <value>Surround with blank lines</value>
  </data>
  <data name="MiKo_6070_Description" xml:space="preserve">
    <value>Surround Console input/output with blank lines to visually separate them from business code. This makes the code clearer and easier to follow.</value>
  </data>
  <data name="MiKo_6070_MessageFormat" xml:space="preserve">
    <value>Surround Console statement(s) with blank lines</value>
  </data>
  <data name="MiKo_6070_Title" xml:space="preserve">
    <value>Console statements should be surrounded by blank lines</value>
  </data>
  <data name="MiKo_6071_CodeFixTitle" xml:space="preserve">
    <value>Surround with blank lines</value>
  </data>
  <data name="MiKo_6071_Description" xml:space="preserve">
    <value>Surround local 'using' statements with blank lines to visually separate them from other code. This improves readability and makes the code easier to follow.</value>
  </data>
  <data name="MiKo_6071_MessageFormat" xml:space="preserve">
    <value>Surround local 'using' with a blank line</value>
  </data>
  <data name="MiKo_6071_Title" xml:space="preserve">
    <value>Local using statements should be surrounded by blank lines</value>
  </data>
</root>