Merge pull request #537 from gedakc/fix-typos-in-contributions

Fix minor typos in Contributing guidelines

CONTRIBUTING.md

@@ -40,24 +40,24 @@ The documentation is available [here](https://flake8.pycqa.org/en/latest/).
 The `setup.cfg` file in the root of this project has the following settings:
 ```conf
 [flake8]
-ignore = E203,E221,E226,E241,E251,E261,E266,E302,E305
+ignore = E203,E221,E226,E228,E241,E251,E261,E266,E302,E305
 max-line-length = 99
 exclude = docs/*
 ```
 
 The command line equivalent, with reporting, is:
 ```bash
-flake8 . --count --ignore E203,E221,E226,E241,E251,E261,E266,E302,E305 --max-line-length=99 --show-source --statistics
+flake8 . --count --ignore E203,E221,E226,E228,E241,E251,E261,E266,E302,E305 --max-line-length=99 --show-source --statistics
 ```
 
-Passing this check is required before contributuions are merged into the `main` branch. This is
+Passing this check is required before contributions are merged into the `main` branch. This is
 checked automatically when you make a pull request. You can run the `flake8` command locally to
 check beforehand. The full command will give you a detailed description of the code lines that do
 not conform to the standard.
 
 ## Ignored Errors
 
-Some errors are ignored in novelWriter, for various reasons. In addition, novelWriter sues camelCase
+Some errors are ignored in novelWriter, for various reasons. In addition, novelWriter uses camelCase
 function and variable names due to this being the standard for the Qt libraries, and also because of
 the author's personal preferences.
 
@@ -81,6 +81,9 @@ operator precedence like `2*a + 3*b` instead of `a * a + 3 * b`. Generally, don'
 `*`, `/` and `**`, but do use spaces around `+` and `-`. For appending strings, the spaces can be
 dropped. Don't use the `+` operator for appending multiple strings. Use formatting instead.
 
+**E228** missing whitespace around modulo operator  
+**Reason:** Column alignment.
+
 **E241:** multiple spaces after ‘,’  
 **Reason:** Column alignment.
 
@@ -99,5 +102,5 @@ like markdown headers.
 make it easier to see which class just ended. The double line break is then redundant.
 
 **E305:** expected 2 blank lines after end of function or class  
-**Reason:** Instead, _always_ end a function with a `return`, preferrably indented at function
+**Reason:** Instead, _always_ end a function with a `return`, preferably indented at function
 level. The end of the function is then clear.