Skip to content

Code Style Initiative #10270

Open
18 of 30 issues completed
Open
Task
18 of 30 issues completed
@harshit7962

Description

@harshit7962

Description

This is a tracker issue to ensure that our code style and guidelines align with the standards set by dotnet. This is a follow-up of the issue .

As in the PR we have added .editorconfig that helps us ensure these style requirements during the build. Given the current state of code, quite a few of these analyzers are disabled in src/Microsoft.DotNet.Wpf/src and src/Microsoft.DotNet.Wpf/cycle-breakers in their respective .editorconfig. The overall idea is to get rid of .editorconfig(s) in the src and have a single .editorconfig (the one in the root).

Steps to proceed with the task

Assume that we are fixing IDE0044: Make field readonly

  1. Remove the analyzer's severity from .editorconfig in src folder. It is generally added as dotnet_diagnostic.IDE0044.severity = suggestion.
  2. Using the script start-vs.cmd, open WPF in Visual Studio
  3. Build the solution (if not already built).
  4. The build is likely to fail with errors/warnings of IDE0044.
  5. Click on any of the warning/error from Error List window, and it should navigate to the line that violates the rule.
  6. On that line, use the shortcut Ctrl + . or right click to find Quick Actions and Refactoring
  7. It should open the possible fixes, one of which would be related to the warning being fixed (as in the image below).
    Image
  8. As in the image above, click on Fix all occurrences in Solution, which should resolve the warning in the solution.

Alternatively

After the step 1, use the command
dotnet format analyzers --diagnostics IDE0044 --severity warn .\src\Microsoft.DotNet.Wpf\src\PresentationBuildTasks\PresentationBuildTasks.csproj. This will fix occurrences of IDE0044 violations in PresentationBuildTasks.csproj. Similarly, fix the occurrences in all the csproj.

Raising the PR

  • There should be no changes to the public API contract. If there are violations, instead of fixing them, suppress the warning.
  • Apart from the suppressions, ensure that all the changes are automated.
  • There should be no behavioral changes in these PRs; they should only comprise the fixes for these analyzer changes.
  • Unless the changes in one resolution are very small (10-20 files), raise a single PR for a single fix. This will help in the easier review process.
  • If fixing a single warning changes a lot of files (>=500), try creating sub-PRs for individual assemblies if that helps reduce the count.
  • Name the PR with the pre-text [StyleCleanUp] for better visibility.
  • As with other PRs, each PR will be taken for a test pass.
  • Try branching out fixes on top of others to minimize merge conflicts. Let us know the order in which you would like the PRs to be taken.

Warnings to be removed

Feel free to create individual sub-issues and assign it to yourself before picking up any of these.

Sub-issues

Metadata

Metadata

Assignees

No one assigned

    Labels

    Good First Issuemetadata: Issue should be easy to implement, good for first-time contributorsarea-StylingIndicates if an issue or a PR is for style changeshelp wanted[up-for-grabs] Good issue for external contributors

    Type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions