diff --git a/README.md b/README.md
index 2f0ce15..4a40ead 100644
--- a/README.md
+++ b/README.md
@@ -20,6 +20,8 @@ If you want to share a best practice, or think one of these guidelines should be
- [Testing](#testing)
- [Structure and Naming](#structure-and-naming)
- [Code style](#code-style)
+ - [Some code style guidelines](#code-style-check)
+ - [Enforcing code style standards](#enforcing-code-style-standards)
- [Logging](#logging)
- [API](#api)
- [API design](#api-design)
@@ -393,6 +395,9 @@ Having a good guideline for creating commits and sticking to it makes working wi

+
+### 7.1 Some code style guidelines
+
* Use stage-2 and higher JavaScript (modern) syntax for new projects. For old project stay consistent with existing syntax unless you intend to modernise the project.
_Why:_
@@ -451,6 +456,22 @@ Having a good guideline for creating commits and sticking to it makes working wi
_Why:_
> It makes it more natural to read the source code.
+
+### 7.2 Enforcing code style standards
+
+* Have your editor notify you about code style errors. Use [eslint-plugin-prettier](https://github.com/prettier/eslint-plugin-prettier) and [eslint-config-prettier](https://github.com/prettier/eslint-config-prettier) with your existing ESLint configuration. [read more...](https://github.com/prettier/eslint-config-prettier#installation)
+
+* Consider using Git hooks
+
+ _Why:_
+ > Git hooks greatly increase a developer's productivity. Make changes, commit and push to staging or production environments without the fear of breaking builds. [read more...](http://githooks.com/)
+
+* Use Prettier with a precommit hook
+
+ _Why:_
+ > While `prettier` itself can be very powerful, it's not very productive to run it simply as an npm task alone each time to format code. This is where `lint-staged` (and `husky`) come into play. Read more on configuring `lint-staged` [here](https://github.com/okonet/lint-staged#configuration) and on configuring `husky` [here](https://github.com/typicode/husky).
+
+
## 8. Logging