InspectionInfo.resx

<?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="AssignedByValParameterInspection" xml:space="preserve">
    <value>Parameter is passed by value, but is assigned a new value/reference. Consider making a local copy instead if the caller isn't supposed to know the new value. If the caller should see the new value, the parameter should be passed ByRef instead, and you have a bug.</value>
  </data>
  <data name="ConstantNotUsedInspection" xml:space="preserve">
    <value>Rubberduck could not find any reference to constant. Consider removing the unused declaration.</value>
  </data>
  <data name="DefaultProjectNameInspection" xml:space="preserve">
    <value>Consider naming your VBA project.</value>
  </data>
  <data name="EmptyStringLiteralInspection" xml:space="preserve">
    <value>The built-in constant 'vbNullString' is a null string pointer taking up 0 bytes of memory, that unambiguously conveys the intent of an empty string.</value>
  </data>
  <data name="EncapsulatePublicFieldInspection" xml:space="preserve">
    <value>Consider exposing a property instead.</value>
  </data>
  <data name="ImplicitActiveSheetReferenceInspection" xml:space="preserve">
    <value>Implicit references to the active sheet make the code frail and harder to debug. Consider making these references explicit when they're intended, and prefer working off object references. Ignore if the member call is referring to a type Rubberduck can't resolve.</value>
  </data>
  <data name="ImplicitActiveWorkbookReferenceInspection" xml:space="preserve">
    <value>Implicit references to the active workbook make the code frail and harder to debug. Consider making these references explicit when they're intended, and prefer working off object references. Ignore if the member call is referring to a type Rubberduck can't resolve.</value>
  </data>
  <data name="ImplicitByRefModifierInspection" xml:space="preserve">
    <value>Parameters are passed by reference unless specified otherwise, which can be confusing and bug-prone. Prefer passing parameters by value, and specify ByRef explicitly when passing parameters by reference.</value>
  </data>
  <data name="ImplicitPublicMemberInspection" xml:space="preserve">
    <value>Module members are public by default, which can be counter-intuitive. Consider specifying explicit access modifiers to avoid ambiguity.</value>
  </data>
  <data name="ImplicitVariantReturnTypeInspection" xml:space="preserve">
    <value>Members with a return value implicitly return a 'Variant' unless specified otherwise. Consider returning an explicit 'Variant' when the return type isn't known, or specify it explicitly.</value>
  </data>
  <data name="MoveFieldCloserToUsageInspection" xml:space="preserve">
    <value>A module-level variable used only in one procedure should be declared in that procedure.</value>
  </data>
  <data name="MultilineParameterInspection" xml:space="preserve">
    <value>Consider continuing long signatures between parameters. Splitting a parameter declaration across multiple lines arguably hurts readability.</value>
  </data>
  <data name="MultipleDeclarationsInspection" xml:space="preserve">
    <value>Declaring multiple variables in the same instruction is legal, but should be used sparingly. Consider declaring variables closer to their usage, in a single instruction per declaration.</value>
  </data>
  <data name="NonReturningFunctionInspection" xml:space="preserve">
    <value>This is likely a bug. The return value of a function or property getter must be assigned before exiting, otherwise the program will not be working with expected results. If a function has no meaningful return value, consider declaring it as a 'Sub' procedure instead.</value>
  </data>
  <data name="ObsoleteCallStatementInspection" xml:space="preserve">
    <value>The 'Call' statement is no longer required to call procedures, and only exists in the language to support legacy code that required it; it can be safely rewritten to an implicit call.</value>
  </data>
  <data name="ObsoleteCommentSyntaxInspection" xml:space="preserve">
    <value>The 'Rem' statement only exists in the language to support legacy code that required it; it can be safely replaced with an apostrophe / single-quote comment.</value>
  </data>
  <data name="ObsoleteGlobalInspection" xml:space="preserve">
    <value>The 'Global' keyword only exists in the language to support legacy code that required it; it can be safely replaced with the 'Public' modifier.</value>
  </data>
  <data name="ObsoleteLetStatementInspection" xml:space="preserve">
    <value>The 'Let' statement only exists in the language to support legacy code that required it; it can be safely removed, since modern VBA does not require that keyword for value assignments.</value>
  </data>
  <data name="ObsoleteTypeHintInspection" xml:space="preserve">
    <value>Type hint characters only exist in the language to support legacy code that required it; they can be safely replaced in declarations with an "As" type clause that specifies the type explicitly, and they can be omitted in other identifier references.</value>
  </data>
  <data name="OptionBaseInspection" xml:space="preserve">
    <value>Arrays are typically zero-based. This option changes the default lower boundary for implicitly-sized arrays, which can introduce off-by-one errors if one isn't cautious.</value>
  </data>
  <data name="OptionExplicitInspection" xml:space="preserve">
    <value>VBA will happily compile a typo: use 'Option Explicit' to prevent successfully compiling an erroneous program.</value>
  </data>
  <data name="ParameterCanBeByValInspection" xml:space="preserve">
    <value>A parameter that is passed by reference and isn't assigned a new value/reference, could be passed by value instead.</value>
  </data>
  <data name="ParameterNotUsedInspection" xml:space="preserve">
    <value>A parameter is passed into a member that does not use it. Consider removing that parameter.</value>
  </data>
  <data name="ProcedureNotUsedInspection" xml:space="preserve">
    <value>Rubberduck could not find any caller for a procedure. If the procedure is hooked to a macro-button, used as a user-defined function (UDF) or handles an application event that Rubberduck didn't know of you can safely ignore this inspection result; otherwise, consider removing it.</value>
  </data>
  <data name="UnassignedVariableUsageInspection" xml:space="preserve">
    <value>This is likely a bug. A variable is being referred to, but is never assigned.</value>
  </data>
  <data name="UntypedFunctionUsageInspection" xml:space="preserve">
    <value>A string-returning equivalent function exists and should preferably be used to avoid implicit type conversions. 
