Skip to content

Commit e903783

Browse files
committed
�fix: fix typo with inspection
1 parent 783d461 commit e903783

File tree

9 files changed

+24
-25
lines changed

9 files changed

+24
-25
lines changed

.vitepress/ch.mts

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -112,7 +112,7 @@ function sidebar(): DefaultTheme.Sidebar {
112112
text: "使其从上到下顺利阅读",
113113
items: [
114114
{
115-
text: "A. 减少视点转换",
115+
text: "A. 减少视点转移",
116116
link: "/ch/code/examples/user-policy"
117117
},
118118
{

ch/code/community.md

Lines changed: 1 addition & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -25,8 +25,7 @@ comments: false
2525

2626
## 为好代码标准添加意见
2727

28-
如果对好代码的标准有意见,或者想提出新的观点,可以参与投票选出你认为更好的代码,并留下自己的意见。
29-
与社区沟通,共同构建更加丰富而深入的标准。
28+
如果对好代码的标准有意见,或者想提出新的观点,可以参与投票选出你认为更好的代码,并留下自己的意见。与社区沟通,共同构建更加丰富而深入的标准。
3029

3130
这可以成为一个契机,帮助你确立判断两段代码之间哪一段更好的标准。
3231

ch/code/examples/condition-name.md

Lines changed: 6 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -49,20 +49,20 @@ const matchedProducts = products.filter((product) => {
4949

5050
通过明确命名筛选同类且价格范围的商品条件,可以避免追踪复杂的条件表达式,清晰表达代码的意图。
5151

52-
## 🔍 深入了解: 为条件式命名的标准
52+
## 🔍 深入了解:为条件式命名的标准
5353

5454
什么时候适合给条件表达式或函数命名并将其提取?
5555

5656
### 适合为条件命名的情况
5757

58-
- **处理复杂逻辑时**: 当条件语句或函数中的复杂逻辑跨越多行时,最好为其命名,明确展示函数的作用。这样可以提高代码可读性,维护和审查变得更加容易。
58+
- **处理复杂逻辑时**当条件语句或函数中的复杂逻辑跨越多行时,最好为其命名,明确展示函数的作用。这样可以提高代码可读性,维护和审查变得更加容易。
5959

60-
- **需要重用时**: 如果同一逻辑可能在多个地方反复使用,可以通过声明变量或函数来实现重用。这样可以减少代码重复,便于后续的维护。
60+
- **需要重用时**如果同一逻辑可能在多个地方反复使用,可以通过声明变量或函数来实现重用。这样可以减少代码重复,便于后续的维护。
6161

62-
- **需要单元测试时**: 分离函数后,可以独立编写单元测试。单元测试可以轻松验证函数是否正常工作,尤其在测试复杂逻辑时非常实用。
62+
- **需要单元测试时**分离函数后,可以独立编写单元测试。单元测试可以轻松验证函数是否正常工作,尤其在测试复杂逻辑时非常实用。
6363

6464
### 不需要为条件命名的情况
6565

66-
- **当逻辑简单时**: 如果逻辑非常简单,实际上不需要为其命名。例如,将数组中的元素翻倍的代码`arr.map(x => x * 2)`,即使不命名,也很直观。
66+
- **当逻辑简单时**如果逻辑非常简单,实际上不需要为其命名。例如,将数组中的元素翻倍的代码 `arr.map(x => x * 2)` ,即使不命名,也很直观。
6767

68-
- **当只使用一次时**: 如果某个逻辑在代码中只出现一次,而且逻辑并不复杂,那么在匿名函数中直接处理逻辑可能更加直观。
68+
- **当只使用一次时**如果某个逻辑在代码中只出现一次,而且逻辑并不复杂,那么在匿名函数中直接处理逻辑可能更加直观。

ch/code/examples/http.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -47,7 +47,7 @@ export async function fetchUser() {
4747

4848
## ✏️ 尝试改善
4949

50-
为了提高函数行为的可预测性,在服务中自定义函数时,应该使用与库函数明显区分开来的、具有描述行的名称
50+
为了提高函数行为的可预测性,在服务中自定义函数时,应该使用与库函数明显区分开来的、具有描述性的名称
5151

5252
::: code-group
5353

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

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,7 @@
66

77
**魔数**(Magic Number)指的是缺乏明确说明而直接插入的数值。
88

9-
例如,直接使用 `404` 来表示未找到(Not Found)的 HTTP 状态码,或者直接使用 `86400` 秒来表示一整天的时间
9+
例如,直接使用 `404` 来表示未找到(Not Found)的 HTTP 状态码,或者直接使用 `86400` 秒来表示一天的时间
1010

1111
## 📝 代码示例
1212

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

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,7 @@
66

77
**魔数**(Magic Number)指的是缺乏明确说明而直接插入的数值。
88

9-
例如,直接使用 `404` 来表示未找到(Not Found)的 HTTP 状态码,或者直接使用 `86400` 秒来表示一整天的时间
9+
例如,直接使用 `404` 来表示未找到(Not Found)的 HTTP 状态码,或者直接使用 `86400` 秒来表示一天的时间
1010

1111
## 📝 代码示例
1212

ch/code/examples/submit-button.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -5,7 +5,7 @@
55
</div>
66

77
如果不同时运行的代码被放在同一个函数或组件中,就很难一眼看清他们各自的作用。
8-
由于实现过程中充满了复杂的分支,使得很难理解每个部分的作用
8+
实现过程中内含复杂的分支,很难理解代码各个部分的作用
99

1010
## 📝 代码示例
1111

@@ -41,7 +41,7 @@ function SubmitButton() {
4141
所以代码阅读者需要考虑的语境过多。
4242

4343
例如,在下面的代码中,蓝色部分表示当用户具有仅查看权限(`'viewer'`)时运行的代码,红色部分表示当用户是普通用户时运行的代码。
44-
由于不同时运行的代码交织在一起,这给理解代码带来了负担
44+
由于不同时运行的代码交织在一起,理解代码时产生负担
4545

4646
![](../../images/examples/submit-button.png)
4747

@@ -70,4 +70,4 @@ function AdminSubmitButton() {
7070
```
7171

7272
- 随着原本分散在 `<SubmitButton />` 代码各处的分支合并为一,分支数量减少。
73-
- `<ViewerSubmitButton />``<AdminSubmitButton />` 各自值管理一个分支,所以代码阅读者需要考虑的语境减少。
73+
- `<ViewerSubmitButton />``<AdminSubmitButton />` 各自仅管理一个分支,所以代码阅读者需要考虑的语境减少。

ch/code/examples/user-policy.md

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -1,10 +1,10 @@
1-
# 减少视点转换
1+
# 减少视点转移
22

33
<div style="margin-top: 16px">
44
<Badge type="info" text="可读性" />
55
</div>
66

7-
在阅读代码时,反复浏览代码的各个部分,或者在多个文件、函数、变量之间翻看阅读的现象被称为 **视点转移**
7+
在阅读代码时,反复浏览代码的各个部分,或者在多个文件、函数、变量之间翻看阅读的现象被称为**视点转移**
88
随着视点的多次转移,需要理解代码的时间也随之增加,很难把握代码的整体语境。
99

1010
如果将代码编写成从上到下、在一个函数或文件中就能顺序阅读的方式,代码阅读者可以迅速理解其功能。
@@ -14,7 +14,7 @@
1414
下列代码会根据用户的权限显示不同的按钮。
1515

1616
- 如果用户权限是管理员(Admin),则显示 `Invite``View` 按钮。
17-
- 如果用户权限是只读用户(Viewer),则非激活 `Invite` 按钮,显示 `View` 按钮。
17+
- 如果用户权限是仅查看用户(Viewer),则非激活 `Invite` 按钮,显示 `View` 按钮。
1818

1919
```tsx
2020
function Page() {
@@ -51,14 +51,14 @@ const POLICY_SET = {
5151
为了理解这段代码中为何 `Invite` 按钮被非激活,你需要按照 `policy.canInvite``getPolicyByRole(user.role)``POLICY_SET` 的顺序,在代码中上下翻阅进行阅读。
5252
在此过程中,发生了三次视点转移,使得代码阅读者很难维持上下文的语境,增加了理解的难度。
5353

54-
虽然使用 `POLICY_SET` 等抽象来按权限管理按钮状态在复杂权限体系中很有用,但在当前简单场景下却增加了阅读者的代码理解难度。같은
54+
虽然使用 `POLICY_SET` 等抽象来按权限管理按钮状态在复杂权限体系中很有用,但在当前简单场景下却增加了阅读者的代码理解难度。
5555

5656
## ✏️ 尝试改善
5757

5858
### A. 展开并明确展示条件
5959

6060
直接在代码中明确展示了基于权限的条件。这样一来,代码中很容易看出 `Invite` 按钮何时会被非激活。
61-
只需阅读代码的上下文,就能一眼看清处理权限的逻辑。코드를 위에서 아래로만 읽으면 한눈에 권한을 다루는 로직을 파악할 수 있어요.
61+
只需阅读代码的上下文,就能一眼看清处理权限的逻辑。
6262

6363
```tsx
6464
function Page() {

ch/code/index.md

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -4,7 +4,7 @@ comments: false
44

55
# 易于修改的代码
66

7-
好的前端代码是 **易于修改的** 代码。
7+
好的前端代码是**易于修改的**代码。
88
在实现新需求时,能够轻松修改和部署的代码被认为好的代码。
99
你可以根据四个标准判断代码是否易于修改。
1010

@@ -25,7 +25,7 @@ comments: false
2525
- [为复杂条件命名](./examples/condition-name.md)
2626
- [为魔数命名](./examples/magic-number-readability.md)
2727
- **使其从上到下顺利阅读**
28-
- [减少视点转换](./examples/user-policy.md)
28+
- [减少视点转移](./examples/user-policy.md)
2929
- [简化三元运算符](./examples/ternary-operator.md)
3030

3131
## 2. 可预测性
@@ -37,7 +37,7 @@ comments: false
3737

3838
- [避免命名重复](./examples/http.md)
3939
- [统一同类函数的返回类型](./examples/use-user.md)
40-
- [解释隐藏的逻辑](./examples/hidden-logic.md)
40+
- [揭示隐藏的逻辑](./examples/hidden-logic.md)
4141

4242
## 3. 内聚性
4343

@@ -74,8 +74,8 @@ comments: false
7474

7575
遗憾的是,这四个标准很难同时兼顾。
7676

77-
例如,通过共同化和抽象化提高代码的内聚性,可确保函数或变数总是一同修改。代码进一步抽象化后,可读性也会随之降低。
77+
例如,通过通用化和抽象化提高代码的内聚性,可确保函数或变数总是一同修改。然而,代码进一步抽象化后,可读性也会随之降低。
7878

79-
允许代码重复可以减少代码的影响范围,从而降低耦合性。然而,这也可能导致在修改一处代码时,另一处未被及时修改,从而影响内聚性
79+
允许代码重复,可以减少代码的影响范围,从而降低耦合性。然而,这也可能导致在修改一处代码时,另一处未被及时修改,从而降低内聚性
8080

8181
前端开发者需要结合当前面临的具体情况,深入思考并在不同价值之间权衡取舍,以确保代码在长期内更易于维护和修改。

0 commit comments

Comments
 (0)