SA1629 should ignore <c>
See original GitHub issue/// <param name="message">Format string of the log message in message template format. Example: <c>"User {User} logged in from {Address}."</c></param>
results in a warning for SA1629, not ending documentation with a period. Using <code>
in place of <c>
has the same result
if the <c>
tag is removed, there is no warning
Issue Analytics
- State:
- Created 5 years ago
- Comments:6 (5 by maintainers)
Top Results From Across the Web
StyleCopAnalyzers (C#) rule SA1629 leads to "not a valid ...
One of our active rules is SA1629: “Documentation text should end with period”. This diagnostic reports on the place where the missing period ......
Read more >Add option to ignore documentation errors on internal ...
I would expect the following when documentInternalElements or documentPrivateElements is false: SA1600: Never reported; SA1601: Never reported ...
Read more >How to fix / suppress SA1636 and SA1641 when reusing ...
I want to credit them correctly for their code. The following class raises warning SA1636 and also "SA1641: The file header company name...
Read more >SA1633: FileMustHaveHeader - StyleCop
This will cause StyleCop to ignore the file. This type of header should never be placed on top of a manually written code...
Read more >Auto Fix StyleCop Warnings with Free Extensions - Mike Conrad
Warning Detail Code Formatter Code Maid
SA1001 Commas should be followed by whitespace. Some Some
SA1002 Semicolons should not be preceded by a space. Some...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@martincostello that is covered by #2761
I’m not sure I agree with the example here. The
.
in this example is part of a string literal (an opaque character as opposed to the end of a sentence).I lean towards wontfix here. The longer this rule goes on, the more I find myself wishing it was included in #1057.