�fix: fix typo with inspection

Author: owonie

.vitepress/ch.mts

@@ -112,7 +112,7 @@ function sidebar(): DefaultTheme.Sidebar {
               text: "使其从上到下顺利阅读",
               items: [
                 {
-                  text: "A. 减少视点转换",
+                  text: "A. 减少视点转移",
                   link: "/ch/code/examples/user-policy"
                 },
                 {

ch/code/community.md

@@ -25,8 +25,7 @@ comments: false
 
 ## 为好代码标准添加意见
 
-如果对好代码的标准有意见，或者想提出新的观点，可以参与投票选出你认为更好的代码，并留下自己的意见。
-与社区沟通，共同构建更加丰富而深入的标准。
+如果对好代码的标准有意见，或者想提出新的观点，可以参与投票选出你认为更好的代码，并留下自己的意见。与社区沟通，共同构建更加丰富而深入的标准。
 
 这可以成为一个契机，帮助你确立判断两段代码之间哪一段更好的标准。
 

ch/code/examples/condition-name.md

@@ -49,20 +49,20 @@ const matchedProducts = products.filter((product) => {
 
 通过明确命名筛选同类且价格范围的商品条件，可以避免追踪复杂的条件表达式，清晰表达代码的意图。
 
-## 🔍 深入了解： 为条件式命名的标准
+## 🔍 深入了解：为条件式命名的标准
 
 什么时候适合给条件表达式或函数命名并将其提取？
 
 ### 适合为条件命名的情况
 
-- **处理复杂逻辑时**: 当条件语句或函数中的复杂逻辑跨越多行时，最好为其命名，明确展示函数的作用。这样可以提高代码可读性，维护和审查变得更加容易。
+- **处理复杂逻辑时**：当条件语句或函数中的复杂逻辑跨越多行时，最好为其命名，明确展示函数的作用。这样可以提高代码可读性，维护和审查变得更加容易。
 
-- **需要重用时**: 如果同一逻辑可能在多个地方反复使用，可以通过声明变量或函数来实现重用。这样可以减少代码重复，便于后续的维护。
+- **需要重用时**：如果同一逻辑可能在多个地方反复使用，可以通过声明变量或函数来实现重用。这样可以减少代码重复，便于后续的维护。
 
-- **需要单元测试时**: 分离函数后，可以独立编写单元测试。单元测试可以轻松验证函数是否正常工作，尤其在测试复杂逻辑时非常实用。
+- **需要单元测试时**：分离函数后，可以独立编写单元测试。单元测试可以轻松验证函数是否正常工作，尤其在测试复杂逻辑时非常实用。
 
 ### 不需要为条件命名的情况
 
-- **当逻辑简单时**: 如果逻辑非常简单，实际上不需要为其命名。例如，将数组中的元素翻倍的代码`arr.map(x => x * 2)`，即使不命名，也很直观。
+- **当逻辑简单时**：如果逻辑非常简单，实际上不需要为其命名。例如，将数组中的元素翻倍的代码 `arr.map(x => x * 2)` ，即使不命名，也很直观。
 
-- **当只使用一次时**: 如果某个逻辑在代码中只出现一次，而且逻辑并不复杂，那么在匿名函数中直接处理逻辑可能更加直观。
+- **当只使用一次时**：如果某个逻辑在代码中只出现一次，而且逻辑并不复杂，那么在匿名函数中直接处理逻辑可能更加直观。

ch/code/examples/http.md

@@ -47,7 +47,7 @@ export async function fetchUser() {
 
 ## ✏️ 尝试改善
 
-为了提高函数行为的可预测性，在服务中自定义函数时，应该使用与库函数明显区分开来的、具有描述行的名称。
+为了提高函数行为的可预测性，在服务中自定义函数时，应该使用与库函数明显区分开来的、具有描述性的名称。
 
 ::: code-group
 

ch/code/examples/magic-number-cohesion.md

@@ -6,7 +6,7 @@
 
 **魔数**(Magic Number)指的是缺乏明确说明而直接插入的数值。
 
-例如，直接使用 `404` 来表示未找到（Not Found）的 HTTP 状态码，或者直接使用 `86400` 秒来表示一整天的时间。
+例如，直接使用 `404` 来表示未找到（Not Found）的 HTTP 状态码，或者直接使用 `86400` 秒来表示一天的时间。
 
 ## 📝 代码示例
 

ch/code/examples/magic-number-readability.md

@@ -6,7 +6,7 @@
 
 **魔数**(Magic Number)指的是缺乏明确说明而直接插入的数值。
 
-例如，直接使用 `404` 来表示未找到（Not Found）的 HTTP 状态码，或者直接使用 `86400` 秒来表示一整天的时间。
+例如，直接使用 `404` 来表示未找到（Not Found）的 HTTP 状态码，或者直接使用 `86400` 秒来表示一天的时间。
 
 ## 📝 代码示例
 

ch/code/examples/submit-button.md

@@ -5,7 +5,7 @@
 </div>
 
 如果不同时运行的代码被放在同一个函数或组件中，就很难一眼看清他们各自的作用。
-由于实现过程中充满了复杂的分支，使得很难理解每个部分的作用。
+实现过程中内含复杂的分支，很难理解代码各个部分的作用。
 
 ## 📝 代码示例
 
@@ -41,7 +41,7 @@ function SubmitButton() {
 所以代码阅读者需要考虑的语境过多。
 
 例如，在下面的代码中，蓝色部分表示当用户具有仅查看权限（`'viewer'`）时运行的代码，红色部分表示当用户是普通用户时运行的代码。
-由于不同时运行的代码交织在一起，这给理解代码带来了负担。
+由于不同时运行的代码交织在一起，理解代码时产生负担。
 
 ![](../../images/examples/submit-button.png)
 
@@ -70,4 +70,4 @@ function AdminSubmitButton() {
 ```
 
 - 随着原本分散在 `<SubmitButton />` 代码各处的分支合并为一，分支数量减少。
-- `<ViewerSubmitButton />` 和 `<AdminSubmitButton />` 各自值管理一个分支，所以代码阅读者需要考虑的语境减少。
+- `<ViewerSubmitButton />` 和 `<AdminSubmitButton />` 各自仅管理一个分支，所以代码阅读者需要考虑的语境减少。

ch/code/examples/user-policy.md

@@ -1,10 +1,10 @@
-# 减少视点转换
+# 减少视点转移
 
 <div style="margin-top: 16px">
 <Badge type="info" text="可读性" />
 </div>
 
-在阅读代码时，反复浏览代码的各个部分，或者在多个文件、函数、变量之间翻看阅读的现象被称为 **视点转移**。
+在阅读代码时，反复浏览代码的各个部分，或者在多个文件、函数、变量之间翻看阅读的现象被称为**视点转移**。
 随着视点的多次转移，需要理解代码的时间也随之增加，很难把握代码的整体语境。
 
 如果将代码编写成从上到下、在一个函数或文件中就能顺序阅读的方式，代码阅读者可以迅速理解其功能。
@@ -14,7 +14,7 @@
 下列代码会根据用户的权限显示不同的按钮。
 
 - 如果用户权限是管理员（Admin），则显示 `Invite` 和 `View` 按钮。
-- 如果用户权限是只读用户（Viewer），则非激活 `Invite` 按钮，显示 `View` 按钮。
+- 如果用户权限是仅查看用户（Viewer），则非激活 `Invite` 按钮，显示 `View` 按钮。
 
 ```tsx
 function Page() {
@@ -51,14 +51,14 @@ const POLICY_SET = {
 为了理解这段代码中为何 `Invite` 按钮被非激活，你需要按照 `policy.canInvite` → `getPolicyByRole(user.role)` → `POLICY_SET` 的顺序，在代码中上下翻阅进行阅读。
 在此过程中，发生了三次视点转移，使得代码阅读者很难维持上下文的语境，增加了理解的难度。
 
-虽然使用 `POLICY_SET` 等抽象来按权限管理按钮状态在复杂权限体系中很有用，但在当前简单场景下却增加了阅读者的代码理解难度。같은
+虽然使用 `POLICY_SET` 等抽象来按权限管理按钮状态在复杂权限体系中很有用，但在当前简单场景下却增加了阅读者的代码理解难度。
 
 ## ✏️ 尝试改善
 
 ### A. 展开并明确展示条件
 
 直接在代码中明确展示了基于权限的条件。这样一来，代码中很容易看出 `Invite` 按钮何时会被非激活。
-只需阅读代码的上下文，就能一眼看清处理权限的逻辑。코드를 위에서 아래로만 읽으면 한눈에 권한을 다루는 로직을 파악할 수 있어요.
+只需阅读代码的上下文，就能一眼看清处理权限的逻辑。
 
 ```tsx
 function Page() {

ch/code/index.md

@@ -4,7 +4,7 @@ comments: false
 
 # 易于修改的代码
 
-好的前端代码是 **易于修改的** 代码。
+好的前端代码是**易于修改的**代码。
 在实现新需求时，能够轻松修改和部署的代码被认为好的代码。
 你可以根据四个标准判断代码是否易于修改。
 
@@ -25,7 +25,7 @@ comments: false
   - [为复杂条件命名](./examples/condition-name.md)
   - [为魔数命名](./examples/magic-number-readability.md)
 - **使其从上到下顺利阅读**
-  - [减少视点转换](./examples/user-policy.md)
+  - [减少视点转移](./examples/user-policy.md)
   - [简化三元运算符](./examples/ternary-operator.md)
 
 ## 2. 可预测性
@@ -37,7 +37,7 @@ comments: false
 
 - [避免命名重复](./examples/http.md)
 - [统一同类函数的返回类型](./examples/use-user.md)
-- [解释隐藏的逻辑](./examples/hidden-logic.md)
+- [揭示隐藏的逻辑](./examples/hidden-logic.md)
 
 ## 3. 内聚性
 
@@ -74,8 +74,8 @@ comments: false
 
 遗憾的是，这四个标准很难同时兼顾。
 
-例如，通过共同化和抽象化提高代码的内聚性，可确保函数或变数总是一同修改。代码进一步抽象化后，可读性也会随之降低。
+例如，通过通用化和抽象化提高代码的内聚性，可确保函数或变数总是一同修改。然而，代码进一步抽象化后，可读性也会随之降低。
 
-允许代码重复可以减少代码的影响范围，从而降低耦合性。然而，这也可能导致在修改一处代码时，另一处未被及时修改，从而影响内聚性。
+允许代码重复，可以减少代码的影响范围，从而降低耦合性。然而，这也可能导致在修改一处代码时，另一处未被及时修改，从而降低内聚性。
 
 前端开发者需要结合当前面临的具体情况，深入思考并在不同价值之间权衡取舍，以确保代码在长期内更易于维护和修改。