If the parameter can be null, ignore this inspection result; passing a null value to a function expecting a string would raise a type mismatch runtime error.</value>
  </data>
  <data name="UseMeaningfulNameInspection" xml:space="preserve">
    <value>Identifier names should indicate what they're used for and should be readable; avoid disemvoweling, numeric suffixes, and 1-2 character names.</value>
  </data>
  <data name="VariableNotAssignedInspection" xml:space="preserve">
    <value>Variable is not assigned. If this isn't intended, there's probably a bug. Ignore this inspection result if the variable is assigned in another procedure via a ByRef parameter.</value>
  </data>
  <data name="VariableNotUsedInspection" xml:space="preserve">
    <value>Variable is not referred to</value>
  </data>
  <data name="VariableTypeNotDeclaredInspection" xml:space="preserve">
    <value>A variable whose type isn't explicitly declared, is implicitly 'Variant'. Consider making it an explicit 'Variant' if that's intended, or declare a more specific type.</value>
  </data>
  <data name="WriteOnlyPropertyInspection" xml:space="preserve">
    <value>A property that exposes a mutator but no accessor is a design smell and makes a confusing API. Consider exposing a getter, or converting the mutator to a method.</value>
  </data>
  <data name="ProcedureCanBeWrittenAsFunctionInspection" xml:space="preserve">
    <value>A procedure that only has one parameter passed by reference that is assigned a new value/reference before the procedure exits, is using a ByRef parameter as a return value: consider making it a function instead.</value>
  </data>
  <data name="SelfAssignedDeclarationInspection" xml:space="preserve">
    <value>An auto-instantiated object variable declaration at procedure scope changes how nulling the reference works, which can lead to unexpected behavior.</value>
  </data>
  <data name="FunctionReturnValueNotUsedInspection" xml:space="preserve">
    <value>A member is written as a function, but used as a procedure. Unless the function is recursive, consider converting the 'Function' into a 'Sub'. If the function is recursive, none of its external callers are using the returned value.</value>
  </data>
  <data name="ObjectVariableNotSetInspection" xml:space="preserve">
    <value>As far as Rubberduck can tell, this variable is an object variable, assigned without the 'Set' keyword. This causes run-time error 91 'Object or With block variable not set' or 438 'Object doesn't support this property or method' depending on whether the variable has the value 'Nothing' or not.</value>
  </data>
  <data name="MissingAnnotationArgumentInspection" xml:space="preserve">
    <value>An annotation parameter is missing or incorrectly specified. The correct syntax is : '@Annotation([parameter])\nExample: '@Folder("Parent.Child")</value>
  </data>
  <data name="ModuleScopeDimKeywordInspection" xml:space="preserve">
    <value>The 'Public' keyword can only be used at module level; its counterpart 'Private' can also only be used at module level. 'Dim' however, can be used to declare both procedure and module scope variables. For consistency, it would be preferable to reserve 'Dim' for locals, and thus to use 'Private' instead of 'Dim' at module level.</value>
  </data>
  <data name="UndeclaredVariableInspection" xml:space="preserve">
    <value>Code that uses undeclared variables does not compile when Option Explicit is specified. Undeclared variables are always Variant, a data type that incurs unnecessary overhead and storage.</value>
  </data>
  <data name="HungarianNotationInspection" xml:space="preserve">
    <value>Hungarian notation makes code less readable, and is redundant when strongly typed variables and meaningful names are used.</value>
  </data>
  <data name="MemberNotOnInterfaceInspection" xml:space="preserve">
    <value>A member access call is made against an extended interface that Rubberduck couldn't resolve, or the member couldn't be found. If VBA cannot resolve the type at run-time, error 438 will be raised. If an equivalent, non-extended interface that Rubberduck can resolve is available, consider using it instead.</value>
  </data>
  <data name="HostSpecificExpressionInspection" xml:space="preserve">
    <value>Bracketed expressions are evaluated by the host application at runtime, which means VBA can't validate the expression at compile-time. Consider using the host application's object model instead.</value>
  </data>
  <data name="ApplicationWorksheetFunctionInspection" xml:space="preserve">
    <value>The Excel Application object does not implement the WorksheetFunction interface directly. All calls made to WorksheetFunction members are handled as late bound and errors in the called member will be returned wrapped in a Variant of VbVarType.vbError. This makes errors un-trappable with error handlers and adds a performance penalty in comparison to early bound calls. Consider calling Application.WorksheetFunction explicitly. Note: If this call generated errors in the past, those errors were ignored. If applying the quick fix, proper error handling should be in place.</value>
  </data>
  <data name="OptionBaseZeroInspection" xml:space="preserve">
    <value>This is the default setting, it does not need to be specified.</value>
  </data>
  <data name="IllegalAnnotationInspection" xml:space="preserve">
    <value>An annotation meant to be specified at module level cannot be used to annotate members; annotations meant to be annotate members cannot be used at module level.</value>
  </data>
  <data name="MissingAttributeInspection" xml:space="preserve">
    <value>A Rubberduck annotation is specified for a module or member, but the corresponding attribute isn't present. Module attributes and annotations need to be synchronized.</value>
  </data>
  <data name="EmptyIfBlockInspection" xml:space="preserve">
    <value>An empty conditional branch without any executable statements, leaves a maintainer wondering about the intent of the code. Avoid writing code that doesn't need to be written.</value>
  </data>
  <data name="RedundantOptionInspection" xml:space="preserve">
    <value>Being the default/implicit setting for this option, this instruction can be safely omitted.</value>
  </data>
  <data name="RedundantByRefModifierInspection" xml:space="preserve">
    <value>By default, all parameters are passed by reference, so it is not necessary to include the 'ByRef' modifier.</value>
  </data>
  <data name="LineLabelNotUsedInspection" xml:space="preserve">
    <value>A line label that is never jumpted to ('GoTo', 'Resume', ...), serves no purpose. Consider removing it.</value>
  </data>
  <data name="EmptyElseBlockInspection" xml:space="preserve">
    <value>An empty 'Else' loop without any executable statements, leaves a maintainer wondering about the intent of the code. Avoid writing code that doesn't need to be written.</value>
  </data>
  <data name="IntegerDataTypeInspection" xml:space="preserve">
    <value>The maximum value of a 16-bit signed integer is 32,767 - using a 32-bit (Long) integer data type where possible can help prevent 'Overflow' run-time errors, and is better handled by modern CPUs.</value>
  </data>
  <data name="StopKeywordInspection" xml:space="preserve">
    <value>The 'Stop' keyword halts execution and brings up the debugger. Avoid its use in distributed code.</value>
  </data>
  <data name="EmptyCaseBlockInspection" xml:space="preserve">
    <value>An empty 'Case' block without any executable statements, leaves a maintainer wondering about the intent of the code. Avoid writing code that doesn't need to be written.</value>
  </data>
  <data name="EmptyDoWhileBlockInspection" xml:space="preserve">
    <value>An empty 'Do...While' loop without any executable statements, leaves a maintainer wondering about the intent of the code. Avoid writing code that doesn't need to be written.</value>
  </data>
  <data name="EmptyForEachBlockInspection" xml:space="preserve">
    <value>An empty 'For Each...Next' loop without any executable statements, leaves a maintainer wondering about the intent of the code. Avoid writing code that doesn't need to be written.</value>
  </data>
  <data name="EmptyForLoopBlockInspection" xml:space="preserve">
    <value>An empty 'For...Next' loop without any executable statements, leaves a maintainer wondering about the intent of the code. Avoid writing code that doesn't need to be written.</value>
  </data>
  <data name="EmptyWhileWendBlockInspection" xml:space="preserve">
    <value>An empty 'Loop' block without any executable statements, leaves a maintainer wondering about the intent of the code. Avoid writing code that doesn't need to be written.</value>
  </data>
  <data name="ShadowedDeclarationInspection" xml:space="preserve">
    <value>Two declarations are in scope and have the same identifier name. Consider using fully qualified identifier names, otherwise only one of them will be available to use.</value>
  </data>
  <data name="ObsoleteErrorSyntaxInspection" xml:space="preserve">
    <value>The 'Error' statement only exists in the language to support legacy code that required it; prefer using 'Err.Raise' instead.</value>
  </data>
  <data name="BooleanAssignedInIfElseInspection" xml:space="preserve">
    <value>A member is assigned True/False in different branches of an if statement with no other statements in the conditional. Use the condition directly to the member instead.</value>
  </data>
  <data name="EmptyModuleInspection" xml:space="preserve">
    <value>Empty modules and classes either point to not yet implemented functionality or represent unnecessary baggage that can hurt the maintainability of a project.</value>
  </data>
  <data name="UnreachableCaseInspection" xml:space="preserve">
    <value>A 'Case' condition either always evaluates to False, causes a run-time error, or the cumulative effect of prior 'Case' statements represents all possible values or a superset of the 'Case' statement's values.  As a result, the 'Case' block will never execute and is "dead code", or the 'Case' statement is a run-time error waiting to happen. Consider removing, reordering, or modifying the 'Case' statement.</value>
  </data>
  <data name="UnhandledOnErrorResumeNextInspection" xml:space="preserve">
    <value>Error handling should be restored after using 'On Error Resume Next'.</value>
  </data>
  <data name="DefTypeStatementInspection" xml:space="preserve">
    <value>Using the 'Def[Type]' statement leads to specifying types by using a prefix. This style of naming is heavily discouraged and should be avoided.</value>
  </data>
  <data name="StepIsNotSpecifiedInspection" xml:space="preserve">
    <value>Step of the for-next loop is not specified. This might be unintentional.</value>
  </data>
  <data name="StepOneIsRedundantInspection" xml:space="preserve">
    <value>1 is the default step in a for-next loop and therefore is redundant.</value>
  </data>
  <data name="SheetAccessedUsingStringInspection" xml:space="preserve">
    <value>Excel already defines a globally scoped object variable with this reference. Consider using the sheet's 'CodeName' property.</value>
  </data>
  <data name="ObsoleteMemberUsageInspection" xml:space="preserve">
    <value>This member is marked '@Obsolete'. It should no longer be used, there should be a better alternative.</value>
  </data>
  <data name="ObsoleteCallingConventionInspection" xml:space="preserve">
    <value>Windows implementations of Visual Basic only support the StdCall calling convention. The CDecl calling convention is only supported in Macintosh versions of VBA. Use of this keyword in Windows will result in runtime error 49 - 'Bad DLL calling convention'. If this procedure is only intended to be used on Macintosh hosts, it should be conditionally compiled.</value>
  </data>
  <data name="DuplicatedAnnotationInspection" xml:space="preserve">
    <value>An annotation is specified multiple times, but is intended to be specified only once.</value>
  </data>
  <data name="ModuleWithoutFolderInspection" xml:space="preserve">
    <value>Modules without the '@Folder' annotation cannot receive custom groupings in the Code Explorer. </value>
  </data>
  <data name="OnLocalErrorInspection" xml:space="preserve">
    <value>On Local Error exists only for compatibility with previous versions of Visual Basic, and all Errors are treated as Local regardless of the On Local Error statement. Use of this keyword inaccurately gives the impression that there is a distinction between types of error handling when there is not.</value>
  </data>
  <data name="IsMissingOnInappropriateArgumentInspection" xml:space="preserve">
    <value>IsMissing is only intended to be called on optional arguments, and will only return correct results if the type of the argument is 'Variant' with no explicit default value. All other uses will return 'False'.</value>
  </data>
  <data name="IsMissingWithNonArgumentParameterInspection" xml:space="preserve">
    <value>IsMissing is only intended to be called on arguments of the containing procedure, and almost all other usages will return 'False'. Passing any other expression to the function is the equivalent to 'VarType({expression}) = vbError', and in rare circumstances can cause the host application to crash.</value>
  </data>
  <data name="AssignmentNotUsedInspection" xml:space="preserve">
    <value>An assignment is immediately overridden by another assignment or is never referenced.</value>
  </data>
  <data name="UnderscoreInPublicClassModuleMemberInspection" xml:space="preserve">
    <value>A class module that contains members with underscores cannot be implemented by other classes. The underscore is used as a separator between the interface/object name and the implemented member name: having an underscore in the member name confuses the compiler, which then refuses to compile the project. Avoid underscores in public member names by following a 'PascalCase' naming convention.</value>
  </data>
  <data name="ExcelMemberMayReturnNothingInspection" xml:space="preserve">
    <value>A procedure that returns an object may return 'Nothing'. That will cause a runtime error 91 - "Object variable or With block variable not set" on subsequent member access. Perform an 'Is Nothing' check after the 'Set' assignment to guard against runtime errors.</value>
  </data>
  <data name="ExcelUdfNameIsValidCellReferenceInspection" xml:space="preserve">
    <value>Functions that are visible to Excel as User-Defined Functions will return a '#REF!' error when used on a Worksheet if they match the name of a valid cell reference. If the function is intended to be used as a UDF, it must be renamed. If the function is not intended to be used as a UDF, it should be scoped as 'Private' or moved out of a standard Module.</value>
  </data>
  <data name="AttributeValueOutOfSyncInspection" xml:space="preserve">
    <value>A Rubberduck annotation is specified for a module or member, but the corresponding attribute has a different value. Module attributes and annotations need to be synchronized.</value>
  </data>
  <data name="MissingMemberAnnotationInspection" xml:space="preserve">
    <value>Member attributes are not displayed in the VBE. By adding an annotation, you make these attributes more explicit, and Rubberduck can keep annotations and attributes synchronized.</value>
  </data>
  <data name="MissingModuleAnnotationInspection" xml:space="preserve">
    <value>Module attributes are not displayed in the VBE. By adding an annotation, you make these attributes more explicit, and Rubberduck can keep annotations and attributes synchronized.</value>
  </data>
  <data name="KeywordsUsedAsMemberInspection" xml:space="preserve">
    <value>A keyword is being used as a member in either an enumeration or an user defined type. That can lead to ambiguous resolution. Consider renaming the member.</value>
  </data>
  <data name="LineContinuationBetweenKeywordsInspection" xml:space="preserve">
    <value>There are line continuations between keywords. There is no good reason to put it there; consider removing them altogether.</value>
  </data>
  <data name="NonBreakingSpaceIdentifierInspection" xml:space="preserve">
    <value>The identifier contains a non-breaking space which looks very much like just an ordinary space (illegal in an identifier name), which obfuscates the code and makes for a confusing experience. Consider using visible characters for the identifiers.</value>
  </data>
  <data name="NegativeLineNumberInspection" xml:space="preserve">
    <value>Negative line numbers are actually input as hex literal and then prettified by VBE. Editing the line again will cause it to turn red since negative line numbers are in fact illegal.</value>
  </data>
  <data name="OnErrorGoToMinusOneInspection" xml:space="preserve">
    <value>While this is legal, this is poorly documented "feature" that means something different -- the error state is also cleared in addition to disabling any error handling. However, this can be ambiguous as a negative line label of -1 may end up as a target and excessively complex error handling usually indicates a need of refactoring the procedure.</value>
  </data>
  <data name="ObsoleteWhileWendStatementInspection" xml:space="preserve">
    <value>'While...Wend' loops exist for backward compatibility and have been superseded by the introduction of 'Do While...Loop' blocks, which support the 'Exit Do' exit statement. 'While...Wend' loops cannot be exited other than fulfilling the 'While' condition.</value>
  </data>
  <data name="SetAssignmentWithIncompatibleObjectTypeInspection" xml:space="preserve">
    <value>The VBA compiler does not raise an error if an object is set assigned to a variable with an incompatible declared object type, i.e. with an object type that is neither the same type, a supertype nor a subtype. Under almost all circumstances such an assignment leads to a run-time error, which is harder to detect and indicates a bug. In all other situations the code can be changed to use only assignments between compatible declared types.</value>
  </data>
  <data name="EmptyMethodInspection" xml:space="preserve">
    <value>Methods without executable statements may appear to be doing something which they actually don't, and therefore causing unexpected behaviour.</value>
  </data>
  <data name="ImplementedInterfaceMemberInspection" xml:space="preserve">
    <value>A class module that is meant to be used as interface for concrete classes should generally be abstracted of any implementations. If it is your intention to use this class module as a concrete type, you can safely ignore this inspection result.</value>
  </data>
  <data name="ArgumentWithIncompatibleObjectTypeInspection" xml:space="preserve">
    <value>The VBA compiler does not raise an error if an object is passed as an argument for a parameter with an incompatible declared object type, i.e. with an object type that is neither the same type, a supertype nor a subtype. Under almost all circumstances passing such an argument leads to a run-time error, which is harder to detect and indicates a bug. In all other situations the code can be changed to only pass arguments of compatible declared types.</value>
  </data>
  <data name="ValueRequiredInspection" xml:space="preserve">
    <value>The VBA compiler does not raise an error if an object is used in a place that requires a value type and the object's declared type does not have a suitable default member. Under almost all circumstances, this leads to a run-time error 91 'Object or With block variable not set' or 438 'Object doesn't support this property or method' depending on whether the object has the value 'Nothing' or not, which is harder to detect and indicates a bug.</value>
  </data>
  <data name="ProcedureRequiredInspection" xml:space="preserve">
    <value>The VBA compiler does not raise an error if an object variable is used in a place that requires a procedure and the object's declared type does not have a suitable default member. Under almost all circumstances, this leads to a run-time error 91 'Object or With block variable not set' or 438 'Object doesn't support this property or method' depending on whether the object has the value 'Nothing' or not, which is harder to detect and indicates a bug.</value>
  </data>
  <data name="DefaultMemberRequiredInspection" xml:space="preserve">
    <value>The VBA compiler does not raise an error if an indexed default member call is required but the object's declared type does not have a suitable default member. Under almost all circumstances, this leads to a run-time error 91 'Object or With block variable not set' or 438 'Object doesn't support this property or method' depending on whether the object has the value 'Nothing' or not, which is harder to detect and indicates a bug.</value>
  </data>
  <data name="UseOfBangNotationInspection" xml:space="preserve">
    <value>Bang notation, formally known as dictionary access expression, looks like it is strongly typed. However, it is actually a stringly-typed access to the parameterized default member of the object it is used on.</value>
  </data>
  <data name="UseOfRecursiveBangNotationInspection" xml:space="preserve">
    <value>Bang notation, formally known as dictionary access expression, looks like it is strongly typed. However, it is actually a stringly-typed access to the parameterized default member of the object it is used on. This is especially misleading if the parameterized default member is not on the object itself and can only be reached by calling the parameterless default member first.</value>
  </data>
  <data name="UseOfUnboundBangNotationInspection" xml:space="preserve">
    <value>Bang notation, formally known as dictionary access expression, looks like it is strongly typed. However, it is actually a stringly-typed access to the parameterized default member of the object it is used on. This is especially misleading the default member cannot be determined at compile time.</value>
  </data>
  <data name="ObjectWhereProcedureIsRequiredInspection" xml:space="preserve">
    <value>Using an object with a default member in a place that requires a procedure leads to an implicit invocation of the default member. This is most likely unintentional and negatively affects readability.</value>
  </data>
  <data name="IndexedDefaultMemberAccessInspection" xml:space="preserve">
    <value>A default member access hides away which member is actually called. Although it is apparent that some call is made in the case of an indexed default member access being explicit is usually better for readability.</value>
  </data>
  <data name="IndexedRecursiveDefaultMemberAccessInspection" xml:space="preserve">
    <value>A default member access hides away which member is actually called. Although it is apparent that some call is made in the case of an indexed default member access being explicit is usually better for readability. This especially holds if the accessed default member is not on the interface of the object itself but has to be resolved via a chain of default member calls.</value>
  </data>
  <data name="IndexedUnboundDefaultMemberAccessInspection" xml:space="preserve">
    <value>A default member access hides away which member is actually called. Although it is apparent that some call is made in the case of an indexed default member access being explicit is usually better for readability. This is especially true if the default member cannot be determined at compile time. In addition, should there not be a suitable default member at runtime, an error 438 'Object doesn't support this property or method' will be raised.</value>
  </data>
  <data name="ImplicitDefaultMemberAccessInspection" xml:space="preserve">
    <value>Default member accesses hide away the actually called member. This is especially misleading if there is no indication in the expression that such a call is made. It can cause errors in which a member was forgotten to be called to go unnoticed.</value>
  </data>
  <data name="ImplicitRecursiveDefaultMemberAccessInspection" xml:space="preserve">
    <value>Default member accesses hide away the actually called member. This is especially misleading if there is no indication in the expression that such a call is made and the final default member is not on the interface of the object itself. In particular, this can cause errors in which a member was forgotten to be called to go unnoticed.</value>
  </data>
  <data name="ImplicitUnboundDefaultMemberAccessInspection" xml:space="preserve">
    <value>Default member accesses hide away the actually called member. This is especially misleading if there is no indication in the expression that such a call is made and if the default member cannot be determined from the declared type of the object. As a consequence, errors in which a member was forgotten to be called can go unnoticed and should there not be a suitable default member at runtime, an error 438 'Object doesn't support this property or method' will be raised.</value>
  </data>
  <data name="SuspiciousLetAssignmentInspection" xml:space="preserve">
    <value>Whenever both sides of an assignment without Set are objects, there is an assignment from the default member of the RHS to the one on the LHS. Although this might be intentional, in many situations it will just mask an erroneously forgotten Set.</value>
  </data>
</root>