Tweaks from Dr. Taco, sixth order

.cspell.json

@@ -22,6 +22,7 @@
     "Cheburashka",
     "chucknorris",
     "cochinita",
+    "codebases",
     "Codeception",
     "colocated",
     "colocating",

manuscript/120_Linting.md

@@ -12,7 +12,7 @@ That’s where the _linters_ come in. Linters check the code to make sure it fol
 
 I> We talk about code style in the [Code style](#code-style) chapter.
 
-Like any tool, linters can make our lives easier and our codebase more consistent and free of bugs, or they could be abused and make our lives full of pain.
+Like any tool, linters can make our lives easier, keeping our codebases more consistent and free of bugs. But if abused, with too many rigid or unnecessary rules, they can fill our lives with pain.
 
 Almost anything that automates or simplifies bug fixing or code reviews is worth implementing as a linter rule. However, there are many, many ways linting can go wrong, and that is what we’re going to talk about in this chapter.
 
@@ -26,7 +26,7 @@ Let’s start with some healthy linting habits and ways to make linters work for
 
 ### Prefer to have too few linter rules than too many
 
-It’s a good idea to start with recommended configs (like ESLint’s `eslint:recommended`) and add only rules that are important for the team. The road to hell is paved with useless linter rules.
+It’s a good idea to start with recommended configs and add only rules that are important for the team. The road to hell is paved with useless linter rules.
 
 For example, the most minimal ESLint config could look like this:
 
@@ -57,24 +57,7 @@ export default [
 ];
 ```
 
-All rules in the recommended ESLint config are defined as errors.
-
-### Define autofixable linter rules as warnings
-
-Ideally, anything that could be fixed by a machine shouldn’t be marked as an error or warning or highlighted at all while we’re writing code; there’s no reason to distract us with things that don’t require our immediate attention.
-
-Here’s how we do it in ESLint:
-
-```js
-// eslint.config.mjs
-export default [
-  {
-    rules: {
-      curly: 'warn'
-    }
-  }
-];
-```
+All rules in the recommended ESLint config are already defined as errors.
 
 ### Clean up the rules regularly
 
@@ -266,9 +249,9 @@ I> We’ll cover a few exceptions later in this chapter. We talk more about code
 
 Unless the coding culture in the team is especially miserable (and in this case, instead of fighting it, you’re better off updating your CV), a linting setup that’s too rigid does more harm than good. It’s better to trust our colleagues and expect that they know how to do their job, allowing us to use linters to catch bugs and code reviews to discuss different approaches. There’s always more than one correct way to do something in programming, and a linter that enforces only one way doesn’t solve any real problems but makes our colleagues suffer more.
 
-## My top 11 linter rules that should have never existed
+## My top linter rules that should have never existed
 
-Many linter rules don’t solve any actual problems with the code; they merely enforce a particular way of writing code — a preference of one of the team members. Many of these rules are purely aesthetic.
+Many linter rules don’t fix any real problems in the code; they merely enforce a particular way of writing it, often based on personal preference. Many of these rules are purely aesthetic.
 
 Below is a selection of rules that create more problems than they solve. Luckily, none of these rules are included in recommended configs, but I’ve seen them all in real projects. These rules remind us that we shouldn’t try to validate and control everything. And I’m not the only one who [gets mad because of a linter rule](https://x.com/iamsapegin/status/1230760798584098817).
 
@@ -286,7 +269,7 @@ Some programmers believe that `null` and `undefined` have different semantics: t
 
 ### [no-else-return](https://eslint.org/docs/latest/rules/no-else-return)
 
-This rule forces us to write:
+This rule disallows `return` statements in the `else` block of `if` conditions. For example, it forces us to write:
 
 ```js
 function somethingToSomethingElse(something) {
@@ -840,7 +823,7 @@ There are two parts to setting up linters: project setup and editor configuratio
 
 Let’s start with the project configuration:
 
-1. Start with the recommended ESLint rules, `eslint:recommended`.
+1. Start with the ESLint recommended config.
 2. Add recommended configs of ESLint plugins for the project’s stack (see below).
 3. Add a few extra rules that make sense for your team.
 4. Add ESLint with autofix to a Git pre-commit or pre-push hook using [Husky](https://github.com/typicode/husky) and [lint-staged](https://github.com/lint-staged/lint-staged) to make sure that all the code in the repository is linted.

manuscript/130_Formatting.md

@@ -110,9 +110,9 @@ T> I use the [Rewrap](https://marketplace.visualstudio.com/items?itemName=stkb.r
 
 ### Run a formatter as a stand-alone tool
 
-Don’t use Prettier as an ESLint plugin because it marks each “incorrectly” formatted place as an error in the code. This isn’t helpful and distracts from the actual linting errors that we need to take care of. The whole idea of code autoformatting is that we no longer need to care about it. There’s no need to tell developers that something is wrong when no action is required from them.
+Don’t use Prettier as an ESLint plugin because it marks each “incorrectly” formatted line of code as an error. This isn’t helpful and distracts from actual linting errors that we need to take care of. The whole point of code autoformatting is that we no longer need to worry about it. There’s no need to tell developers that something is wrong when no action is required from them.
 
-![The curse of linting](images/curse-of-linting.jpeg)
+![The curse of linting: these errors are unhelpful and can be autofixed](images/curse-of-linting.jpeg)
 
 ## The ideal code formatting setup
 
@@ -150,3 +150,4 @@ Code formatters save us a lot of time and help us avoid the meta work of formatt
 Start thinking about:
 
 - Simplifying code when autoformatting makes it uglier.
+- Adding line breaks in comments to improve their readability.

manuscript/150_Editing.md

@@ -186,6 +186,8 @@ Here’s what I use to work with Git:
 - However, I rarely use Git commands directly and either use [git-friendly](https://github.com/git-friendly/git-friendly) or [my own aliases](https://github.com/sapegin/dotfiles/blob/master/tilde/.gitconfig) and scripts.
 - Occasionally I use [Lazygit](https://github.com/jesseduffield/lazygit) to quickly commit something in the command line.
 
+![Committing to Git in GitHub Desktop](images/github-desktop.png)
+
 What I like the most about committing from Visual Studio Code (besides its accessibility with a hotkey) is that I can set a large font size for the commit message field. Most Git tools set a tiny font, limit the size of the message field to one or two lines, and don’t let you change them. This is very uncomfortable, and I’m glad I can finally change it in the Code.
 
 ![Committing to Git in Visual Studio Code](images/vscode-spell-checker.png)

manuscript/160_Footer.md

@@ -4,7 +4,7 @@ All the topics covered in this book aren’t hard rules, but ideas for possible
 
 There are valid use cases for all programming techniques. Maybe even `goto`, who knows — I’m probably too young to know. The only certain thing is that the answer to any question about programming is: _it depends_. No matter how many likes this solution has on Stack Overflow, it may not be the best solution for your problem.
 
-So, the goal of this book isn’t to teach you how to write good code, but to help you to notice certain antipatterns, or code smells, that can _often_ (but not _always_) be improved, and give you the tools — techniques and patterns — to make those improvements.
+So, the goal of this book isn’t to teach you how to write good code, but to help you notice certain antipatterns, or code smells, that can _often_ (but not _always_) be improved, and give you the tools — techniques and patterns — to make those improvements.
 
 And remember: we write code for our colleagues and our future selves, so they can understand it. We should prioritize code readability and trust our gut feelings over whatever random people on the internet or linters tell us to do.