From 795ed0964fa3dd890ff6cbf95a60da633294ee6d Mon Sep 17 00:00:00 2001 From: Aoran Zeng Date: Tue, 19 Aug 2025 09:55:03 +0800 Subject: [PATCH] =?UTF-8?q?=E6=9B=B4=E6=96=B0=E4=BB=A3=E7=A0=81=E9=A3=8E?= =?UTF-8?q?=E6=A0=BC=E6=96=87=E6=A1=A3?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- doc/03-为什么拒绝使用代码格式化工具.md | 54 +++++++++++--------------- 1 file changed, 23 insertions(+), 31 deletions(-) diff --git a/doc/03-为什么拒绝使用代码格式化工具.md b/doc/03-为什么拒绝使用代码格式化工具.md index 7dfad59..56589b5 100644 --- a/doc/03-为什么拒绝使用代码格式化工具.md +++ b/doc/03-为什么拒绝使用代码格式化工具.md @@ -3,17 +3,15 @@ ! ------------------------------------------------------------- ! Doc Type : Markdown ! Doc Name : 03-为什么拒绝使用代码格式化工具.md - ! Doc Authors : Aoran Zeng - ! Contributors : Nul None + ! Doc Authors : 曾奥然 + ! Contributors : Nul None ! Created On : <2025-08-10> - ! Last Modified : <2025-08-17> + ! Last Modified : <2025-08-18> ! ---------------------------------------------------------- --> # chsrc 代码风格 -`chsrc` 项目的第一作者深受 **Ruby** 语言哲学的影响。Ruby 在编程语言界以其 **"程序员幸福感"** 和优雅语法著称。作者同时对 **Perl poem**（Perl 诗歌）这一独特的艺术形式印象深刻。 - -Ruby 的语法优美性在编程行业中具有标杆地位。Matz（松本行弘）提出的 **代码应该为人类而写，偶尔为机器执行** 这一理念，已经成为现代编程语言设计的重要指导原则。 +Ruby 的语法优美性在编程行业中具有标杆地位。Matz（松本行弘）提出的 **代码应该为人类而写，偶尔为机器执行** 这一理念，已经成为现代编程语言设计的重要指导原则。`chsrc` 项目的第一作者深受 **Ruby** 语言哲学的影响。 本项目起源于 AI 编程尚未流行的时代，所有代码全部依赖人类的耐心来维护。现在，我们的代码以及这篇文章不仅会由人类阅读，也会由 AI 阅读。我们始终坚持：**代码的可读性和维护性是项目长期发展的根本保障**。 @@ -25,11 +23,25 @@ Ruby 的语法优美性在编程行业中具有标杆地位。Matz（松本行 代码格式化工具（code formatter）在多人协作的代码仓库中确实有其价值，**参与的人越多，统一格式的需求越迫切**。然而，`chsrc` 项目经过深思熟虑后，拒绝使用代码格式化工具。让我来说明这一决定背后的深层原因。 -像 `Prettier` 这样的工具表面上带来了统一性，但其代价是什么？**它是极度专制的（opiniated）**，这意味着为了获得表面的一致性，我们必须**完全交出代码审美的自主权**。今天我们大部分人使用 `Prettier`，**并非出于真心的认同，而是因为整个前端生态圈的集体胁迫——不用就意味着被边缘化**。每一个有追求的程序员都应该保留**对代码美学的最后决定权，格式化工具的便利性不应该以牺牲美观性和可维护性为代价**。 +### 被强迫使用 + +像 `Prettier` 这样的工具表面上带来了统一性，但其代价是什么？**它是极度专制的（opiniated）**，我们必须**完全交出代码审美的自主权**。今天我们大部分人使用 `Prettier`，**并非出于真心的认同，而是因为整个前端生态圈的集体胁迫——不用就意味着被边缘化**。 这种现象的本质令人深思：**少数 `Prettier` 维护者的个人偏好，竟然决定了全球数百万开发者的代码美学标准。这显然是一种技术独裁，坚决拒绝向格式化工具的霸权低头**。 -C语言的格式化工具通常选择 `clang-format`，它的配置选项十分丰富，比 `Prettier` 要理性得多。然而，即便如此，**其配置的复杂性和局限性仍然无法满足 chsrc 对代码美学的严苛要求**。如果你是一位 `clang-format` 的配置专家，我们诚挚邀请您告诉我们如何优雅地处理以下代码场景，**也许这能改变我的立场**。 +
+ +### 一致性 ≠ 美观 ≠ 可读 + +格式化工具只保证了表面的一致性，就像一些校服，一致不一定代表美。同样，一致不一定代表代码就是最易读易懂的。 + +每一个有追求的程序员都应该保留**对代码美学的最后决定权，格式化工具的便利性不应该以牺牲美观性和可维护性为代价**。 + +
+ +### 满足不了我们的需求 + +C语言的格式化工具通常选择 `clang-format`，它的配置选项十分丰富，比 `Prettier` 要理性得多。然而，即便如此，**其配置的复杂性和局限性仍然无法满足 chsrc 对代码格式的严苛要求**。如果你是一位 `clang-format` 的配置专家，我们诚挚邀请您告诉我们如何优雅地处理以下代码场景，**也许这能改变我的立场**。
@@ -42,8 +54,8 @@ C语言的格式化工具通常选择 `clang-format`，它的配置选项十分 `=` 对齐： ```c -char *name = va_arg(args, char*); -char *email = va_arg(args, char*); +char *name = va_arg (args, char*); +char *email = va_arg (args, char*); ``` 复杂逻辑的 `=` 对齐： @@ -78,30 +90,10 @@ if (!matched) matched = iterate_menu (chsrc_wr_menu, input, &target_tmp); - 类型名: `PascalCase_t` -- 函数定义时，函数名和`()`之间始终保持一个空格 +- 函数定义和调用时，**函数名和`()`之间始终保持一个空格**，如果是在宏中，可紧凑一些，无硬性规定 - 函数和函数定义之间保持**2个空行**，若一系列函数和一系列函数存在主题性区别，**可用3个空行** -- 函数调用时，函数名和`()`之间应当保持一个空格 - - 例外: 当函数参数为0或1时不用保持该空格。 - - 但若该函数参数过长如很长的字符串，又或嵌套了函数，我们仍然保持一个空格。 - -```c -// 一般函数调用都空格，因为这是 GNU 风格最显著的特征之一 -func (1, 2); - -// 当函数参数为0或1时不用保持空格，因为能更紧凑一些 -br(); -red("string"); - -// 但如果有函数嵌套，即使参数只有1个，外部函数还是要保持空格，这样清晰得多 -func1 (func2("string")); -// 如果参数过长，即使参数只有1个，也应该保持空格 -red ("loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong string"); -``` -