2 命名

名副其实

如果名称需要注释来补充 那就不算是名副其实

避免误导

避免留下掩藏代码本意的错误线索

• hp hypotenuse(斜边) & linux 专有名称【还有 aix sco】
• accountList 如果不是列表类型 => accountGroup | bunchOfAccounts | accounts

提防使用不同之处较小的名称

• XYZControllerForEfficientHandingOfStrings
• XYZControllerForEfficientStorageOfStrings

避免小写字母 l 和 大写字母 O 作为变量名

做有意义区分

避免数字系列命名
Product | ProductInfo | ProductData
Variable 不应存在于变量名中 | Table 不应存在于表名中
NameString | Name
moneyAmount | money
theMessage | message

使用可读名称

编程是一种社会活动 可读的名称便于沟通

使用可搜索名称

避免单字母名称和数字常量 —— 不便于查找和替换
单字母名称仅用于短方法的本地变量
名称长短应与其作用域大小相对应

避免使用编码

m_xxxx 应当把类和函数做得足够小 消除对成员前缀的需要
接口不应当加以修饰 前导字母 I 被滥用 干扰 废话，如果接口和实现必须选一个来编码的话 宁肯选择实现 ShapFacotryImpl | CShapFacotry

避免思维映射

不要中间映射步骤 明确是王道

类名

名词 | 名词短语

正确示例：Customer | WikiPage | Account | AddressParser
避免使用的名词：Manager | Processor | Data | Info

方法名

动词 | 动词短语

正确示例：postPayment | deletePage | save | getXxx | setXxx | 断言 isXxx

重载构造器时 使用描述了参数的静态工厂方法名

Complext fulcrumPoint = new Complext(23.0);
=>
Complext fulcrumPoint = Complex.fromRealNumber(23.0);
// 将相应构造器设置为 private，强制使用这种命名手段

每个抽象概念对应一个词

• controller 层：get
• serivce 层：list
• model 层：fetch

别用双关

• add
• append
• insert

使用解决方案领域名称

只有程序员才会读你的代码

• AccountVisitor 访问者模式
• JobQueue 队列

使用问题领域名称

至少负责维护代码的程序员就能去请教领域专家了
优秀的程序要其工作之一就是分离解决方案领域和问题领域的概念

添加有意义语境

需要批量加前缀的时候往往意味着你应该创建新的类来封装属性了

firstName | lastName | street | houseNumber | city | state | zipcode
=>
addrFirstName | addrLastName | addrStreet …
=>
Address

不要添加没用语境

CSDAccountAddress
精确是命名的重点