# 1. prettier 与 ESLint 的规则冲突（quote vs indent）治理策略；"格式化黑盒"是否可接受 A 让 ESLint 同时管格式与质量 B 用 eslint-config-prettier 关闭 ESLint 的格式规则，格式化交给 prettier，ESLint 只管质量；格式化黑盒可接受 ✓ 正确答案 C 两者都开，冲突时人工裁决 D 不用 prettier，全部手写格式
# 2. 代码块垂直对齐（alignment）的争议中 const a = 1 与 const ab = 2 是否对齐，clang-format 与 black 的默认策略差异及团队如何统一？ A 所有工具都默认对齐 B 垂直对齐与 diff 无关 C 对齐完全由人工控制 D clang-format 提供对齐选项但默认不启用、black 默认不对齐，团队应交给工具强制并固定配置，避免人工对齐与 diff 噪音 ✓ 正确答案
# 3. 单仓库多语言格式化（gofmt + prettier + black + rustfmt）下的工具链冲突中 Node.js 与 Go 的 import 顺序规则不同如何统一 A 用一个工具格式化所有语言 B 强制所有语言 import 顺序一致 C 各语言用各自格式化器（gofmt/prettier/black/rustfmt），import 顺序按语言惯例，统一的是流程与 CI 检查而非规则 ✓ 正确答案 D 不格式化，人工统一
# 4. 导入顺序的约束（stdlib / 3rd / internal）如何在 golangci-lint 与 ruff（Python）中配置以防止回退 A import 顺序无关紧要 B Go 用 gci/gofumpt 定义 stdlib/3rd/internal 分组，Python 用 ruff 的 isort 规则，通过 CI 门禁与 pre-commit 防止回退 ✓ 正确答案 C 只需人工排序一次 D 一个工具管所有语言的 import
# 5. 格式化与 git blame 中全仓格式化提交会破坏代码归属追溯，如何用 .git-blame-ignore-revs 标记并保持历史可读？ A 用 .git-blame-ignore-revs 列出格式化提交，git blame 跳过它们追溯真实作者；格式化提交与逻辑提交分离 ✓ 正确答案 B 格式化提交破坏 blame 无法解决 C 禁止全仓格式化 D blame 只显示格式化提交即可
# 6. 行宽限制（80/100/120）的认知证据中研究显示超过 100 列后阅读速度显著下降，但 IDE 横向滚动的容忍度变化 A 行宽越长越好，灵活表达 B 超长行（>100 列）降低阅读速度，IDE 横向滚动缓解个人阅读但仓库仍应统一行宽（80-120），工具强制 ✓ 正确答案 C 行宽必须 80 D 行宽与可读性无关
# 7. EditorConfig 跨 IDE 统一缩进/字符集，与 .gitattributes 治理换行符（CRLF/LF，text=auto）防止跨平台 diff 噪声 A EditorConfig 管跨平台 diff，.gitattributes 管缩进 B 换行符无需治理 C EditorConfig 统一缩进/字符集，.gitattributes 用 text=auto 规范化换行符（存 LF、检出转平台格式）并标记 binary，消除跨平台 diff 噪声 ✓ 正确答案 D 二进制文件也要 text=auto
# 8. pre-commit 钩子框架（pre-commit framework、husky + lint-staged）的格式化卡点中仅对暂存文件增量格式化 A 每次提交格式化全仓 B husky + lint-staged / pre-commit framework 只对暂存文件增量格式化，重新暂存后提交，保证合规且高效 ✓ 正确答案 C 钩子只检查不格式化 D 格式化应在提交后单独做
# 9. lambda 表达式与闭包的格式化（一行内 vs 多行）的可读性 A 所有 lambda 都必须一行 B 所有 lambda 都必须多行 C 短而简单的 lambda 一行，长而复杂的 lambda 多行，交给格式化工具按行宽决定 ✓ 正确答案 D lambda 格式与可读性无关
# 10. 函数参数列表的换行（多参数 vs 多行）的格式约定 A 所有参数都同行 B 参数少且未超行宽时同行，参数多或超行宽时每行一个参数，缩进由格式化工具统一 ✓ 正确答案 C 所有参数都多行 D 换行随意，无法统一
# 11. 运算符换行（运算符前置 vs 后置）的可读性差异；不同语言规范（Google Style、LLVM） A 所有语言都强制运算符后置 B 运算符换行无差异 C 前置运算符对齐便于阅读（Google/Python 偏好），后置符合行尾续行直觉（LLVM 偏好），团队统一并工具强制 ✓ 正确答案 D 必须前置
# 12. 格式化工具的价值中 Prettier/Black/gofmt 统一风格消除争论？ A 工具输出确定、全队统一配置、自动执行，消除风格争论，让评审聚焦逻辑 ✓ 正确答案 B 格式化工具仍靠人工争论风格 C 格式化工具使 diff 更乱 D 风格应每个开发者自由决定
# 13. 长字符串、长 SQL 与正则等"不可安全换行"内容的格式化策略中关闭自动换行 vs 拆分拼接的取舍？ A 所有长内容都强制换行 B 正则可以随意拆分 C 所有长内容都用 ignore 保持原样 D 换行会破坏语义的（正则、字面量）用 ignore 关闭换行；可安全拼接的（SQL、模板）拆分拼接，语义正确优先 ✓ 正确答案
# 14. 格式化配置的变更治理中修改 prettier/格式化规则的评审流程，以及全仓再格式化的风险如何控制？ A 任何开发者可随意改格式化配置 B 配置变更走评审、全仓格式化单独提交并登记 blame ignore、分模块试点灰度，控制大规模 diff 与冲突风险 ✓ 正确答案 C 全仓格式化混入逻辑提交 D 格式化配置变更无需管控
# 15. 链式调用（fluent API）的换行策略中每行一个方法 vs 同行多个；.then(...).then(...) 的 lint 规则 A 所有链式调用都同行 B 短链同行，长链（.then().then()）每行一个方法，用 newline-per-chained-call lint 强制 ✓ 正确答案 C 所有链式调用都每行一个 D 链式调用换行无影响
# 16. .gitattributes 中二进制文件（binary）标记与合并策略（merge=union）的配置 A binary 文件应做换行符规范化 B binary 文件无法用 LFS 管理 C merge=union 适用于所有文件 D binary 标记排除换行规范化与 text diff，merge=union 用于追加型文件（lock/changelog）取并集，但 union 有重复行风险 ✓ 正确答案
# 17. 行宽、缩进与空行的约定中为什么一致性比偏好更重要？ A 一致性让代码可预测、diff 干净、评审聚焦逻辑，整体可读性与协作效率高于个人偏好 ✓ 正确答案 B 个人偏好永远优先 C 风格是否一致无所谓 D 一致性只影响美观
# 18. 格式化与 git diff 中如何减少格式化噪音？ A 格式化与逻辑变更混在一个提交 B 格式化噪音不可避免 C 提交前自动格式化入库即合规、格式化与逻辑分离提交、审 diff 用 -w 忽略空白、blame 跳过格式化提交 ✓ 正确答案 D 只格式化一部分文件
# 19. 自动格式化的 CI 门禁中 format check 与 pre-commit？ A 只做 CI 检查，不做本地格式化 B 只做本地格式化，不做 CI C pre-commit 本地自动格式化，CI format check 兜底防绕过，二者配置一致保证入库即合规 ✓ 正确答案 D 本地与 CI 规则可不同
# 20. 格式化器与代码生成器的冲突中手写代码与生成代码（protobuf、OpenAPI client）混用时如何分区管理格式化规则？ A 生成代码也要跑格式化器 B 生成器输出可被手改 C 生成代码与手写代码混用格式化 D 用 ignore 分区排除生成目录，格式化器只负责手写代码，生成代码由生成器负责，用重新生成 diff 一致性检查 ✓ 正确答案
