# 1. 函数长度控制中单一职责原则（SRP）与函数行数（一般 20-50 行）的协同；过长函数的识别与拆分策略 A 只按行数机械拆解 B 行数超过 50 就一定拆 C 函数越长越好，减少调用 D SRP 是原则，行数（20-50）是量化线索，过长函数用 Extract Function 把语义单元拆出，主函数成为可读步骤清单 ✓ 正确答案
# 2. 嵌套层级控制中最大深度（一般 3-4 层）的项目门禁与 early return（卫语句）降低嵌套的实践 A 嵌套越深越安全 B 卫语句会降低可读性 C 嵌套无法控制 D 用卫语句提前返回压平正常路径，lint 的 max-depth 强制最大深度（3-4 层）作为项目门禁 ✓ 正确答案
# 3. 命名规范与可读性中避免缩写、使用意图揭示型命名、领域术语一致性 A 缩写能让代码更简洁 B 避免缩写、用意图揭示型命名、保证领域术语一致，靠规范 + 术语表 + lint 强制 ✓ 正确答案 C 命名随意即可 D 缩写是良好实践
# 4. 代码评审中如何用「可读性检查清单」统一团队标准，命名、函数长度、嵌套、副作用、魔法数五项门禁如何落地为 reviewer 可勾选的 checklist，并沉淀为规范文档？ A 可读性无法评估，靠感觉 B 只靠 lint 自动检查可读性 C 把命名/函数长度/嵌套/副作用/魔法数做成可勾选 checklist，可机检的交给 lint，清单沉淀为规范文档 ✓ 正确答案 D checklist 一次用完即弃
# 5. clever code 反模式中过于巧妙的一行式技巧如何损害可读性，评审中如何区分"优雅"与"晦涩"？ A 优雅是简单可读、意图自明；晦涩是技巧压缩、读者需长时间解码。评审中以"能否快速理解意图"区分，晦涩则重构 ✓ 正确答案 B 代码越短越优雅 C 一行式技巧应鼓励 D 晦涩代码无需解释
# 6. 注释规范中解释"为什么"而非"做什么"；行内注释与文档注释的边界 A 注释解释"为什么"，行内注释讲局部 why、文档注释讲公共契约，边界清晰 ✓ 正确答案 B 注释解释"做什么"，行内与文档无区别 C 文档注释可以写实现细节 D 行内注释应写完整契约
# 7. 代码结构一致性中文件内方法排列顺序（公共→私有、高层→底层）、类内字段排列规范 A 方法/字段随意排列 B 私有方法应在前 C 字段排列无规范 D 方法公共→私有、高层→底层，字段常量→静态→实例并按职责分组，用规范 + lint 强制 ✓ 正确答案
# 8. 魔法数字与魔法字符串的处理中常量提取、枚举替代、配置外移的边界与优先级？ A 固定值用常量，有限取值用枚举，运行可变/环境相关用配置外移，按值的变化性选择优先级 ✓ 正确答案 B 所有数值都保持原样 C 所有数字都配置化 D 魔法字符串无需处理
# 9. 代码可读性的量化评估中可读性指数、认知负荷度量、团队可读性评审 A 可读性完全无法量化 B 指标即结论，无需评审 C 认知复杂度、圈复杂度、函数长度等指标标记可疑点，指标作线索，最终由团队评审确认 ✓ 正确答案 D 只靠人工感觉
# 10. 副作用透明中函数命名与文档应明确副作用（Command-Query Separation） A 查询方法可以随意写状态 B 命令与查询分离，查询纯读、命令明确改状态，命名与文档让副作用可预期，lint 检查查询方法是否违规 ✓ 正确答案 C 副作用不必透明 D 一个方法可既查询又写，方便
# 11. 错误处理的统一策略中异常 vs 错误码、统一错误处理层的架构选择 A 各层各自处理错误 B 全部用错误码 C 全部用异常 D 明确异常（类型化错误）与错误码（可预期错误）分工，用框架层统一错误处理（状态码/错误体/日志）形成一致契约 ✓ 正确答案
# 12. 长参数列表（long parameter list）与「临时变量堆积」两类可读性杀手中引入参数对象（Parameter Object）与提炼函数（Extract Function）的改造时机如何判断？ A 参数越多越好，临时变量越少越好 B 只按数量机械拆解 C 参数多且语义相关用 Parameter Object，临时变量多且属子步骤用 Extract Function，按语义内聚判断 ✓ 正确答案 D 无需改造，忍者阅读
# 13. 可读性 vs 性能的权衡中何时牺牲可读性换取性能、注释与基准数据如何补偿，避免凭感觉做微优化？ A 性能永远优先 B 默认可读性优先，仅对已证实的热路径且收益显著时才优化，用注释解释 + benchmark 证明，避免凭感觉微优化 ✓ 正确答案 C 凭感觉优化最有效 D 可读性与性能无关
# 14. 代码的局部性（locality）中变量声明靠近使用处、副作用局部化、控制流局部化为何是函数可读性的核心？ A 变量越早声明越好 B 副作用分散更能体现灵活 C 变量声明靠近使用、副作用与控制流局部化，减少认知跨度，让读者线性阅读即可理解 ✓ 正确答案 D 局部性无关紧要
# 15. 可读性评审意见的闭环中可读性类评论如何分类统计并反哺命名规范与格式化配置？ A 评审意见用过即弃 B 分类统计可读性评论，高频反哺规范条目与 lint/格式化配置，让问题从人工提醒变为工具默认合规 ✓ 正确答案 C 只统计不改进 D 评审评论无法分类
# 16. 复合布尔条件的拆分中用命名谓词或布尔变量替代长条件表达式的判据，何时提取、何时保留？ A 所有条件都提取为谓词 B 条件复杂、有业务语义或可复用则提取为命名谓词/变量，简单局部条件保留内联，避免过度抽象 ✓ 正确答案 C 所有条件都内联 D 布尔条件无法拆分
# 17. 中间变量 vs 管道式链式调用中二者在可读性与调试体验上的取舍，团队评审标准如何定？ A 一定用链式调用 B 一定用中间变量 C 简单链式简洁可读，复杂或需中间调试用中间变量，评审标准是链式是否保持可读、是否需要中途观察 ✓ 正确答案 D 两者不可混用
# 18. 可读性与「团队熟悉度」的张力中为性能或框架约束而牺牲直觉命名时，如何通过文档、示例与代码注释补偿可读性？ A 框架约束命名无需补偿 B 团队熟悉度可完全替代可读性 C 因框架/性能牺牲直觉命名时，用文档、示例、注释补偿，让读者不靠猜；能改回直觉命名时改回 ✓ 正确答案 D 补偿没有意义
# 19. 可读性正反例库中团队如何维护正反例代码示例作为可读性规范的活教材，并随评审持续更新？ A 规范只写文字，不配示例 B 反例库建一次不再更新 C 每个规范条目配反例+正例，作为活教材，随评审发现新反模式持续更新，并用 lint 校验示例可编译 ✓ 正确答案 D 示例无需可编译
