这篇博文最初由坎•乌泽尔 (Can Uzer) 发表在自己的个人网站上。（https://canuzer.com/naming-convention-best-practices/）
在游戏开发过程中，怎样的命名规范好？我们又为何要在意？简单来说，命名规范是一套用来定义如何对特定类型的素材（如音频片段、动画和游戏界面）进行命名的规则。作为管理大量音频素材的游戏音频设计师，我发现明确并且一致的命名规范非常重要。因为这样会比较有条理，而且可以提高工作效率。只要切实重视起来，就能显著改进工作流程、减少错误并简化团队之间的沟通。在本文中，我就来分享一些帮助大家更加高效地为素材命名的实用技巧。
我们先来说说恰当的命名规范都有哪些明显的好处：
提高浏览和搜索效率：快速找到所需文件。
合理组织：以通俗、实用的方式组织文件。
简化批处理：轻松完成批量重命名等针对文件的批处理操作。
自动执行任务：通过脚本自动执行涉及字符串处理的任务。
增强代码的可读性：在引用素材名称时让代码更加简明易懂。
统一命名素材：音频、美术和动画等部门采用一致的命名可使团队协调一致。
有序归档：确保文件结构整洁有序。
追求完美：一切井然有序，让人心情愉快！
那么，如何界定怎样才算恰当、高效的命名规范呢？下面列出了一些核心原则、理念以及应用实例。各位在构建文件命名系统的时候不妨参考一下。
恰当的命名规范都有哪些基本特质
简明扼要：包含足够的细节，又不会太过繁琐（如 ui_button_select）。
层层嵌套：按照从概括到具体的原则逐层嵌套（如 environment_forest_bird）。
合理排序：方便按照字母顺序合理且高效地对名称进行排序。
格式一致：始终采用一致的大小写格式（如 camelCase、PascalCase 或 snake_case）。
统一编号：基于预期文件数量应用一致的数位编号（如 01、02 或 001、002）。为了保证能够恰当地排序，请避免使用单一数位编号（如 pig_minion_1）。
语法一致：始终采用一致的动词形式、名词或后缀（如 cha_sonic_spin vs. cha_sonic_spinning 或 bomb_activation vs. bomb_activate）。
词形一致：对两可的单词采用同一标准拼法（如 ambiance/ambience 或 flyer/flier）。
时态/单复数一致：保持时态和单复数一致（如 chest_destroyed vs. chest_destroy 或 coins_collect vs. coin_collect）。
命名规范示例
最好使用结构式来记录命名格式以确保对素材进行一致的命名。比如：
type_category_?subcategory_?action_?subcategory_?01
（注意：? 代表可选类别）。
下面列举了一些采用此格式的示例：
ui_button_select
ui_button_shop_purchase
gp_proj_fire_hit_small_01
gp_proj_fire_hit_small_02
gp_booster_bomb_activate
mus_core_jungle_01
这些例子展示了其中的一些窍门：
按照从概括到具体的原则逐层嵌套类别。
谨慎地使用缩写，以保证简明易懂。
action 类别始终为动词，并且没有多余的后缀。
编号一致，有助排序。
下面我以 Unity 工程的视角列举了两种不同的文件命名方式。各位不妨看看哪种更加合理、更有条理（或者说合乎情理）。😃
其他实用窍门
避免名称过长：如果名称过长，工具界面看着会很乱。所以，尽量只保留关键细节。
适当使用描述词：决定是否标明某些特质。比如，在音乐轨名称结尾添加 loop 以表明其为循环（如 music_theme_loop）。不过，省去 loop 可以让名称更简短。具体可根据制作需要来选择。
机制与主题：选择是以游戏机制还是主题来命名（抑或两者并用）。比如，脚本可命名为 ExplodingProjectile（机制），主题则可直接命名为 Fireball（主题）。声音设计师和艺术家经常会从主题的角度来构建游戏机制。不过，在对实体命名和分类时，最好把机制也考虑进去。这样看上去更容易分辨，还可以了解到相关信息。
谨慎使用缩写：名称可以更简短，但要确保能看懂。而且，必须始终采用标准、一致的缩写。示例如下：
gp：gameplay
plr：player
cha/char：character
amb：ambience
mus：music
有关大小写格式的细节
snake_case：我发现 snake_case – 用下划线分隔小写单词 – 特别有用（如 cha_red_attack_vo）。因为下划线可分隔特定字词，从而简化搜索（比如，输入 cha_ 可筛选出包含 cha_ 的条目，但可避开 characters）。
大小写混用：可将关键词大写来突显某部分信息（如 amb_factory_main_STOP）。在类别包含多个单词时，也可使用 camelCase。比如，enemy_fireDemon_death（其中 Fire Demon 为单独的实体）。
其他样式：团队也可根据喜好使用 PascalCase、camelCase 和 kebab-case（作为土耳其人，我们更倾向于称之为 kebap）。
应当避免的情形
非描述性名称：clip_01（没有上下文，不明所以）。
分隔符不一致：awesome_sound1（数字前怎么没加下划线呢？）
自然语言结构：PickupGreenEmerald（不好排序或筛选；应改用 ItemGemEmeraldGreen）。
层级不一致：boss_enemy_eggman（enemy 比 boss 更宽泛；应改用 enemy_boss_eggman）。
数位不一致：GreatArt_1、GreatArt_2、GreatArt_10（应改用 GreatArt_01、GreatArt_02…）
缩写看不懂：mus_stng_lvl_comp（这…谁看得懂啊？）
名称过长：sfx_env_forest_daytime_birds_chirping_loop_ambient_lowIntensity_01.wav（太长，眼都要看花了）。
标识版本：在名称中包含版本号或其他标识。比如，music_battle_theme_epic_v3_finalMix_02（有点乱，而且确定是最终版本吗？）
团队用词不统一：音频文件被命名为 mechanic_woodbox，而艺术家称之为 mechanic_crate。这样很容易给人带来困扰。请确保各个团队统一用词。
插入空格：最好不要在单词之间插入空格。这可能会给某些工具或实用程序带来问题。所以，一般不建议那么做。
结语
命名规范没有统一的规则，每个项目都有独特的需求。不过，不妨听取各个部门的意见，尽早建立一套周全的系统。这样可以简化制作流程并提高工作效率。最好将命名规范记录在案，这样所有人都能统一口径。
希望这里分享的技巧和窍门能帮助大家更加高效地为素材命名并优化工作流程。各位不妨试试！
关于作者
约翰•乌瑟 (Can Uzer)
约翰•乌瑟 (Can Uzer) 是一名土耳其/芬兰籍游戏音频设计师，他广泛涉猎 PC、主机和手机游戏、VR 等多个领域并拥有丰富的经验。他曾毕业于 SAE 和阿尔托大学，在拿到新媒体声音专业硕士学位后，他曾作为自由职业者常年与多家游戏公司合作。目前，他在芬兰为 Rovio/SEGA 担任首席声音设计师。在工作之余，约翰喜欢锻炼、玩游戏 (尤其是复古游戏)…
个人网站：canuzer.com
成为 Audiokinetic 博客撰稿人，跟全球互动音频社区用户分享您的项目经验和创意想法，请电邮至：info@audiokinetic.cn （投稿攻略：https://blog.audiokinetic.com/zh/guidelines）
原文链接：https://www.audiokinetic.com/zh/blog/naming-convention-best-practices/
