code-cracker

Code Cracker

An analyzer library for C# and VB that uses Roslyn to produce refactorings, code analysis, and other niceties.

Check the official project site on code-cracker.github.io. There you will find information on how to contribute, our task board, definition of done, definition of ready, etc. You can find this document in the following languages This is a community project, free and open source. Everyone is invited to contribute, fork, share and use the code. No money shall be charged by this software, nor it will be. Ever.

Features

The list of features is documented here: http://code-cracker.github.io/diagnostics.html

Design

Installing

You may use CodeCracker in two ways: as an analyzer library that you install with NuGet into your project, or as a Visual Studio extension. The way you want to use it depends on the scenario you are working on. You most likely want the Nuget package.

If you want the analyzers to work during your build, and generate warnings and errors during the build, also on build servers, then you want to use the Nuget package. The package is available on NuGet (C#, VB). If you want to be able to configure which analyzers are being used in your project, and which ones you will ignore, and commit those changes to source control and share with your team, then you also want the Nuget package.

To install from NuGet, for the C# version:

Install-Package CodeCracker.CSharp

Or for the Visual Basic version:

Install-Package CodeCracker.VisualBasic

Or use the Package Manager in Visual Studio.

There is also a version for both named CodeCracker only, but it makes no sense to get it, you should search for the C# or VB version.

If you want the alpha builds that build on each push to the repo, add this to your NuGet feed. We only push complete releases to Nuget.org, and commit builds go to Myget.org.

If you want global analyzers that will work on every project you open in Visual Studio, then you want the Extension. Grab the extension at the Visual Studio Extensions Gallery (C#, VB).

To build from source:

git clone https://github.com/code-cracker/code-cracker.git
cd CodeCracker
msbuild

Then add a reference to CodeCracker.dll from within the Analyzers node inside References, in Visual Studio.

TL;DR: If you want to use CodeCracker in all your projects, install the Visual Studio extension (C#, VB). If you want to use CodeCracker for just one project, install the Nuget package as described above.

SonarQube Plugin

CodeCracker has a SonarQube Plugin that can be downloaded at Plugins HomePage.

Contributing

The main supported IDE for development is Visual Studio 2017. We do not support VS 2015 anymore.

Questions, comments, bug reports, and pull requests are all welcome. Bug reports that include steps to reproduce (including code) are preferred. Even better, make them in the form of pull requests. Before you start to work on an existing issue, check if it is not assigned to anyone yet, and if it is, talk to that person. Also, check the project board and verify it is not being worked on (it will be tagged with the Working tag). If it is not being worked on, check if the item is Ready before you start. If the issue has the Working tag (working swimlane on Huboard) and has no Assignee then it is not being worked on by somebody on the core team. Check the issue's description to find out who it is (if it is not there it has to be on the comments). We are adding people that want to contribute to the Contributors team so we can always assign them to the issues, so during your first contribution you probably will be assigned to this team.

The easiest way to start is looking into the issues that are up for grabs. You may ask to work on any of them, read below to see how. You can also triage issues which may include reproducing bug reports or asking for vital information such as version numbers or reproduction instructions. If you would like to start triaging issues, one easy way to get started is to subscribe to code-cracker on CodeTriage.

If you are just starting with Roslyn, want to contribute, and feel you are not yet ready to start working on full analyzers or code fixes, you can start helping with areas that are less demanding. We have identified a few:

• Fixing bugs

  Still demands knowledge of Roslyn internals but it is easier than coming up with a full analyzer or code fix. Look for the bugs that are up for grabs.

• Documentation

  We are documenting all analyzers on the CodeCracker user site. There are lots of analyzers and code fixes to document.

• Localization/Translation

  We are starting to translate the analyzers and code fixes messages to other languages. If you want CodeCracker on your language feel free to create an issue and start working on it. If you want to help with an ongoing translation, comment on the existing issue and say you are ready to help. We also need to update existing analyzers, which were not created ready for localization.

Issues and task board

• The task board is at Huboard.
• You can also check the Github backlog directly.

Definition of Ready (DoR)

An item should only have its work started after the backlog item is ready. We have defined ready as:

1. Have most of the scenarios/test cases defined on the issue on Github

2. If it has an analyzer then

   复制

    1. The warning level of the analyzer must be in the issue's description (`Hidden`, `Information`, `Warning`, or `Error`)
    2. The diagnostics it provides should already have numeric ids defined formatted as `CC0000`.

3. If it has a code fix then the category should be in the issue's description. The supported categories are listed on the SupportedCategories.cs file.

4. Have some of the maintainers verify it (cannot be the same one who wrote the issue and/or test cases)

The first one is important so we have clearly defined what we will build. The last one is important so we don't go on building something that will not be usable, will hurt users, or will be a waste of effort.

View examples at issues #7 and #10.

Severity Levels

These are the 4 severity levels supported on Roslyn and how they are understood on the Code Cracker project:

1. Hidden: Only used for refactorings. See #66 (and its comments) to understand why.
2. Info: An alternative way (ex: replacing for with foreach). Clearly, a matter of opinion and/or current way could be correct, or maybe the new code could be correct. We cannot determine.
3. Warning: Code that could/should be improved. It is a code smell and most likely is wrong, but there are situations where the pattern is acceptable or desired.
4. Error: Clearly a mistake (ex: throwing ArgumentException with a non-existent parameter). There is no situation where this code could be correct. There are no differences of opinion.

You can read directly on Microsoft's source code how they interpret these levels.

Definition of Done

The DoD is still evolving. At the present time the checklist is as follows:

1. Builds

2. Has tests for analyzers, code fixes (including fix all providers) and refactoring

3. All tests pass

4. Analyzers follow the guidelines for names

   复制

    1. Always named `Analyzer`
    2. Always add the diagnostic id to the `DiagnosticIds.cs` file.

5. Code fixes should follow the guidelines for names

   复制

    1. Always named `CodeFixProvider`
    2. Always use the same diagnostic id added to the `DiagnosticIds.cs` file, unless you are writing a code fix for a diagnostic id raised by the C# compiler itself (starting with `CS`).

6. Fix all scenarios (fix all in a document, fix all in a project and fix all in solution) work. You might need to write a FixAllProvider. Check the DisposableVariableNotDisposedFixAllProvider as an example.

7. Follow the coding standards present on the project code files.

8. Works in Visual Studio

9. Uses localizable strings

Start working

Once it is Ready and agreed on by anyone from the core team, just state in a comment that you intend to start working on that item and mention any/all the maintainers (use @code-cracker/owners) so they can tag it correctly and move it on the board.

If you are not familiar with the way Github works you might want to check the Github guides, especially the Github flow one. The GitHub for the Roslyn Team video might help you as well, and it also explains some Git concepts.

To start working fork the project on Github to your own account and clone it **from the