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.
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.
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 -Pre
Or for the Visual Basic version:
Install-Package CodeCracker.VisualBasic -Pre
Or use the Package Manager in Visual Studio.
There is also a version for both named
If you want the alpha builds that build on each push to the repo, add https://www.myget.org/F/codecrackerbuild/ 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.
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
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.
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:
Issues and task board
Definition of Ready (DoR)
An item should only have its work started after the backlog item is ready. We have defined ready as:
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.
These are the 4 severity levels supported on Roslyn and how they are understood on the Code Cracker project:
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:
Once it is Ready and agreed on by any one 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, specially 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 there. Don't clone from the main CodeCracker repository. Before you start coding create a new branch and name it in a way that makes sense for the issue that you will be working on. Don't work on the
When you commit, mention the issue number use the pound sign (#). Avoid making a lot of small commits unless they are meaningful. For most analyzers and code fixes a single commit should be enough. If you prefer to work with a lot commits at the end squash them.
Make your first commit lines mean something, specially the first one. Here and here are some tips on a good commit first line/message.
Do not, under any circumstance, reformat the code to fit your standards. Follow the project standards, and if you do not agree with them discuss them openly with the Code Cracker community. Also, avoid end of line white spaces at all costs. Keep your code clean.
Always write unit tests for your analyzers, code fixes, fix all providers and analyzers.
When you are done, pull the changes from the
You have to do that in the command line:
# add the main repo with the `codecracker` name git remote add code-cracker https://github.com/code-cracker/code-cracker.git # checkout the master branch git checkout master # download the latest changes from the master repo git pull code-cracker master # go back to your working branch git checkout <youbranchname> # integrate your changes git merge master # solve integration conflicts
You can solve the conflicts in your favorite text editor, or, if you are using Visual Studio, you can use it as well. Visual Studio actually presents the conflict in a very nice way to solve them. Also, on the
If you know git well, you can rebase your changes instead of merging them. If not, it is ok to merge them. When your changes are up to date with the
After your pull request is accepted you may delete your local branch if you want. Update your
If your pull request is denied try to understand why. It is not uncommon that PRs are denied but after some discussing and fixing they are accepted. Work with the community to get it to be the best possible code. And thank you!
Rules for contribution
If you work on something that you have not yet discussed with the maintainers there is a chance the code might be denied because they might find the analyzer/fix is not necessary, or duplicated, or some other reason. They are easily reachable through Twitter or on Github. Before you code discuss it with it them.
Small code changes or updates outside code files will eventually be made by the core team directly on
Contributors can be found at the contributors page on Github.
What are the maintainers responsibilities?
The maintainers have to:
To become part of the core team one has to be invited. Invitations happen only if all the core team agrees.
If a member of the core team is not active for at least to months, they will probably be removed from the core team.
Please see our contact page.
This software is open source, licensed under the Apache License, Version 2.0. See LICENSE.txt for details. Check out the terms of the license before you contribute, fork, copy or do anything with the code. If you decide to contribute you agree to grant copyright of all your contribution to this project, and agree to mention clearly if do not agree to these terms. Your work will be licensed with the project at Apache V2, along the rest of the code.