Move 编码规范
本节列出了 Move 团队总结的一些基础编码规范。这些仅是建议,如果您有偏好的其他格式指南和规范,可以自由采用。
命名规范
-
模块名称:应采用小写蛇形命名法,例如
fixed_point32
、vector
-
类型名称:若非原生类型,应采用驼峰命名法,例如
Coin
、RoleId
-
函数名称:应采用小写蛇形命名法,例如
destroy_empty
-
常量名称:
- 表示错误码时应采用大驼峰命名法并以
E
开头(如EIndexOutOfBounds
) - 表示非错误值时采用大写下划线命名法(如
MIN_STAKE
)
- 表示错误码时应采用大驼峰命名法并以
-
泛型类型名称:应具有描述性(或在适当情况下反描述),例如向量泛型参数使用
T
或Element
。通常模块中的”主要”类型应与模块同名,如option::Option
、fixed_point32::FixedPoint32
-
模块文件名:应与模块名称一致,如
option.move
-
脚本文件名:应采用小写蛇形命名法,且应与脚本中”主”函数名称匹配
-
混合文件名:若文件包含多个模块和/或脚本,文件名应采用小写蛇形命名法,且不与内部任何特定模块/脚本名称匹配
导入规范
- 所有模块
use
语句应位于模块顶部 - 函数应从声明它们的模块中完全限定导入和使用,不应在顶层导入
- 类型应在顶层导入。当出现名称冲突时,应使用
as
在本地重命名
例如有如下模块:
module 0x1::foo {
struct Foo { }
const CONST_FOO: u64 = 0;
public fun do_foo(): Foo { Foo{} }
// ...
}
应按以下方式导入和使用:
module 0x1::bar {
use 0x1::foo::{Self, Foo};
public fun do_bar(x: u64): Foo {
if (x == 10) {
foo::do_foo()
} else {
abort 0
}
}
// ...
}
当导入两个模块出现本地名称冲突时:
module 0x1::other_foo {
struct Foo {}
// ...
}
module 0x1::importer {
use 0x1::other_foo::Foo as OtherFoo;
use 0x1::foo::Foo;
// ...
}
注释规范
- 每个模块、结构体和公共函数声明都应添加注释
- Move 支持文档注释
///
、常规单行注释//
、块注释/* */
和文档块注释/** */
注释示例
文档注释必须紧贴在被注释项上方。例如以下是有效写法:
/// 我的超赞模块,文档注释可以写在这里
module 0x42::example { // 双斜线注释可以出现在任意位置
// 双斜线注释可以出现在任意位置
/// 我的超赞常量
const MY_VALUE: u64 = 5;
/// 我的超赞错误信息
const E_MY_ERROR: u64 = 10;
#[view]
/// 我的超赞视图函数
fun show_me_the_money() {
// ...
}
/* 同样地,块注释可以出现在任意位置 */
}
```以下是会导致失败的文档注释 `///` 示例
```move
module 0x42::example {
/// My awesome view function <- 必须位于注解下方,紧贴被注释内容
#[view]
fun show_me_the_money() {
// ...
/// 函数内部(错误位置)
}
/// 未关联到任何内容(错误位置)
}
代码格式
Move 团队计划编写一个自动格式化工具来强制执行格式规范。但在目前过渡期间:- 除script
和address
块的内容不应缩进外,其他情况应使用四个空格缩进。
- 当行长度超过100个字符时,应进行换行处理。
- 结构体和常量必须在模块的所有函数之前声明。