fix grammar, describe go integrations

home search stat 
    
      
diff --git a/notes-go/lint-n-format.md b/notes-go/lint-n-format.md
index 374cc16..1bbde86 100644
--- a/notes-go/lint-n-format.md
+++ b/notes-go/lint-n-format.md
@@ -2,30 +2,30 @@
 
 ## Linters
 
-The first linter you face coming into Go is [go vet](https://golang.org/cmd/vet/). This is a built-in linter targeted mostly on finding bugs rather than code style.
+The first linter you face coming into Go is [go vet](https://golang.org/cmd/vet/). It is a built-in linter targeted mostly at finding bugs rather than code style.
 
-Another official linter from the Go core team is [golint](https://github.com/golang/lint). This one is targeted on finding not bugs but mostly style issues from the official [code review guide](https://github.com/golang/go/wiki/CodeReviewComments) and [effective go](https://golang.org/doc/effective_go.html).
+Another official linter from the Go core team is [golint](https://github.com/golang/lint). This one is targeted at finding not bugs but mostly style issues from the official [code review guide](https://github.com/golang/go/wiki/CodeReviewComments) and [effective go](https://golang.org/doc/effective_go.html).
 
-If you want catch more bugs and write more effective code, consider running more linters. Go has plenty of them. Of course, it would be hard to download, install, and run all of them. Luckily, we have an amazing [golangci-lint](https://golangci-lint.run/). This is a wrapper, providing a single unified way to run and configure [more than 40 linters](https://golangci-lint.run/usage/linters/). Keep in mind that by default it runs only a few of them, so it's good to have an explicit configuration with listing of all linters you want to use in the project. And if you want to see from what you can start, below are some most notable linters.
+If you want to catch more bugs and write more effective code, consider running more linters. Go has plenty of them. Of course, it would be hard to download, install, and run all of them. Luckily, we have amazing [golangci-lint](https://golangci-lint.run/). It is a wrapper, providing a single unified way to run and configure [more than 40 linters](https://golangci-lint.run/usage/linters/). Keep in mind that by default, it runs only a few of them, so it's good to have an explicit configuration with a listing of all linters you want to use in the project. And if you'd like to know from what you can start, below are some most notable linters.
 
 A few biggest linters:
 
-+ [staticcheck](https://staticcheck.io/docs/) has a huge collection of checks, target on finding bug, improving code readability and performance, simplifying code.
++ [staticcheck](https://staticcheck.io/docs/) has a huge collection of checks, target on finding bugs, improving code readability and performance, simplifying code.
 + [go-critic](https://go-critic.github.io/) has also many different checks of all kinds: bugs, performance, style issues. It is positioned as "the most opinionated linter", so, probably, you want to disable a few checks but only a few. Don't ask what's better, staticcheck or go-critic, just use both.
 + [gosec](https://github.com/securego/gosec) is targeted exclusively on finding security issues.
 
 A few more specific but helpful linters:
 
 + [errcheck](https://github.com/kisielk/errcheck) finds errors that you forgot to check. [Always check all errors](https://github.com/golang/go/wiki/CodeReviewComments#handle-errors) and do something meaningful, don't let them pass unnoticed.
-+ [ineffassign](https://github.com/gordonklaus/ineffassign) finds an assignment that has no effect. In most of the cases, it happens when you assigned an error into previously created `err` variable but forgot to check it.
++ [ineffassign](https://github.com/gordonklaus/ineffassign) finds an assignment that has no effect. In most cases, it happens when you assigned an error to a previously created `err` variable but forgot to check it.
 
 Useful linters without golangci-lint integration (yet?):
 
 + [revive](https://github.com/mgechev/revive) is a stricter and faster alternative to golint with a lot of rules. Most of the rules are about code style and consistency, some are opinionated. No need to worry, the linter allows to configure or disable any check.
-+ [sqlvet](https://github.com/houqp/sqlvet) lints SQL quearies in Go code for syntax errors and unsafe constructions.
++ [sqlvet](https://github.com/houqp/sqlvet) lints SQL queries in Go code for syntax errors and unsafe constructions.
 + [semgrep-go](https://github.com/dgryski/semgrep-go) finds simple bugs.
 
-What should you use? Everything you can! If you have an existing project, enable all linters that are easy to integrate, and then slowly, one by one, try and enable all that look reasonable and helpful. Just give it a try! Also, be mindful of your coworkers, help them to fix a code that a lintert complains about, and be ready to disable a check if it works not so well for your codebase, especially if it is only about a code style.
+What should you use? Everything you can! If you have an existing project, enable all linters that are easy to integrate, and then slowly, one by one, try and enable all that look reasonable and helpful. Just give it a try! Also, be mindful of your coworkers, help them to fix a code that a linter complains about, and be ready to disable a check if it works not so well for your codebase, especially if it is only about a code style.
 
 Further reading:
 
@@ -37,9 +37,9 @@ Further reading:
 Your basic toolkit:
 
 + One of the most famous go features is a built-in code formatter [gofmt](https://golang.org/cmd/gofmt/). Gofmt is your friend, use gofmt. There is no specification about what exactly gofmt does because the code evolves and changes rapidly, fixing formatting bugs and corner cases.
-+ [goimports](https://pkg.go.dev/golang.org/x/tools/cmd/goimports) is another must-have code formatter. It automatically adds missed imports and removes unused ones. I so used to it that I don't remember when I last time added an import manually.
-+ [goreturns](https://github.com/sqs/goreturns) fills in `return` statement with zero values to match the function return type. It is helpful for saving a few keystrokes. However, be careful using it, the project seems to be not in an active development for a long while.
-+ [gofumpt](https://github.com/mvdan/gofumpt) is a stricter fork `gofmt` with more rules. It is fully compatible with `gofmt` and really helpful.
++ [goimports](https://pkg.go.dev/golang.org/x/tools/cmd/goimports) is another must-have code formatter. It automatically adds missed imports and removes unused ones. I am so used to it that I don't remember when I last time added an import manually.
++ [goreturns](https://github.com/sqs/goreturns) fills in `return` statement with zero values to match the function return type. It helps save a few keystrokes. However, be careful using it, the project seems to be not in active development for a long while.
++ [gofumpt](https://github.com/mvdan/gofumpt) is a stricter fork `gofmt` with more rules. It is fully compatible with `gofmt` and helpful.
 
 For historical reasons, Go extension for VSCode support specifying only one code formatter at once. So, every next level tool calls all previous tools under the hood:
 
@@ -47,24 +47,33 @@ For historical reasons, Go extension for VSCode support specifying only one code
 + `goreturns` calls `goimports`.
 + `gofumpt` provides `gofumports` which is `goimports` calling `gofumpt` instead of `gofmt`.
 
-So, I use `gofumports` as my code formatter in VSCode, which basically includes `gofmt`, `gofumpt`, and `goimports`.
+So, I use `gofumports` as my code formatter in VSCode, which includes `gofmt`, `gofumpt`, and `goimports`.
 
 A few smaller code formatters that can come in handy:
 
-+ [golines](https://github.com/segmentio/golines) formats long lines of code. Probably, you want be happy with the result and would like to manually reformat it. However, it's still better than piece of code hiding outisde your screen boundaries. There is issue "[consider breaking long lines](https://github.com/mvdan/gofumpt/issues/2)" in gofumpt, so there is a chance that soon gofumpt will take care of it as well.
-+ [keyify](https://github.com/dominikh/go-tools/tree/master/cmd/keyify) turns unkeyed struct literals (`T{1, 2, 3}`) into keyed ones (`T{A: 1, B: 2, C: 3}`). This description says everything. Always use keyed struct literals because order is hard to remember, can be changed, and so on.
++ [golines](https://github.com/segmentio/golines) formats long lines of code. Probably, you won't be happy with the result and would like to manually reformat it. However, it's still better than a piece of code hiding outside your screen boundaries. There is an issue "[consider breaking long lines](https://github.com/mvdan/gofumpt/issues/2)" in gofumpt, so there is a chance that soon gofumpt will take care of it as well.
++ [keyify](https://github.com/dominikh/go-tools/tree/master/cmd/keyify) turns unkeyed struct literals (`T{1, 2, 3}`) into keyed ones (`T{A: 1, B: 2, C: 3}`). This description says everything. Always use keyed struct literals because the order is hard to remember, can be changed, and so on.
 + [unconvert](https://github.com/mdempsky/unconvert) removes unnecessary type conversions. It's not so important but makes the code a bit cleaner.
 
 See [awesome-go-code-formatters](https://github.com/life4/awesome-go-code-formatters) for more tools.
 
 ## Custom rules
 
-If you have a custom rule you'd like to validate or reformat in your project, there are few linters and tools that can be helpful:
+If you have a custom rule you'd like to validate or reformat in your project, there are a few linters and tools that can be helpful:
 
-+ [gomodguard](https://github.com/ryancurrah/gomodguard) allows to forbid usage of particular modules or domains.
-+ [ruleguard](https://github.com/quasilyte/go-ruleguard) is not actually a linter at the moment but a framework for fast writing of simple rules. It has a [custom DSL](https://github.com/quasilyte/go-ruleguard/blob/master/docs/gorules.md) that can be used to lint code as well as rewrite specific constructions. It [can be integrated](https://quasilyte.dev/blog/post/ruleguard/#using-from-the-golangci-lint) with golangci-lint via go-critic.
++ [gomodguard](https://github.com/ryancurrah/gomodguard) allows forbidding usage of particular modules or domains.
++ [ruleguard](https://github.com/quasilyte/go-ruleguard) is not a linter at the moment but a framework for fast writing of simple rules. It has a [custom DSL](https://github.com/quasilyte/go-ruleguard/blob/master/docs/gorules.md) that can be used to lint code as well as rewrite specific constructions. It [can be integrated](https://quasilyte.dev/blog/post/ruleguard/#using-from-the-golangci-lint) with golangci-lint via go-critic.
 
 ## Integrations
 
 + [Golangci-lint has integrations with everything](https://golangci-lint.run/usage/integrations/).
++ Gofmt is the standard and integrated in every IDE.
 + [Gofumpt has integration with VSCode and a guide for GoLand](https://github.com/mvdan/gofumpt#installation).
++ Other tools can be integrated into git pre-commit hooks.
+
+Frameworks for pre-commit hooks:
+
++ [pre-commit](https://github.com/pre-commit/pre-commit) (Python)
++ [lefthook](https://github.com/Arkweid/lefthook) (Go)
++ [husky](https://github.com/typicode/husky) and [lint-staged](https://github.com/okonet/lint-staged) (JS)
++ [overcommit](https://github.com/sds/overcommit) (Ruby)
diff --git a/notes-python/lint-n-format.md b/notes-python/lint-n-format.md
index 0236803..5f1679f 100644
--- a/notes-python/lint-n-format.md
+++ b/notes-python/lint-n-format.md
@@ -2,11 +2,11 @@
 
 ## Linters
 
-+ [pyflakes](https://github.com/PyCQA/pyflakes) -- checks only obvious bugs and never code style. There are no opinionated checks. Pyflakes must be enabled in any project, and all error must be fixed.
-+ [pycodestyle](https://github.com/PyCQA/pycodestyle) -- most important code style checker. Controls compatibility with [PEP-8](https://www.python.org/dev/peps/pep-0008/) that is standard de-facto for how Python code should look like. Initially, with tool was called pep8, but [renamed after Guido's request](https://github.com/PyCQA/pycodestyle/issues/466).
-+ [flake8](https://gitlab.com/pycqa/flake8) is the most famous Python linter. First of all, it is a framework allowing to write your own linters that can be configured and run in a unified way. Pyflakes and pycodestyle are default dependencies of Flake8. If you just install and run Flake8 in clean environment, you'll see their checks.
++ [pyflakes](https://github.com/PyCQA/pyflakes) -- checks only obvious bugs and never code style. There are no opinionated checks. Pyflakes should be enabled in any project, and all errors must be fixed.
++ [pycodestyle](https://github.com/PyCQA/pycodestyle) -- most important code style checker. Controls compatibility with [PEP-8](https://www.python.org/dev/peps/pep-0008/) that is standard de-facto for how Python code should look like. Initially, the tool was called pep8, but [renamed after Guido's request](https://github.com/PyCQA/pycodestyle/issues/466).
++ [flake8](https://gitlab.com/pycqa/flake8) is the most famous Python linter. First of all, it is a framework allowing you to write custom linters that can be configured and run in a unified way. Pyflakes and pycodestyle are default dependencies of Flake8. If you just install and run Flake8 in a clean environment, you'll see their checks.
 + [flakehell](https://github.com/life4/flakehell) is a wrapper around flake8. It provides additional commands and features, nicer output, and more control over plugins and checks.
-+ [PyLint](https://github.com/PyCQA/pylint) is an alternative linter with many checks that are missed in flake8 plugins. Some of them is opinionated and can be difficult to satisfy. However, most of the checks are really useful. FlakeHell supports PyLint as a plugin. The important thing to remember is that PyLint is slow because of heavy inference of types and values.
++ [PyLint](https://github.com/PyCQA/pylint) is an alternative linter with many checks that are missed in flake8 plugins. Some of them are opinionated and can be difficult to satisfy. However, most of the checks are useful. FlakeHell supports PyLint as a plugin. The important thing to remember is that PyLint is slow because of heavy inference of types and values.
 + [wemake-python-styleguide](https://github.com/wemake-services/wemake-python-styleguide) is a flake8/flakehell plugin, providing a lot of checks. It is fast, strict, and helpful, finds many bugs, style issues, enforces consistency. It is very opinionated, so you probably want to disable some (most of the) checks.
 
 See [awesome-flake8-extensions](https://github.com/DmytroLitvinov/awesome-flake8-extensions) for more plugins.
@@ -18,16 +18,16 @@ Python has quite a few code formatters with different code style and philosophy
 There are 3 all-in-one code formatters, all of them are supported by VSCode out of the box:
 
 + [autopep8](https://github.com/hhatto/autopep8) is the oldest and the least opinionated Python code formatter. It formats the code to follow [PEP-8](https://www.python.org/dev/peps/pep-0008/) and nothing else. Under the hood, it uses the mentioned above [pycodestyle](https://github.com/PyCQA/pycodestyle). So, if the project passes pycodestyle (or flake8) checks, you can safely use autopep8.
-+ [black](https://github.com/python/black) is "uncompromising" and opinionated code formatter. The code style is close to PEP-8 (there are few exceptions) but also it has an opinion about pretty much everything. It has some issues that make it a bad choice for an experienced team. However, it can be a good choice for an unexperienced team, an open-source project, or for a quick formatting of an old and dirty code. See [Don't use Black in your team](https://articles.orsinium.dev/python/black/) for more information.
-+ [yapf](https://github.com/google/yapf) is a code formatter from Google. Like black, it reformats everything. The main difference is that every small detail in yapf is configurable. It makes sense to use yapf for a project with a codestyle stat is different from PEP-8. However, if you have choice, prefer using PEP-8 for all projects.
++ [black](https://github.com/python/black) is "uncompromising" and opinionated code formatter. The code style is close to PEP-8 (there are few exceptions) but also it has an opinion about pretty much everything. It has some issues that make it a bad choice for an experienced team. However, it can be a good choice for an inexperienced team, an open-source project, or for quick formatting of an old and dirty code. See [Don't use Black in your team](https://articles.orsinium.dev/python/black/) for more information.
++ [yapf](https://github.com/google/yapf) is a code formatter from Google. Like black, it reformats everything. The main difference is that every small detail in yapf is configurable. It makes sense to use yapf for a project with a code style that is different from PEP-8. However, if you have a choice, prefer using PEP-8 for all projects.
 
 A few small but helpful formatters:
 
-+ [isort](https://github.com/PyCQA/isort) groups and sorts imports. Usually, imports section in Python is quite messy, and isort brings an order here. It is a powerful tool and every stylistic decision there can be configured. Use isort.
++ [isort](https://github.com/PyCQA/isort) groups and sorts imports. Usually, the imports section in Python is quite messy, and isort brings an order here. It is a powerful tool and every stylistic decision there can be configured. Use isort.
 + [add-trailing-comma](https://github.com/asottile/add-trailing-comma) adds trailing commas to multiline function calls, function signatures, and literals. Also, it fixes indentation for closing braces.
-+ [autoflake](https://github.com/myint/autoflake) removes unused imports and variables. It is helpful for cleaning up a messed code.
++ [autoflake](https://github.com/myint/autoflake) removes unused imports and variables. It helps clean up a messed code.
 + [docformatter](https://github.com/myint/docformatter) formats docstrings according to [PEP-257](https://www.python.org/dev/peps/pep-0257/).
-+ [pyupgrade](https://github.com/asottile/pyupgrade) changes the code to use newer Python features. It will replace old comprehensions style, old formatting via `%`, drop unicode and long literals, simplify `super` calls and much more.
++ [pyupgrade](https://github.com/asottile/pyupgrade) changes the code to use newer Python features. It will replace old comprehensions style, old formatting via `%`, drop Unicode and long literals, simplify `super` calls, and much more.
 + [unify](https://github.com/myint/unify) formats string literals to use one style of quotes (single or double).
 
 See [awesome-python-code-formatters](https://github.com/life4/awesome-python-code-formatters) for more tools.