diff --git a/STYLE.md b/CODINGSTYLE.md
similarity index 59%
rename from STYLE.md
rename to CODINGSTYLE.md
index 1a1e2187b..2c9f26679 100644
--- a/STYLE.md
+++ b/CODINGSTYLE.md
@@ -8,11 +8,11 @@ Maintaining proper coding style is very important for any large software project
 - It provides for an aesthetically pleasing experience when one reads the code
  
 ## General typographic conventions
-- Maintain maximum line length of 80 characters. Even though today’s monitors often are very wide and it’s often not a problem to have 120 characters displayed in an editor, maintaining shorter line lengths improves readability. It also allows others to have two parallel windows open, side by side, each with different parts of the source code.
+- Maintain a maximum line length of 80 characters. Even though today’s monitors often are very wide and it’s often not a problem to have 120 characters displayed in an editor, maintaining shorter line lengths improves readability. It also allows others to have two parallel windows open, side by side, each with different parts of the source code.
 - Naming conventions:
     - `ClassName`, 
     - `someVariable`, `someFunction`, `someArgument`
-- Maintain a decent amount of horizontal spacing, e.g. add a space after `if` or before `{` in PHP, Python, JavaScript and similar in other languages. Whether and where to also use spaces within expressions, such as `(y*4+8)` vs. `(y * 4 + 8)` is left to the developer’s judgment. Do not put spaces immediately after or before the brackets in expressions, so avoid constructs like this: `if ( condition )` and use ones like this: `if (condition)` instead.
+- Maintain a decent amount of horizontal spacing, e.g. add a space after `if` or before `{` in PHP, Python, JavaScript, and similar in other languages. Whether and where to also use spaces within expressions, such as `(y*4+8)` vs. `(y * 4 + 8)` is left to the developer’s judgment. Do not put spaces immediately after or before the brackets in expressions, so avoid constructs like this: `if ( condition )` and use ones like this: `if (condition)` instead.
 - Use descriptive names for variables and functions. At a time when most editors have auto-completion features, there is no excuse for using short variable names.
 - Comments should be indented together with the code, e.g. like this:
     ```
@@ -25,11 +25,11 @@ Maintaining proper coding style is very important for any large software project
 ## File naming conventions
 - Never use spaces within file names
 - **PHP:** Write file names in title case ,e.g. `AttachmentTool.php`
-- **Python:** Write file names with small letters, use dash to separate words, rather than underscores, e.g. `load_warninglists.py`
+- **Python:** Write file names with small letters, use a dash to separate words, rather than underscores, e.g. `load_warninglists.py`
 - **JavaScript:** Write file names with small letters, use dashes to separate words, rather than underscores, e.g. `bootstrap-colorpicker.js`
 
 ## General programming style guidelines
-- Always prefer readability over trickiness! No need using tricks to save a few lines of code.
+- Always prefer readability over trickiness! No need to use tricks to save a few lines of code.
 - Make sure your code compiles and builds without warnings
 - Always think first about interfaces (e.g. function arguments, or class methods) and data structures before you start writing the actual code.
 - Use comments to explain non-trivial code fragments, or expected behavior of more complex functions, if it is not clear from their name.
@@ -40,13 +40,13 @@ Maintaining proper coding style is very important for any large software project
         // Return style
         return style;
       }
-- In production code there should really be little to no commented or disabled code fragments. Do not use comments to disable code fragments, unless you really need to. But generally, there is little excuse to keep old, unused code fragments in the code. One should really use the functionality provided by the source code management system, such as git, instead. E.g. create a special branch for storing the old, unused code – this way you will always be able to merge this code into upstream in the future.
+- In production code, there should be little to no commented or disabled code fragments. Do not use comments to disable code fragments, unless you need to. But generally, there is little excuse to keep old, unused code fragments in the code. Instead, use the functionality provided by the source code management system, such as git. For example, create a special branch for storing the old, unused code – this way you will always be able to merge this code into upstream in the future.
 - Try not to hardcode values in the code. 
 
 ## Commit message guidelines
 
-Please attempt to follow our [commit messages best practices](https://github.com/MISP/MISP/wiki/CommitMessageBestPractices) when writing your Git commit messages. 
-In addition, when committing changes that will resolve an issue once merged, include #NNNN in the commit message, NNNN being the issue number. 
+Please attempt to follow our [commit messages best practices](https://github.com/MISP/MISP/wiki/CommitMessageBestPractices) when writing your git commit messages. 
+Also, when committing changes that will resolve an issue once merged, include #NNNN in the commit message, NNNN being the issue number. 
 Then, GitHub will automatically reference this commit on the corresponding issue, once the branch is pushed to our Git repository. 
 For example:
 ```