Kotlin 团队协作：引发所有争论的代码风格与约定

Kotlin 团队协作：如何停止争论格式化并开始编写代码

您是否曾进行过代码审查，其中一半的评论都是“加个空格”、“去掉空格”或“为什么你用驼峰命名法而不是蛇形命名法”？如果是这样——欢迎加入我们。在任何团队中，迟早都会面临一个问题：Kotlin 代码风格与约定。如果不提前达成一致，每个人都会坚持自己“完美”的括号放置方式。

本文并非枯燥的规则清单。这是一份实用指南，教您如何让 Kotlin 代码对团队来说更具可读性、统一性和便利性。我们将分析关键约定、自动化工具以及能为您节省数小时会议争论时间的技巧。

为什么 Kotlin 代码风格关乎金钱而非美学

老实说：业务方并不关心您将花括号放在同一行还是新的一行。但业务方关心的是让新开发人员融入项目需要多长时间。研究表明，开发人员花费高达 40% 的时间阅读代码。如果代码采用统一的 Kotlin 代码风格，这一过程将大大加快。

当项目中使用统一的 Kotlin 代码风格时：

\n
• 新团队成员能更快理解项目结构。
\n
• 代码审查进行得更快——审查者寻找逻辑错误，而不是空格问题。
\n
• 因错误格式化导致的 bug 数量减少（是的，这种情况确实存在）。
\n
• Git 差异更清晰——重新格式化带来的噪音更少。
\n

因此，Kotlin 约定并非主管的任性要求，而是提高效率的工具。现在，我们将分析如何无痛地实施它们。

官方指南：Kotlin 编码约定

我们从基础开始：JetBrains 有一份官方文档——Kotlin 编码约定。这并非法律，但明智的人建议将其作为起点。让我们快速浏览一下最常引发争论的关键点。

命名：永远使用驼峰命名法

Kotlin 对所有内容都使用驼峰命名法：类名首字母大写（MyAwesomeClass），函数和变量名首字母小写（myAwesomeFunction）。顶层常量或对象内部的常量使用全大写蛇形命名法（SCREAMING_SNAKE_CASE）。变量名中不要使用下划线——这不是 Python。

// 正确\nclass UserProfile\nval userName: String\nfun getUserData(): UserData\n\n// 错误\nclass user_profile\nval user_name: String\nfun get_user_data(): UserData

花括号：在同一行打开

Kotlin 遵循 Java 传统：左花括号与声明在同一行。除非您想被视为异端，否则这一点没有商量余地。

// Kotlin 方式\nfun processData(data: List<String>) {\n    data.forEach { item ->\n        println(item)\n    }\n}\n\n// 非 Kotlin 方式（但如果整个团队都这样写——也可以）\nfun processData(data: List<String>)\n{\n    data.forEach { item ->\n        println(item)\n    }\n}

空格：不要吝啬

在关键字（if、for、when）之后、二元运算符周围以及逗号之后添加空格。这能提高可读性。

// 可读性强\nif (x > 0 && y < 10) {\n    println("Hello, World!")\n}\n\n// 阅读困难\nif(x>0&&y<10){\n    println("Hello, World!")\n}

自动格式化：您最好的朋友

手动检查代码风格已是过去式。Kotlin 在 IntelliJ IDEA 中有内置格式化工具：Ctrl+Alt+L（Mac 上为 Cmd+Option+L）。但如果您的团队中有人使用 VS Code 或其他编辑器——问题将不可避免。

解决方案：ktlint 和 Spotless。

ktlint：全能工具

ktlint 是一个检查和自动