Skip to content

Update basic documentation and add analyzer documentation and process #8

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Jul 10, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions CODE-OF-CONDUCT.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,6 @@
# Code of Conduct

This project has adopted the code of conduct defined by the Contributor Covenant
to clarify expected behavior in our community.

For more information, see the [.NET Foundation Code of Conduct](https://dotnetfoundation.org/code-of-conduct).
7 changes: 7 additions & 0 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
# Contributing

We welcome contributions. If you want to contribute to existing issues, check the
[help wanted](https://github.com/rjmurillo/EffectiveCSharp.Analyzers/labels/help%20wanted) or
[good first issue](https://github.com/rjmurillo/EffectiveCSharp.Analyzers/labels/good%20first%20issue) items in the backlog.

If you have new ideas or want to complain about bugs, feel free to [create a new issue](https://github.com/rjmurillo/EffectiveCSharp.Analyzers/issues/new).
48 changes: 48 additions & 0 deletions docs/DOCUMENTING-ANALYZERS.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,48 @@
# Documenting analyzers

Full documentation is available in [Effective C#: 50 Specific Ways to Improve your C#](https://www.oreilly.com/library/view/effective-c-50/9780134579290/) by author [Bill Wagner](https://github.com/BillWagner). Documentation of each rule is a derative work inspired by the explanation, prose, and examples contained within the book.

Code analyzers and code fixes will be named and numbered similarly to the book (e.g., _Item 2: Prefer readonly to const_ is tracked as [`ECS0002`](./rules/ECS0002.md)). Some of the author's guidance is opinionated, and unless otherwise indicated as prescriptive guidance, will show up as `Info` or `Suggestion`. In your code base you can change the effective severity of the rules to suit your needs.

For each analyzer, it will be documented as follows:

1. Within the `docs` at the root of the analyzer project

2. A subdirectory `docs/rules`

The rationale for this suggestion is that there might be other documents in the `docs` directory (like this one). Keeping the rule documentation in its own subdirectory makes it easier to distinguish from other documentation.

3. A copy of the [Rule reference page template](RULE-REFERENCE-TEMPLATE.md) is used to create documentation with the following convention:

`<DiagnosticId>.md`

For example, for _Item 2: Prefer readonly to const_ the prefix for Effective CSharp Analyzers is `ECS` and the identifier for the rule is normalized to four places. The documentation would be named `ECS0002.md`

4. The template is filled in with information about the analyzer.

5. Provide a stable URI for each page

If you use a URI that points to the GitHub repo `main` branch, then the URI will change whenever the source tree is rearranged. If rule behavior changes over time, it will be out of phase with the documentation used to describe the rule in the version used to identify the issue.

To avoid this issue, we use [`Nerdbank.GitVersioning`](https://github.com/dotnet/Nerdbank.GitVersioning) to stamp the commit into the assembly.

6. In each analyzer, set the value of the `HelpLinkUri` property of the `DiagnosticDescriptor` to the URI.

For example, the [PreferReadonlyOverConstAnalyzer](../src/EffectiveCSharp.Analyzers/PreferReadonlyOverConstAnalyzer.cs) produces a diagnostic with rule ID `ECS0002` ("Prefer readonly over const").

```csharp
internal const string Id = DiagnosticIds.PreferReadonlyOverConst;

private static readonly DiagnosticDescriptor Rule = new(
id: Id,
title: "Prefer readonly over const",
messageFormat: "Consider using readonly instead of const for better flexibility",
category: "Maintainability",
defaultSeverity: DiagnosticSeverity.Info,
isEnabledByDefault: true,
helpLinkUri: $"https://github.com/rjmurillo/EffectiveCSharp.Analyzers/blob/{ThisAssembly.GitCommitId}/docs/{Id}.md");
```

The documentation for the rule is placed in to `docs/rules/ECS0002.md`.

**Note**: Some analyzers produce diagnostics with more than one rule. In such a case, create a separate reference page for each rule following the conventions above.
33 changes: 33 additions & 0 deletions docs/RULE-REFERENCE-TEMPLATE.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,33 @@
# RULEID: Friendly rule name

This rule is described in detail in [Effective C#: 50 Specific Ways to Improve your C#](https://www.oreilly.com/library/view/effective-c-50/9780134579290/).

## Cause

## Rule description

## How to fix violations

## When to suppress warnings

## Example of a violation

### Description

### Code

```csharp
```

## Example of how to fix

### Description

Check notice on line 24 in docs/RULE-REFERENCE-TEMPLATE.md

View check run for this annotation

Codacy Production / Codacy Static Code Analysis

docs/RULE-REFERENCE-TEMPLATE.md#L24

Multiple headings with the same content

### Code

Check notice on line 26 in docs/RULE-REFERENCE-TEMPLATE.md

View check run for this annotation

Codacy Production / Codacy Static Code Analysis

docs/RULE-REFERENCE-TEMPLATE.md#L26

Multiple headings with the same content

```csharp
```

## Related rules

[RULEID: Friendly related rule name](https://stable-uris/MyRuleId.md)
Loading