brightlight / youshouldspellcheck.analyzer Goto Github PK

We have to differentiate between "identifiers" and "normal text", as totally different rules apply:

• Identifiers cannot have whitespaces between words. Instead, they use casing to separate words.
• in contrast, normal text uses whitespaces to separate words
• normal text must support abbreviations, which sometimes themselves may contain whitespaces (ideally non-breaking space)
• normal text might contain GUIDs (e.g. in certain arguments)
• normal text might contain certain annotations like "ToDo xy/dd.mm.yyyy" which should not raise issues
• word recognition might be tricky, e.g. "Delivery-planned/actual"
• identifiers can contain numbers, e.g. "Information3"

If text contains "/" without spaces, like costs/revenues, it is treated as one word, in consequence often flagged as an issue and suggestions show up.

I would like the possibility to only check attribute properties at first (to reduce false-positives if code is not prepared for a spellchecker). Therefore it should be possible to enable code inspections for attributes without also enabling code inspections for all other string literals as well.
At the moment, both are controlled by YS101.

For easier usage there should be a nuget package to add this analyzer to projects.

This analyzer has now reached beta stage. I can experimentally use it at work for "real-life" testing, but there is no documentation yet regarding how to add/use this analyzer, about the format of the XML configuration file, how to add the configuration file to projects ("AdditionalFiles"), etc.

Support Release tracking analyzer

The configuration should allow to exclude certain types or even whole namespaces from the checks.
Using some sort of wildcard or regex would probably be the most flexible way to do this.

Examples:

• Exclude namespace
  Company.Department.Area
• Exclude namespace and beneath
  Company.Department.Area.*
• Exclude one type
  Company.Department.Area.TypeName.*
• Exclude one method in one component
  Company.Department.Area.TypeName.MethodeName.*

But how to exclude only the check of attributes or certain types of attributes and not also the check of identifiers?

It must be possible to define language even on sub-attribute level. For instance, certain attribute arguments represent normal text (e.g. "Caption", "Description") while other arguments reference identifiers (e.g. resource strings) and therefore must be spellchecked using identifier rules (or not be checked at all, because the referenced identifier will be checked anyway).
Also, normal text (like "Caption" and "Description") might require a different language than identifiers.

In the current state, there is an extra rule-id per identifier type. Each rule (code inspection) can be enabled separately. Also, the valid language(s) can be set for each identifier type separately.
I can't imagine a situation where it would make sense to use a different language for classes and methods, or methods and events, etc. So maybe the configuration should be simplified.

Regarding the rule identifications: my suggestion would be this:

• digit 1 identifies the used "engine":
  • 1: Hunspell (local dictionary)
  • 2: LanguageTool
• digit 2-3 identify the item type that is checked
  • 01: string literal
  • 02: XML comment
  • 03: identifier (can be split into more detail if necessary later)
• digit 4-5 identify the type of finding. Depends on used engine (see digit 1)
  • HUnspell: always 00 ("general", Hunspell, doesn't support categories)
  • LanguageTool: some sort of category-id mapping

Support custom dictionaries - per language - to keep track of company-specific vocabulary and abbreviations.

The suggestions shown for a flagged identifier (or part of it) ar exactly the ones that the spellchecker provided. This means that sometimes compound words, or words with spaces are suggested.
For instance, "ShowPopupMenu" will suggest "pop-up" and "pop up" as replacements for "Popup".

I get a NullReferenceException when an issue is shown and I want to open the available code fixes ("suggestions") in the context menu. I have not changed the analyzer for at least months. Only thing that has changed is that I have updated my Visual Studio 2019.

System.NullReferenceException : Object reference not set to an instance of an object.
   at YouShouldSpellcheck.Analyzer.YouShouldSpellcheckAnalyzerCodeFixProvider.Suggestions(String word,IEnumerable`1 languages,Dictionary`2 allSuggestions)
   at YouShouldSpellcheck.Analyzer.YouShouldSpellcheckAnalyzerCodeFixProvider.Suggestions(Diagnostic diagnostic,String& offendingWord,Dictionary`2 allSuggestions,IEnumerable`1 languages)
   at async YouShouldSpellcheck.Analyzer.TextCodeFixProvider.RegisterCodeFixesAsync(<Unknown Parameters>)
   at async Microsoft.CodeAnalysis.CodeFixes.CodeFixService.GetCodeFixesAsync(<Unknown Parameters>)
   at async Microsoft.CodeAnalysis.Extensions.IExtensionManagerExtensions.PerformFunctionAsync[T](<Unknown Parameters>)

It should be possible to run a grammar check for longer texts using LanguageTool.

As this will produce a lot of requests, a locally running server instance should be used (see http://wiki.languagetool.org/http-server), not the public one.

API description: http://wiki.languagetool.org/public-http-api

There should probably be a cache in place, to the analyzers don't fire the same requests again and again.

Currently, squiggly lines sometimes appear slightly off. This is the case when the string contains escape characters, for instance for quotes (\"). Verbatim strings can also contain such escape characters (example: @"This is a ""quote""").

    [Display(Name = "Special \"escapng\" and \na new lines")]
    public string Name3 { get; }

For instance, for public const string XmlVersion = "Version"; I get the suggestion to replace "Xml" with "XML". That suggestion is fine for literal strings or XML comments, but my code styles require pacal casing for identifiers, so XmlVersion is correct and XMLVersion would be wrong (and trigger other issues).

Multi-line XML comments are currently checked line-by-line separately. That's okay if you just do a spellcheck. But it's not optimal for a grammar check (LanguageTool).