kotlin编码风格指南-源文件

最新推荐文章于 2023-11-04 13:21:36 发布

blazecake

最新推荐文章于 2023-11-04 13:21:36 发布

阅读量605

点赞数

分类专栏： kotlin 文章标签： kotlin android 编码

kotlin 专栏收录该内容

4 篇文章

订阅专栏

kotlin编码风格指南

This document serves as the complete definition of Google’s Android coding standards for source code in the Kotlin Programming Language. A Kotlin source file is described as being in Google Android Style if and only if it adheres to the rules herein.
Like other programming style guides, the issues covered span not only aesthetic issues of formatting, but other types of conventions or coding standards as well. However, this document focuses primarily on the hard-and-fast rules that we follow universally, and avoids giving advice that isn’t clearly enforceable (whether by human or tool).

源文件

所有源文件必须使用UTF-8编码

命名

如果源文件只包含一个最外层类，则文件名应使用区分大小写的名称加上.kt扩展名来定义。如果源文件包含多个外层类声明，则选择一个描述文件内容的名字，使用帕斯卡命名法，附加上.kt后缀。

// Foo.kt
class Foo { }

// Bar.kt
class Bar { }
fun Runnable.toBar(): Bar = // …

// Map.kt
fun <T, O> Set<T>.map(func: (T) -> O): List<O> = // …
fun <T, O> List<T>.map(func: (T) -> O): List<O> = // …

特殊字符

空格字符

除了换行符，水平ASCII码间隔字符（0x20）唯一使用空白字符，可以用于源文件的任何地方。这意味着：

在字符串和字符中的空白字符会转义。即作为一个值存在。
制表符不用于缩进。

特殊转义序列

任何字符，使用一种特殊的转义序列如：（\b，\n，\r，\t，\’、\”，\\，$），而不使用Unicode（例如，\ u000a）转义。

非ASCII字符

对于剩余的非ASCII字符，无论是使用实际的Unicode字符（例如，∞）或等效的Unicode转义（如\ u221e）。优先选择使代码更易于阅读和理解的字符。Unicode转义符不推荐用于打印中，除了字符串值和注释使用外，其他地方强烈禁止使用。

例子	说明
val unitAbbrev = “μs”	Best：即使没有注释也非常清楚。
val unitAbbrev = “\u03bcs” // μs	Poor：没必要使用一个可打印字符。
val unitAbbrev = “\u03bcs”	Poor：读者不知道这是什么。
return “\ufeff” + content	Good：使用不可打印的转义字符，必要时可加注释

结构

一份.kt文件由下列组成，顺序如下：

版权许可和/或许可证头部（可选）
文件层次的注释
包语句
import语句
顶级类的声明

只用一行空行隔开以上部分。

版权/许可证

版权或许可头应该放在一个多行注释的顶部。

/*
 * Copyright 2017 Google, Inc.
 *
 * ...
 */

不要使用KDoc-style或单线条样式的注释。

/**
 * Copyright 2017 Google, Inc.
 *
 * ...
 */

// Copyright 2017 Google, Inc.
//
// ...

文件层次的注释

注释放置在标题注释和包声明之间

包声明

包语句不受长度限制, 不用换行。即写成一行。

Import语句

类、函数、属性导入语句以分组形式排成一列，并根据ASCII排序

不允许使用通配符(任何类型)导入

与包语句类似, 导入语句长度不受限制, 也不用换行。即一行写一条导入语句。

top-level的声明

. kt 文件可以在 top-level 上声明一个或多个类型、函数、属性或类别名。

文件的内容应该集中在单个主题上。例如单个公共类型, 或者是在多个接收类型上执行相同操作的一组扩展函数。不相关的声明应该被分离到他们自己的文件中, 并且一个文件中的公共声明应该被最小化。

对文件内容的数量和顺序没有明确的限制。

源文件通常从上往下读, 一般来说这意味着顺序上应该反映出读文件上边的声明将会理文件后面的代码。不同的文件可以选择对其内容进行不同的排序。同样, 一个文件可能包含100个属性, 另一个文件包含10个函数, 或仅仅是单个类。

重要的一点是每个类应当使用一些可以解释的逻辑顺序。例如, 添加新函数时不要习惯性地添加到类的末尾, 因为这将产生 “按日期顺序添加” 的排序, 这不是逻辑排序。

类成员顺序

类中成员的顺序遵循与 “top-level 声明” 相同的规则。

参考地址