Skip to content
🎉 Welcome to the new Aptos Docs! Click here to submit an issue.

Move 编码规范

本节列出了 Move 团队总结的一些基础编码规范。这些仅是建议,如果您有偏好的其他格式指南和规范,可以自由采用。

命名规范

  • 模块名称:应采用小写蛇形命名法,例如 fixed_point32vector

  • 类型名称:若非原生类型,应采用驼峰命名法,例如 CoinRoleId

  • 函数名称:应采用小写蛇形命名法,例如 destroy_empty

  • 常量名称

    • 表示错误码时应采用大驼峰命名法并以 E 开头(如 EIndexOutOfBounds
    • 表示非错误值时采用大写下划线命名法(如 MIN_STAKE
  • 泛型类型名称:应具有描述性(或在适当情况下反描述),例如向量泛型参数使用 TElement。通常模块中的”主要”类型应与模块同名,如 option::Optionfixed_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 团队计划编写一个自动格式化工具来强制执行格式规范。但在目前过渡期间:- 除scriptaddress块的内容不应缩进外,其他情况应使用四个空格缩进。

  • 当行长度超过100个字符时,应进行换行处理。
  • 结构体和常量必须在模块的所有函数之前声明。