WarningsAsErrors бойынша practical guide

Software warnings бір күні late-night outage-қа айналғанға дейін harmless көрінеді.

Бұл article ішінде WarningsAsErrors family of settings арқылы yellow squiggles-ті early-failing, production-saving errors-ке қалай айналдыруға болатынын қараймыз.

Switch қалай flip ету керек, қашан fine-tune жасау керек және project already warnings ішінде drowning болса не істеу керек екенін көресіз.

Бір warning release-ті неге батыруы мүмкін

Typical C# solution dozens of diagnostics шықса да compile болады, өйткені most compiler diagnostics және analyzer rules үшін default severity - warning. Teams noise-қа үйренеді, real defects plain sight ішінде жасырынады:

• Кейін app crash ететін CS8602 сияқты nullability warnings.

• Ignored async warnings артында masked unobserved task exceptions.

• Analyzers caught API misuse, бірақ never fixed.

Ашығын айтқанда, warning - production-ға scheduled bug.

Code Example

public static class Program
{
    static void Main(string[] args)
    {
        // CS0168: Variable declared but never used
        int unusedVariable;

        // CS8600: Converting null literal or possible
        // null value to non-nullable type
        string nullableStr = GetNullableString();

        // CS8602: Dereference of a possibly null reference
        Console.WriteLine($"Length: {nullableStr.Length}");
    }

    // Method that can return null
    private static string? GetNullableString()
    {
        return DateTime.Now.Second % 2 == 0 ? "Test string" : null;
    }
}

Error List CS0168, CS8600 және CS8602 reports етеді, бірақ build still finishes successfully: zero errors және three warnings.

TreatWarningsAsErrors

.csproj ішіне one line қосу every compiler warning-ті error етеді:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
    <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
  </PropertyGroup>
</Project>

Енді build fails fast болады.

Pros

1. Fresh compiler warnings production-ға ship болу chance zero.

2. Every developer үшін clear signal.

Cons

1. Legacy codebase already hundreds of diagnostics болса, бұл brutal болуы мүмкін.

WarningsAsErrors

More control керек болса, errors ретінде treated болуы керек warning codes ғана list жасаңыз:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
    <WarningsAsErrors>CS8600</WarningsAsErrors>
  </PropertyGroup>
</Project>

All other warnings warnings болып қалады және build сындырмайды. Multiple warning codes қосу үшін semicolons арқылы separate етіңіз:

<WarningsAsErrors>CS8600;CS8602</WarningsAsErrors>

WarningsNotAsErrors

Кейде inverse керек: most warnings errors болып қалсын, бірақ few noisy ones exception болсын.

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
    <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
    <WarningsNotAsErrors>CS0168</WarningsNotAsErrors>
  </PropertyGroup>
</Project>

Егер сізде already hundreds of warnings болса, бұл approach enough болмауы мүмкін. Келесі posts-тың бірінде оларды quickly cleaning up жасау tactics бөлісемін.

Key Takeaways

1. Бүгін ignored warning ертеңгі post-mortem болуы мүмкін.

2. TreatWarningsAsErrors - ең simple және reliable safety net.

3. WarningsAsErrors және WarningsNotAsErrors selective lists rule-ды gradually adopt етуге мүмкіндік береді.

4. Signal clean болуы үшін compiler switches, analyzers және formatting automate етіңіз.

Warnings-ті қазір lock down етіңіз, сонда production environment кейін тынышырақ ұйықтайды.