[Tracking] Code Spell-Checking Sprint
- Dominant language
- C#
- Stars
- 4.9k
- Forks
- 1.1k
- Avg merge
- 20h 23m
- Merged PRs (30d)
- 103
Description
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?
Contributor guide
Assessment
This issue has not been assessed yet.