济南网站制作公司哪家技术好,网页设计实验报告步骤,提供手机自适应网站公司,深企在线命名的原则
1. “小处诚实非小事“
有个词叫做”以小见大“。以建筑作喻#xff0c;宏大建筑中最细小的部分#xff0c;比如关不紧的门、未铺平的地板#xff0c;甚至时凌乱的桌面#xff0c;都会将整个大局的魅力毁灭殆尽#xff0c;这就是整洁代码之所系。
2. 有意义…命名的原则
1. “小处诚实非小事“
有个词叫做”以小见大“。以建筑作喻宏大建筑中最细小的部分比如关不紧的门、未铺平的地板甚至时凌乱的桌面都会将整个大局的魅力毁灭殆尽这就是整洁代码之所系。
2. 有意义的命名 选个好名字省下来的时间比花掉的多。一旦发现有更好的名字就换掉旧的名字。 2.1 名副其实
变量、函数和类的名字应该告诉读者它为什么存在、它做什么事、它应该怎么用。如果名称需要注释来补充那就不算是名副其实。
举例
int d; // 消逝的时间以日计上例中变量d只能暗示这是一个表示day-天数的变量但没有“消逝”的含义。我们应该明确指明计量对象和计量单位的名称
int elapesdTimeInDays;
int daysSinceCreation;
int daysSinceModification;
int fileAgeInDays;再举一个例子
std::listvectorint *getThem()
{auto *list1 new std::listvectorint;for (auto x : theList){if (x[0] 4)list1-push_back(x);}return list1;
}上例中getThem、x[0] 4、theList等都比较模糊。可以改成这样
listvectorint *getFlaggedCells()
{auto *flaggedCells new listvectorint;for (auto cell : gameBoard){if (cell[STATUS_VALUE] FLAGGED)flaggedCells-push_back(cell);}return flaggedCells;
}还可以更进一步不用vectorint来表示单元格而是用一个对象来表示并做好封装
listCell *getFlaggedCells()
{auto *flaggedCells new listCell;for (auto cell : gameBoard){if (cell.isFlagged())flaggedCells-push_back(cell);}return flaggedCells;
}与第一个版本比起来这里明显更容易理解了。
2.2 避免误导
程序员必须避免留下掩藏代码本意的错误线索。
避免使用特定平台专有名称。如hp、aix、sco。避免物理数据结构名称与变量名不同的情况。例如AccountList其内部是用list存储的吗避免使用不同之处较小的名称。避免l、o这种外观有歧义的名称。
2.3 做有意义的区分
对于编译器或者解释器来说只要名称中有一个字符的不同就不会出错但是对于读者来说我们不仅需要名称不同还要对名称做出有意义的区分。
举例来说对于a1, a2, a3,…这样的区分方式任何人不结合上下文的情况下看了都会一头雾水。还有类似getActiveChannel, getActiveChannels, getActiveChannelInfo这样的命名方式也不容易看出它们的区别。
另外我们也要尝试抛弃变量命中没有意义的部分例如NameString不如改为Name除非Name还可以不用String来表示。
2.4 使用读的出来的名称
读的出来的名称一方面便于程序员间的交流另一方面也利用了人类大脑的语言功能便于理解和记忆。
比较下面两个例子
class DtaRcrd102
{
private:Date genymdhms;Date modymdhms;const string pszqint 102;
};class Customer
{
private:Date generationTimestamp;Date modificationTimestamp;const string recordId 102;
};2.5 使用可搜索的名称
可搜索性还是在强调名称要具有区分度。所以坚持这个原则长名称胜于短名称除非短名称已足够精确搜得到的名称胜于用自造编码代写的名称。
单字母名称仅适用于短方法中的本地变量。名称长短应与其作用域大小相对应。
2.6 避免使用编码
尽量避免将对象的类型和作用域编码进名称中因为这会增加不必要的负担。现代的编译器和静态分析器能够帮助我们检查对象的类型。
看一下有哪些反例
匈牙利标记法Hungarian Notation, HN成员前缀m_
有一个例外是对接口和实现的编码例如对于抽象工厂模式可以将接口类命名为ShapeFactory而将具体类命名为ShapeFactoryImpl。
2.7 避免思维映射
不应当让读者在脑中把你的名称翻译为他们熟知的名称。这种问题经常出现在选择是使用问题领域术语还是解决方案领域术语时。
我们应该尽量让名称明确而不是自以为是的认为一种名称与某个对象之间存在一种映射关系。例如以r代表url。最终目的是编写让他人能轻易理解的代码。
2.8 类名
类名和对象名应该是名词或者名字短语如Customer, WikiPage, Account和AddressParser。避免使用Manager, Processor, Data, Info这种缺少实际意义的词。类名不应当是动词。
2.9 方法名
方法名应当是动词或动词短语如postPayment、deletePage或save。
重载构造器时使用描述了参数的静态工厂方法名。例如
Complex fulcrumPoint Complex.FromRealNumber(23.0);通常好于
Complex fulcrumPoint new Complex(23.0);2.10 别扮可爱
名字不要太耍宝毕竟别人不一定有你的幽默感。宁可明确毋为好玩。
2.11 每个概念对应一个词
给每个抽象概念一个词并且一以贯之。例如不要混用fetch、retrieve和get。在同一堆代码中有controllermanager和driver它们的区别是什么
2.12 别用双关语
避免将同一单词用于不同目的。如果同一术语用于不同的概念那么它基本上就是双关语了。
我们要遵循“一词一义”规则例如对于add方法如果它出现在多个类中我们要保证这些add方法的参数和返回值在语义上等价。具体地说如果在一个类中。add方法通过增加或连接两个现存值来获得新值并返回。现在要写一个新类需要一个方法能够把参数添加道容器中那么就不能把这个方法叫做add因为这样做的话add就变成了双关语。可以使用insert、append之类地词。
2.13 使用解决方案领域名称
我们的读者都是程序员所以如果可以尽量使用计算机科学中的术语、算法名、模式名和数学术语。例如对于熟悉访问者(VISITOR)模式的程序员来说AccountVisitor富有意义。
2.14 使用源自所涉问题领域的名称
如果真的不能用程序员所熟悉的术语来命名那就采用问题涉及领域的名称吧。至少负责维护代码的程序员知道该去请教谁。
优秀的程序员和设计师其工作之一就是分离解决方案领域和问题领域的概念。与所涉问题更为贴近的代码应当采用源自问题领域的名称。
2.15 添加有意义的语境
单单一个名称能够说明的信息还是太过有限。我们需要有良好命名的类、函数或者名称空间来放置名称给读者提供语境。如果没有这么做那么给名称添加前缀就是最后一招了。
那么如何添加语境呢举例来说可以从一个复杂的函数体中拆分出多个步骤然后给这些子函数命上合适的名字从而提供更多语境告诉读者整个函数的逻辑。
不要添加没用的语境
只要现有的代码已经足够清楚就没必要拆分出不同的子函数。只要短名称足够清楚就比长名称好。
