通用命名规则
总述
函数命名，变量命名，文件命名要有描述性，少用缩写（大众性的缩写可以使用）
说明
尽可能的使用描述性的命令，可以体现其准确功能的命名方式。尽量不适用缩写，不节省空间，让读者能读懂是最重要的事情。变量、函数或类的名称应该已经答复了所有的大问题。它该告诉你，它为什么会存在，它做什么事，应该怎么用。如果名称需要注释来补充，那就不算是名副其实。
反面例子
int n //毫无意义
int AdgCompConns //含糊不清的缩写
int PcReader //Pc有太多含义了
int CstrmId //缩减了太多的字母
正面例子
int PriceCountReader; // 无缩写
int NumError // num 是常见的写法
int TreeHeight //树的高度
类和方法命名
总述
必须以大写字母开头，以清晰表达类的用途和功能为原则。
说明
类是一类方法集合。命名的方式应该是以名词为主，清晰的表达类的功能，方法应当以动词为主，表现其做了什么事情，并且得到什么结果
反面例子
//含义太广
class UMobile
{
public:
float Space(); // 含义表达不清晰，不知道做了什么
float GetSize(); //不知道获取什么大小
}
正面例子
//命名清晰，这个类为移动设备安卓和连接
class UMobileInstalledContent
{
public:
/** Get the disk free space in megabytes where content is installed /
float GetDiskFreeSpace(); // 获取磁盘空余的空间，获取为一个动作，结果是得到空间大小
/* Get the installed content size in megabytes */
float GetInstalledContentSize(); //获取安装content文件的大小
};
名副其实
总述
变量的命名应该是“名副其实”
说明
名副其实说起来简单。我们想要强调，这事很严肃。选个好名字要花时间，但省下来的时间比花掉的多。注意命名，而且一旦发现有更好的名称，就换掉旧的。这么做，读你代码的人（包括你自己）都会更开心。
反面例子
List<int[]> getThem()
{
List<int[]> list1 = new ArrayList<int[]>();
for (int[] x : theList)
if (x[0] == 4)
list1.add(x);
return list1;
}
这其中存在一些问题
- theList中是什么类型的东西？
- theList零下标条目的意义是什么？
- 值4的意义是什么？
- 我怎么使用返回的列表？
问题的答案没体现在代码段中，可代码段就是它们该在的地方。比方说，我们在开发一种扫雷游戏，我们发现，盘面是名为theList的单元格列表，那就将其名称改为gameBoard。
正面例子
盘面上每个单元格都用一个简单数组表示。我们还发现，零下标条目是一种状态值，而该种状态值为4表示“已标记”。只要改为有意义的名称，代码就会得到相当程度的改进：
List getFlaggedCells()
{
List flaggedCells = new ArrayList();
for (Cell cell : gameBoard)
if (cell.isFlagged())
flaggedCells.add(cell);
return flaggedCells;
}
避免误导
总述
程序员必须避免留下掩藏代码本意的错误线索。应当避免使用与本意相悖的词
说明
别用accountList来指称一组账号，除非它真的是List类型。List一词对程序员有特殊意义。如果包纳账号的容器并非真是一个List，就会引起错误的判断。
所以，用accountGroup或bunchOfAccounts，甚至直接用accounts都会好一些。
提防使用外形相似度较高的名称。例如，想区分模块中某处的XYZControllerFor-EfficientHandlingOfStrings和另一处的XYZControllerForEfficientStorage-OfStrings，会花多长时间呢？这两个词的外形实在太相似了。
做有意义的区分
总述
如果程序员只是为满足编译器或解释器的需要而写代码，就会制造麻烦。
说明
因为同一作用范围内两样不同的东西不能重名，你可能会随手改掉其中一个的名称，有时干脆以错误的拼写充数，结果就会出现在更正拼写错误后导致编译器出错的情况。光是添加数字系列或是废话远远不够，即便这足以让编译器满意。如果名称必须相异，那么其意思也应该不同才对。
举例
以数字系列命名（a1、a2…aN）是依义命名的对立面。这样的名称纯属误导——完全没有提供正确信息，没有提供导向作者意图的线索。试看：
void copyChars(char a1[], char a2[]) {
for (int i = 0; i < a1.length; i++) {
a2[i] = a1[i];
}
}
如果参数名改为source和destination，这个函数就会像样许多。
废话是另一种没意义的区分。假设你有一个Product类，如果还有一个名为ProductInfo或ProductData的类，那它们的名称虽然不同，意思却无区别。Info和Data就像a、an和the一样，是意义含混的废话。
设想有一个名为Customer的类，还有一个名为CustomerObject的类，它们的区别何在呢？哪一个是表示客户历史支付情况的最佳方式？
使用可搜索的名称
总述
对于单字母名称和数字常量，有一个问题，就是很难在一大篇文字中找出来。
说明
找MAX_CLASSES_PER_STUDENT很容易，但想找数字7就麻烦了，它可能是某些文件名或其他常量定义的一部分，出现在因不同意图而采用的各种表达式中。如果该常量是个长数字，又被人错改过，就会逃过搜索，从而造成错误。
反面例子
for (int j=0; j<34; j++) {
s += (t[j]*4)/5;
}
正面例子
int realDaysPerIdealDay = 4;const int WORK_DAYS_PER_WEEK = 5;int sum = 0;for (int j=0; j < NUMBER_OF_TASKS; j++) {
int realTaskDays = taskEstimate[j] * realDaysPerIdealDay;
int realTaskWeeks = (realTaskdays / WORK_DAYS_PER_WEEK);
sum += realTaskWeeks;
}
注意，上面代码中的sum并非特别有用的名称，不过至少搜得到它。采用能表达意图的名称，貌似拉长了函数代码，但要想想看，WORK_DAYS_PER_WEEK比数字5好找得多，而列表中也只剩下了体现作者意图的名称。
UE特殊命名规则
命名规范
- 所有代码和注释都应采用美式标准英语的拼写和语法。
- 命名（如类型或变量）中的每个单词需大写首字母，单词间通常无下划线。例如：Health 和 UPrimitiveComponent，而非 lastMouseCoordinates 或 delta_coordinates。
- 类型名前缀需使用额外的大写字母，用于区分其和变量命名。例如：FSkin 为类型名，而 Skin 则是 FSkin 的实例。
- 模板类的前缀为T。
- 继承自 UObject 的类前缀为U。
- 继承自 AActor 的类前缀为A。
- 继承自 SWidget 的类前缀为S。
- 抽象界面类的前缀为I。
- 列举的前缀为E。
- 布尔变量必须以b为前缀（例如 bPendingDestruction 或 bHasFadedIn）。
- 其他多数类均以F为前缀，而部分子系统则以其他字母为前缀。
- Typedefs应以任何与其类型相符的字母为前缀：若为结构体的Typedefs，则使用F；若为 Uobject 的Typedefs，则使用U，以此类推。
- 特别模板实例化的Typedef不再是模板，并应加上相应前缀，例如：
typedef TArray FArrayOfMyTypes;
- 特别模板实例化的Typedef不再是模板，并应加上相应前缀，例如：
- C#中省略前缀。
- 多数情况下，UnrealHeaderTool需要正确的前缀，因此添加前缀至关重要。
- 类型和变量的命名为名词。
- 方法名是动词，以描述方法的效果或未被方法影响的返回值。
- 若In或Out参数同样为布尔，以b作为In/Out的前缀，如 bOutResult。
扫一扫
2651
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
