Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://docs.microsoft.com/en-us/dotnet/fundamentals/code-analysis/quality-rules/ca1508 below:

CA1508: Avoid dead conditional code (code analysis) - .NET

A method has conditional code that always evaluates to true or false at run time. This leads to dead code in the false branch of the condition.

By default, this rule analyzes the entire codebase, but this is configurable.

Methods can have conditional code, such as if statements, binary expressions (==, !=, <, >), null checks, etc. For example, consider the following code:

public void M(int i, int j)
{
    if (i != 0)
    {
        return;
    }

    if (j != 0)
    {
        return;
    }

    // Below condition will always evaluate to 'false' as 'i' and 'j' are both '0' here.
    if (i != j)
    {
        // Code in this 'if' branch is dead code.
        // It can either be removed or refactored.
        ...
    }
}

C# and VB compilers perform analysis of conditional checks involving compile-time constant values that always evaluate to true or false. This analyzer performs data flow analysis of non-constant variables to determine redundant conditional checks involving non-constant values. In the preceding code, the analyzer determines that i and j are both 0 for all code paths that reach i != j check. Hence, this check will always evaluate to false at run time. The code inside the if statement is dead code and can be removed or refactored. Similarly, the analyzer tracks nullness of variables and reports redundant null checks.

Note

This analyzer performs an expensive dataflow analysis of non-constant values. This can increase the overall compile time on certain code bases.

It's safe to suppress a violation of this rule if you're not concerned about the maintainability of your code. It is also fine to suppress violations that are identified to be false positives. These are possible in the presence of concurrent code that can execute from multiple threads.

If you just want to suppress a single violation, add preprocessor directives to your source file to disable and then re-enable the rule.

#pragma warning disable CA1508
// The code that's violating the rule is on this line.
#pragma warning restore CA1508

To disable the rule for a file, folder, or project, set its severity to none in the configuration file.

[*.{cs,vb}]
dotnet_diagnostic.CA1508.severity = none

For more information, see How to suppress code analysis warnings.

Use the following options to configure which parts of your codebase to run this rule on.

• Exclude specific symbols
• Exclude specific types and their derived types

In addition, the following dataflow analysis–related options apply to this rule:

• interprocedural_analysis_kind
• max_interprocedural_lambda_or_local_function_call_chain
• max_interprocedural_method_call_chain
• points_to_analysis_kind
• copy_analysis
• sufficient_IterationCount_for_weak_KDF_algorithm

You can configure these options for just this rule, for all rules they apply to, or for all rules in this category (Maintainability) that they apply to. For more information, see Code quality rule configuration options.

You can exclude specific symbols, such as types and methods, from analysis by setting the excluded_symbol_names option. For example, to specify that the rule should not run on any code within types named MyType, add the following key-value pair to an .editorconfig file in your project:

dotnet_code_quality.CAXXXX.excluded_symbol_names = MyType

Note

Replace the XXXX part of CAXXXX with the ID of the applicable rule.

Allowed symbol name formats in the option value (separated by |):

• Symbol name only (includes all symbols with the name, regardless of the containing type or namespace).
• Fully qualified names in the symbol's documentation ID format. Each symbol name requires a symbol-kind prefix, such as M: for methods, T: for types, and N: for namespaces.
• .ctor for constructors and .cctor for static constructors.

Examples:

You can exclude specific types and their derived types from analysis by setting the excluded_type_names_with_derived_types option. For example, to specify that the rule should not run on any methods within types named MyType and their derived types, add the following key-value pair to an .editorconfig file in your project:

dotnet_code_quality.CAXXXX.excluded_type_names_with_derived_types = MyType

Note

Replace the XXXX part of CAXXXX with the ID of the applicable rule.

Allowed symbol name formats in the option value (separated by |):

• Type name only (includes all types with the name, regardless of the containing type or namespace).
• Fully qualified names in the symbol's documentation ID format, with an optional T: prefix.

Examples:

• Maintainability rules

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4