Update rules/Proj0039.md

Co-authored-by: Laura Kramer <[email protected]>

Author: Corniel

rules/Proj0039.md

@@ -8,7 +8,7 @@ ancestor: MSBuild
 MSBuild can be configured to [threat all warnings as errors]( https://learn.microsoft.com/dotnet/csharp/language-reference/compiler-options/errors-warnings#treatwarningsaserrors).
 How tempting this may feel (ideally a solution should not contain any warnings), there are some objections to consider. Because such a policy might be counterproductive.
 
-## 1. We’re not developing in a perfect world
+## 1. We’re not developing in a perfect world
 When a warning pops up, the developer facing it, should solve the issue. That why we have static code analysis enabled after all. The fact that this is not happening hints that we do not live in a perfect world. By changing the severity to error for all rules, the world we live in will not change.
 
 A developer that was not willing to resolve a warning is most likely also not willing to resolve an error beyond the bare minimum: that means by suppressing the issue, disabling the rule, or by adjusting the code just to satisfy the rule, none of these resolutions is guaranteed to be an improvement.
@@ -28,7 +28,7 @@ It is possible to create static code analysis with an error severity. The reason
 Some extensions in Visual Studio (like VS Spell Checker or SonarQube IDE) add warnings to the build output as they are de facto analysers. As they are not configured by the solution but by the environment of the developer, those developers can not build the solution.
 
 ## 6. False positives
-Although analyser rule builders – like us – try their best to come up with robust and correct analysers, it turns out that now and then a rule reports a false positive. In such cases it is better to not to have to supress the issue, or to adjust the code just so satisfy the rule, but to file a bug report and wait for an update that fixes the FP.
+Although analyser rule builders – like us – try their best to come up with robust and correct analysers, it turns out that now and then a rule reports a false positive. In such cases it is better to not to have to supress the issue, or to adjust the code just so satisfy the rule, but to file a bug report and wait for an update that fixes the FP.
 
 In the end, warnings are an indication as technical debt, and should be handled a such: with care. Using tools like Qodana and SonarQube can create reports on pull requests to reduce the introduction of new warnings (ideally to zero).
 
@@ -40,7 +40,7 @@ On a regular basis the team working on the project should allocate time to addre
 
   <PropertyGroup>
     <TargetFramework>net8.0</TargetFramework>
-    <TreatWarningsAsErrors>true</ TreatWarningsAsErrors>
+    <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
   </PropertyGroup>
 
 </Project>