quicksketch
commented
11 months ago I think of cspell as a tool to prevent most misspellings but not everything. It still won't catch grammar errors or similar sounding words (i.e. there/their/they're). That's fine. It catches most typos and that's what I think it's best at. So I would be in favor of enabling this setting and trimming down the allowed words dictionary.
Alternatively, we could establish a policy to always use underscores where possible for variables and array keys etc.
I think that is already the case? Or maybe it's a loose convention that derives from the variable naming policy. I would be in favor of this too.
klonos
This is a follow-up to #4537 in an effort to optimize the tasks our PRs are running. In the PR for that issue, when trying to address cspell tripping over the word
pageviews, I have elected to correct the two instances in our codebase topage viewsinstead (these were in docblocks by the way - not in actual code, so that was easy/safe). More generally though, there are various instances in our codebase that are compound words which are tripping cspell, and which they wouldn't if they were split using spaces, dashes, or underscores as appropriate per case.https://github.com/klonos/backdrop/blob/1.x/.cspell/backdrop.dic is currently 571 lines long (and constantly growing obviously), and it includes at least 234 entries (about 41% of the total) that are compound words:
If not all of these, then most of them could be ignored if we used the
--allow-compound-wordsglobal option for cspell (and there's alsocspell:enableCompoundWordsandcspell:disableCompoundWordsif we wanted to do that per-file/per-line).Pros:
Cons:
This function is meantto be used internally.themeanttotypo would not be caught)Alternatively, we could establish a policy to always use underscores where possible for variables and array keys etc. ...so it should be
my_keywordand$my_new_passwordinstead ofmykeywordor$mynewpassword. Then we could go and change these things in our codebase accordingly (where applicable/safe).The other option is for us to do nothing about this (just keep adding words to our custom dictionary as cspell complains about them in various PRs), in which case this issue can be closed.