命名规范对照:BP_MyDoor → my_door
UE 靠前缀分辨资产类型:BP_、S_、E_、BPI_。Verse 一个前缀都不用,改用大小写分工:类型名 snake_case,成员与函数 PascalCase。这一页给一张完整的改名对照表、一个动手练习,和几条容易踩的细节。
一、为什么 UE 要前缀,而 Verse 不要
UE 的前缀体系是被内容浏览器逼出来的。一个文件夹里躺着蓝图、材质、贴图、结构体、枚举、蓝图接口,文件名是唯一能一眼分辨的线索,于是有了 BP_、M_、T_、S_、E_、BPI_。它解决的是「一堆资产混在一起怎么认」的问题。
Verse 里没有这个问题。类型不是资产,它是写在文件里的一行声明,而那行声明本身已经把话说完了:
# 一眼就知道这是类、结构体、枚举、接口,不需要前缀
my_door := class(creative_device):
Placeholder:int = 0
player_stats := struct:
Score:int = 0
door_state := enum:
Closed
Opening
Open
openable := interface:
Open():void
所以 Verse 把命名的力气花在了另一件事上:用大小写区分「类型」和「值」。这是读代码时更常用的信息 —— 你每天要判断「这个名字是个类型还是个变量」几百次,而「这个名字是不是枚举」一天问不了两回。
二、三条规则就够了
规则一:类型名一律 snake_case —— 全小写,词与词之间用下划线。class、struct、enum、interface,一视同仁:my_door、player_stats、door_state、openable。官方 API 里的 creative_device、button_device、weak_map 也都是这个样子。
规则二:其余一律 PascalCase —— 字段、局部变量、常量、函数、方法,全部首字母大写、词与词直接连写:IsOpen、MaxHealth、OpenDoor()。这一条基本不用改:你在蓝图变量面板里就是这么写的。
规则三:模块路径就是文件夹路径 —— 项目里每个文件夹自动成为一个同名模块,using { /MyProject/Doors } 里的那串路径,对应的就是目录结构。.verse 文件名跟着主类型走,也是 snake_case:my_door.verse。
三条合起来的效果是:看到 my_door 就知道那是一个类型,看到 MyDoor 就知道那是一个值或函数。不看上下文就能读懂一半,这是前缀体系给不了的。
三、改名对照表
把手上的项目照着这张表翻一遍:
| UE / 蓝图里的写法 | Verse 里的写法 | 说明 |
|---|---|---|
BP_MyDoor(Actor 蓝图) |
my_door |
去前缀,转 snake_case |
BP_TreasureChest |
treasure_chest |
同上。多词照样每个词之间加下划线 |
S_PlayerStats(Structure) |
player_stats |
结构体也是类型,规则相同 |
E_DoorState(Enumeration) |
door_state |
枚举同上 |
BPI_Openable(Blueprint Interface) |
openable |
接口同上。惯例是用形容词或能力名,不加 i 前缀 |
BP_HealthComponent(Actor Component) |
health_component |
Scene Graph 的组件类,规则一样 |
变量 IsOpen |
IsOpen |
不用改。成员与局部变量都是 PascalCase |
C++ 变量 bIsOpen |
IsOpen |
去掉布尔的 b 前缀 —— 类型已经写在 :logic 上了 |
函数 OpenDoor |
OpenDoor() |
不用改。函数名也是 PascalCase |
常量 MAX_HEALTH |
MaxHealth |
Verse 没有全大写常量的惯例。常量和别的成员长得一样,因为不可变本来就是默认 |
Event Dispatcher OnDoorOpened |
字段 DoorOpenedEvent + 回调方法 OnDoorOpened() |
官方 API 的惯例是事件字段以 Event 结尾(如 InteractedWithEvent),订阅它的回调用 On 开头 |
资产路径 /Game/Doors |
模块路径 /MyProject/Doors |
文件夹自动成为同名模块 |
文件 BP_MyDoor.uasset |
文件 my_door.verse |
文件名跟主类型走,也是 snake_case |
四、改名练习
下面这台设备是从蓝图资产 BP_TreasureChest 翻过来的,里面有一个蓝图变量叫 IsLocked。两个空,一个要改写法、一个不要 —— 想清楚再填:
using { /Fortnite.com/Devices }
# 蓝图资产 BP_TreasureChest —— 类型名怎么写?
____ := class(creative_device):
# 蓝图变量 IsLocked —— 成员名要不要改写法?
var ____:logic = true
Unlock():void =
set IsLocked = false
再自己做一遍:把 BP_SpikeTrap、E_TeamColor、S_LootEntry、BPI_Damageable 依次翻成 Verse 的类型名。答案分别是 spike_trap、team_color、loot_entry、damageable —— 全部去前缀、全部 snake_case,没有例外。
五、四条容易踩的细节
一、别给类型加后缀补偿。去掉 BP_ 之后,很多人手痒想改成 my_door_class 或 door_enum。别加 —— 声明那一行已经写了 class / enum,再写一遍只是噪音。
二、布尔用 Is / Has / Can 开头。IsOpen、HasKey、CanInteract,读起来就是一句能回答「是 / 否」的问句。C++ 那个 b 前缀在 Verse 里不用。
三、缩写按普通词处理。PlayerId 而不是 PlayerID,HudText 而不是 HUDText。一串连续大写会把 PascalCase 的词边界糊掉,读的人得停下来断句。团队里统一即可,官方风格指南是最终依据。
四、名字里别放中文或空格。标识符只能用字母、数字和下划线。中文可以出现在注释和字符串字面量里,那没问题;但类型名、字段名一律用英文。
最后一句实话:命名规范不是为了讨好编译器 —— 写成 MyDoor := class(...) 也能编译过。它是为了让下一个打开这份代码的人(很可能是三个月后的你)少花十分钟。这一点在蓝图时代就成立,换成文本代码只会更明显。
六、小测验
蓝图资产 BP_TreasureChest 翻译成 Verse 的类型名,应该写成什么?
来源
本文整理自 Epic 官方文档:Verse Code Style Guide(官方文档)↗ · Verse Language Quick Reference(官方文档)↗