[Tracking] Code Spell-Checking Sprint

[KlausLoeffelmann]

This is an approach suggestion for now, please feel free to comment.

Comments and variables in the source code still contain a LOT of typos or weird "spelling variations".
I would suggest, we create a list of areas (doing it all at the same time is WAY too invasive of course) for tracking, and then put the sub issues derived from that out there up-for-grabs, after we've defined, how we want to tackle this. Here is a rule list as a first suggestion:

• Spellcheck/Formatting - don't do anything else: Sometimes you see a "potential quick change", like lambda-ing a property getter. Resist! 😸 Let's concentrate on spellchecking and reformatting, but not refactoring, no matter how tempting!
• (Obvious) Typos inside of comments: Correct typos indicated by VS, but do not correct overzealously, meaning: If how an indicated typo to solve is not immediate clear to you, just leave it. If it's an impactful change (like a typo which you're not sure to correct appears 20 times in a source file), rather create a new issue.
• Double-Space-Rule: Eliminate double-spaces behind a terminal punctuation, since this is a) a phased-out rule, which is no longer practiced, b) was US/English only and doesn't compute for an international audience and c) gets in the way, if it is applied accidentally inside of XML comments.
• Typos inside of local variables: Correct obvious typos in local variables, if the names are NOT abbreviated. Also correct accidentally used camelcAsenAming (camelCaseNaming), but do not introduce camel case naming, unless you can answer "What would @JeremyKuhne or @lonitra do" confidently: The reason is, that we have a lot of Win32 API calls in the repo, and those variables have a naming standard which consist of a lot weird abbreviations and in addition is often just not camelCase, and not even camelCaseIsh.
• Scope of other member items: NEVER change member names, which are protected, internal (Friend), virtual (Overridable) let alone public. If there is an obvious typo in such a member, please create a new issue so we can discuss, if we want to touch it (sometimes even changing an Internal member can be a breaking change, since ... you know ... Reflection...).

• Control.cs (Sub-issue/PR)
• Application.cs (Sub-issue/PR)
• DataGridView (Sub-issue/PR)
• [...to extend...] (Sub-issue/PR)

@Olina-Zhang, once we finalize this item and know what we want to do, we should take it over to the Designer repo, and - as suggestion - do the same?

[paul1956]

I have done this to all the VB code except possibly the 2 spaces after periods and 100% sentences with period in XML comments. The biggest offender is the resource and language files which I am not comfortable changing.

Also missing "see" attribute in XML Comments (how many and when).

What about changing attr to attribute in local names and other misspellings in local variables? VS considers anything 4 characters or longer misspelled if it's not in the dictionary. For words with special meaning/casing/spelling is there a way in a repo to add to spell checker?

I will take on finishing the VB code if no one else wants to when exact scope is clear.

[paul1956]

@merriemcgaw how do I volunteer? I would like to try 1, There are two things that are easy to do, change local variable like attr to attribute (154 occurrences) it would include typeattr to typeAttribute and changing behaviour in behavior (29 occurrences) in comments. Also changing period with 2 spaces to period and 1 space.

Another issue causing a lot suggestions is below, I have no idea how to fix, should I just open a new issue?

Severity	Code	Description	Project	File	Line	Suppression State	Details
Message (active)	IDE0130	Namespace "System.Windows.Forms" does not match folder structure, expected "System.Windows.Forms.System.Windows.Forms.Accessibility"	System.Windows.Forms	C:\Repos\Winforms\src\System.Windows.Forms\src\System\Windows\Forms\Accessibility\AccessibleRoleControlTypeMap.cs	6		

[merriemcgaw]

@paul1956 please go ahead and open a separate issue for the message above.

And I think you just volunteered 😉

[paul1956]

@merriemcgaw i will open the separate issue a namespace warning but not volunteering as its a C# issue and solving it is way beyond my C# skills.

I will open 2 separate issues (if necessary) on attrib and 2 spaces after period and volunteer for those. Also the biggest use of 2 periods after space is resource strings, I assume you don’t want me to touch those.

Where does one open issues about the Repo, none of the public issues seem to fit?

[paul1956]

@merriemcgaw C# has quoted strings with 2 periods after space. I think that is a separate issue that need to be opened. Also, XML Summy comments that are extremely long and don't wrap at column 120.

[merriemcgaw]

@paul1956 I think you're right. Let's open a tracking issue on the content of quoted strings because I think that will take a bit more to do just right.