Unity 项目规范

编码(Coding)

使用 .NET standards为基础，并在下方进行了更改

命名(Wording)

• 使用描述性的且准确的名称(即使这使得名称更长)，注重可读性而不是简洁性
• 不要乱用首字母缩略词，仅使用公认标准的首字母缩写

  例如：UI、IO

• 方法名(Method)应该是动词或动词短语
• 属性名(Property)应该是名词、名词短语或形容词
• 布尔属性(Boolean)应该是肯定短语。可以在布尔属性前加上"Is"，“Has”，can"

  例如：IsActive、CanJump

• 如果多个属性与同一项相关，使用项名称作为前缀并添加属性类型或角色

  private Color _gameTitleColor
  private String _gameTitleString
  private TextMeshProUGUI _gameTitleText
  

• 如果名称不在固定列表中，避免使用数字作为名称

  例如：animator1、animator2
  而是说明两个属性之间的区别
  例如：playerAnimator、enemyAnimator

拼写(Capitalization)

• 骆驼拼写法(camelCase)：第一个词的首字母小写，后面每个词的首字母大写
• 帕斯卡拼写法(PascalCase)：每个单词的首字母都是大写的。如果单词是由两个字母组成的首字母缩略词，则两个字母都要大写。如果单词是包含两个以上字母的首字母缩略词，则只有第一个字母大写

  • 类、方法、枚举、名称空间、公共字段/属性使用PascalCase

    例如：ClassName、GetValue

  • 局部变量、方法参数使用camelCase

    例如：previousValue mainUI

  • 私有字段/属性使用camelCase，但以下划线开头

    例如：_inputReader

  • 常量全大写，用下划线分隔单词

    例如：GRAVITY_AMOUNT

编程(Programming)

• 保持字段和方法为private，除非需要它们public
• 如果想在Inspector中显示字段，而不想让其他类访问这个变量，不要用public，使用private和特性[SerializeField]

  注意：这样可能会得到警告"Field is never assigned to， will always have its default value"，使用=default为字段指定默认值

• 尽量避免使用单例(Singletons)。尝试使用ScriptableObjects(1，2)来建立一个类似的、集中的、可以从多个对象中访问的类
• 声明变量时不要使用var，始终显式地编写它的类型
• 避免使用静态变量，如果你绝对需要他们，请确保它们与Fast Enter Play Mode兼容
• 不要在你的代码中使用硬编码的"魔法数字"

  例如：角色移动xInput*0.035f，为什么用这个数字?请将这个数字存储在一个有明确名称的字段中——也许再加个注释说明为什么选择这个特殊数字

• 提交代码之前，删除所有没使用过的using命令

  例如：using System

格式(Formatting)

• 使用空格来缩进代码，不要用Tab
• 花括号：如果内容为空，写在同一行。如果非空，每个占一行

  public class EmptyBraces(){}
  public class NonEmptyBraces
  {
      // ...
  }
  

• 相互包含的逻辑单元需要缩进以表示层次关系

  public void FunctionName()
  {
      if(somethingHappended)
      {
          // ...
      }
  }
  

注释(Comments)

• 重要：不要为了注释而注释。如果你认为任何人只要看一眼就能理解代码的作用，就不要添加注释，给变量、类、方法良好的名字，让他们解释自己!
• 使用行内注释为单独的代码行进行补充说明
• 在每一个类上都要写摘要，以描述类的目的。如果一个类可读性不高或者功能细节不直观时，可以选择性的在摘要中加入这些细节

  /// <summary>
  /// This class manages save data
  /// </summary>
  提示：在IDE中输入三个"/"符号，一般会自动生成摘要。看微软官方规范
  

• 在方法前写注释，解释它的功能，以防方法名不准确，或者添加其他重要的细节，可以用行内注释

  /// <summary> This function does this... </summary>
  public float CalculateBoundingBox(){ }
  

• 使用以//TODO：开头的注释来表示需要稍后完成的事情，这样你就不会忘记了

  注意：这不是在鼓励你推送未完成的功能

• 不要写#region或者//--------这类注释

场景/层次结构(Scene/Hierarchy)

组织结构(Organisation)

• 在根(root)上创建空的GameObject并命名，创建视觉上的分隔符

  例如："— Camera —"，"— Environment —"，"— Lighting —"等
  给这些分隔符添加"EditorOnly"标签，这样打包的时候就不会加入

• 可以使用空的GameObject作为容器，但不要只包含1-2个物体
• UI

  • 尽可能使用同一个Canvas，只有在Canvas属性改变的时候才创建多个Canvas

  • 每一个屏幕创建一个面板(Panel)

    例如：一个设置标签和它的选项

  • 用面板(Panel)作为容器，将UI元素进行分组

    例如：一个设置标签和它的选项
    面板能帮忙固定需要固定在一起的元素
    例如：一些能量/物品UI在屏幕右下角

命名(Naming)

• 在GameObject命名中不要用空格
• 用PascalCase命名

  例如：MainCharacter，DoorTrigger

• 如果仅用PascalCase命名会产生歧义，用下划线连接两个概念

  例如：MainHall_ExitTrigger，BossMinion_AttackWaypoints

• 预制体(Prefabs)：如果合理，可以重新命名实例

  例如：一个Prefab Variant文件名称为"Protagonist_Scene1Variant"，如果你只用它一次，可以直接重命名为"Protagonist"

项目文件(Project files)

命名(Naming)

• 与 Scene/Hierarchy 规则相同
• 同一个文件夹下，如果文件相关，使他们名称自然而然地归为一组

  • 一般来说，名字要以该物体所属的事物作为前缀

    例如：PlayerAnimationController、PlayerIdle、PlayerRun等

  • 合理的情况下，可以使相似的对象保持在一起，即使他们属于不同事物，或者形容词导致他们分开

    例如：在一个道具资产文件夹中，你可以用TableRound、TableRectangular来作为名称，这样它们就呆在一起，如果用RoundTable、RectangularTable，他们就不在一起了

• 避免在名称中使用文件类型

  例如：用ShinyMetal代替ShinyMetalMaterial

文件夹(Folders)

• 在根目录中，将你的资源放在能够识别游戏区域/系统/位置的文件夹中，可以创建子文件夹来分隔不同类型的资产
• 场景总是放在Scenes文件夹中
• 不属于特定系统的脚本放在Scripts文件夹中，可以创建子文件夹来分类
• 总而言之：如果一个系统/功能只有脚本，那就在Scripts中创建一个文件夹。如果它有其他类型的资产，那么将该文件夹放在根目录中，并根据资产类型添加子文件夹。如果它有其它类型的资产，就把该文件夹放在根目录下，并按照资产类型添加子文件夹

┌── Art
│   ├── Characters
│   │   └── PigChef
│   │       ├── Materials
│   │       ├── Prefabs
│   │       └── Textures
│   ├── Environment
│   │   ├── Interiors
│   │   ├── Nature
│   │   │   ├── Materials
│   │   │   ├── Prefabs
│   │   │   └── Textures
│   │   └── Props
├── UI
│   ├── Materials
│   ├── Scripts
│   └── ScriptableObjects
├── InventorySystem
│   ├── Scripts
│   └── ScriptableObjects
├── Scenes
│   ├── Locations
│   └── Menus
└── Scripts
    └── SceneManagementSystem