[DON'T MERGE] Review additional coding style suggestions #8347
Conversation
|
|
||
| Single variable lambdas should use `x` as the variable name (based on lambda calculus λx). Multi variable lambdas should use descriptive names, where `x` can be used for the main iterated item like `(x, index) => ...`. Name `c` can be used for context of Roslyn callback. | ||
|
|
||
| Short names can be used as parameter and variable names, namely `SyntaxTree tree`, `SemanticModel model`, `SyntaxNode node` and `CancellationToken cancel`. | ||
|
|
||
| ### Method names | ||
|
|
||
| FIXME Avoid Get prefixes for method names. Save three characters when it only gets x.Foo.Bar. |
There was a problem hiding this comment.
I would suggest to vote about this one in the 4th step of our process.
| Unit tests for common C# and VB.NET rules should use two aliases `using CS = SonarAnalyzer.Rules.CSharp` and `using VB = SonarAnalyzer.Rules.VisualBasic`. Test method names should have `_CS` and `_VB` suffixes. | ||
|
|
||
| Unit tests for single language rule should not use alias nor language method suffix. | ||
|
|
||
| Variable name `sut` (System Under Test) is recommended in unit tests that really tests a single unit (contrary to our usual rule integration unit tests). | ||
|
|
||
| FIXME - Avoid names without meaning like `foo`, `bar`, `baz`. OR KISS? |
There was a problem hiding this comment.
I would suggest to vote about this one in the 4th step of our process.
|
|
||
| Unit test method names: | ||
| - Underscore in UT names separates logical groups, not individual words. | ||
| - FIXME: what should the name pattern be? NEEDS DISCUSSION ([many patterns](https://dzone.com/articles/7-popular-unit-test-naming) and also [Microsoft convention](https://learn.microsoft.com/en-us/dotnet/core/testing/unit-testing-best-practices#naming-your-tests) - I'd go for MS convention) |
There was a problem hiding this comment.
I would suggest to vote about this one in the 4th step of our process.
| { "there": 42 }, | ||
| } | ||
| ``` | ||
| * FIXME - align on how to use collection initializers int[] x = [ 1, 2, 3 ] or old style (see [slack discussion](https://sonarsource.slack.com/archives/C01H2B58DE1/p1697103918957899?thread_ts=1696951023.295859&cid=C01H2B58DE1)) |
There was a problem hiding this comment.
I would suggest to vote about this one in the 4th step of our process.
|
Kudos, SonarCloud Quality Gate passed!
|
|
Kudos, SonarCloud Quality Gate passed!
|
| { "hey" : 1 }, | ||
| { "there": 42 }, |
There was a problem hiding this comment.
Wrong sytnax.
| { "hey" : 1 }, | |
| { "there": 42 }, | |
| ["hey"] = 1, | |
| ["there"] = 42 |
There was a problem hiding this comment.
It's my typo, sorry for that Andrei.
And Tim, the one I wanted to suggest is this one:
var dict = new Dictionary<int,int>
{
{ 1, 2 },
{ 3, 4 },
};|
|
||
| ## Comments | ||
|
|
||
| * Code should contain as few comments as necessary in favor of well-named members and variables. | ||
| * Comments should generally be on separate lines. | ||
| * Comments on the same line with code are acceptable for short lines of code and short comments. | ||
| * Documentation comments for abstract methods and their implementations should be placed only on the abstract method, to avoid duplication. _When reading the implementation, the IDE offers the tooling to peek in the base class and read the method comment._ | ||
| * Avoid using comments for "Arrange, Act, Assert" in UTs, unless the test is complex. | ||
| * Use single-line comments. Exception: `Internal /* for testing */ void Something()`. |
There was a problem hiding this comment.
The naming here is confusing since this is a single line.
| * Use single-line comments. Exception: `Internal /* for testing */ void Something()`. | |
| * Use double-slash comments only. Exception: `Internal /* for testing */ void Something()`. |
There was a problem hiding this comment.
Or maybe rather "Do not use /* ... */."
|
|
||
| * When to factorize: two is a group, three is a crowd. | ||
| * Less is more. | ||
| * Rely on Roslyn Type inference to reduce used characters. |
There was a problem hiding this comment.
What do you mean by "used characters"?
| @@ -218,6 +285,15 @@ It can still be used when and where it makes sense. For instance, when a class h | |||
| implementing generic interfaces (such as `IComparable`, `IDisposable`), it can make sense to have regions | |||
| for the implementation of these interfaces. | |||
|
|
|||
| ## Spacing | |||
|
|
|||
| * Avoid spaces unless they bring clarity and help the reader understand logical groups. Prefer spaces over comments. | |||
There was a problem hiding this comment.
By spaces you mean newlines?
It's a bit confusing, someone might read this as using new int[]{1,2,3} instead of new int[] { 1, 2, 3 }
There was a problem hiding this comment.
yes, empty lines, I will update
No description provided.