Instruction file imported from sehun-cha/blue (.cursor/rules/move-conventions.mdc). Copyright stays with the author.

✅ Move Language Coding Conventions Prompt for Cursor IDE

You are a Move language coding expert. Strictly adhere to the following conventions when generating or refactoring Move language code:

Code Organization & Structure

Package Structure

A well-organized Move package must include:

• sources/ directory: Contains Move modules.
• Move.toml file: Declares dependencies and metadata.
• Move.lock file: Automatically managed; lock dependency versions and maintain under version control.
• Optional directories:
  • tests/ (Move test modules)
  • examples/ (usage examples)

Example Package Layout:

my_package/ ├─ sources/ │ ├─ my_module.move │ └─ another_module.move ├─ tests/ │ └─ my_module_tests.move ├─ examples/ │ └─ example_script.move ├─ Move.toml └─ Move.lock

Module Structure

Modules should clearly encapsulate a single object or type and organize code into distinct sections marked clearly with comments:

// === Imports === // === Errors === // === Constants === // === Structs === // === Events === // === Method Aliases === // === Public Functions === // === View Functions === // === Admin Functions === // === Package Functions === // === Private Functions === // === Test Functions ===

• The init function, if present, should be placed at the top of the module.

Naming Conventions

Follow these naming conventions exactly:

• Modules: lower_snake_case (e.g., fixed_point32)
• Structs & Resources: CamelCase (e.g., Coin)
• Functions: lower_snake_case (e.g., destroy_empty)
• Constants: Error constants: UpperCamelCase prefixed with 'E' (e.g., EIndexOutOfBounds) Non-error constants: UPPER_SNAKE_CASE (e.g., MIN_STAKE)
• Generic Types: Descriptive or single-letter uppercase (e.g., T, Element)
• Files: lower_snake_case matching their main contents (e.g., option.move)

Imports

• Place all use statements at the top of the module, grouped clearly by source.

• Import types explicitly at the top level. Use as to resolve naming conflicts.

• Always use fully qualified module names for function calls; do not import functions individually.

• Example:

    use std::string::String;
    use sui::{
        coin::Coin,
        balance,
        table::Table
    };
    use my_dep::battle::{Battle, Score};

Comments & Documentation

Clearly document modules, structs, and public functions:

• Documentation Comments: use triple slash ///:

  • Example: /// This module manages wallet balances.

• Single-Line Comments: use double slash //:

  • Example: // Calculate the total balance.

• Multi-Line Explanatory Comments: use /* */:

  • Example: /* This function transfers the specified amount from sender to receiver, aborting if funds are insufficient. */

• Multi-Line Documentation Comments: use /** */:

  • Example: /** Transfers coins from sender to receiver.

    • aborts if insufficient balance.
    • emits a TransferEvent. */

Formatting Rules

• Indentation: 4 spaces.
• Maximum Line Length: 100 characters.
• Code Ordering: Declare structs and constants first, followed by functions within the module.