规范直接使用代码展示,容易看懂自然而然也就会容易遵循。
破窗效应
一幢有少许破窗的建筑为例,如果那些窗不被修理好,可能将会有破坏者破坏更多的窗户。最终他们甚至会闯入建筑内,如果发现无人居住,也许就在那里定居或者纵火。一面墙,如果出现一些涂鸦没有被清洗掉,很快的,墙上就布满了乱七八糟、不堪入目的东西;一条人行道有些许纸屑,不久后就会有更多垃圾,最终人们会视若理所当然地将垃圾顺手丢弃在地上。这个现象,就是犯罪心理学中的破窗效应。
我们做项目也是一样的。一定要好好写代码,不要让“破窗”在我们的项目中发生,不能让项目有任何变混乱的趋势,保持项目清爽,这可以给我们开发者到来很好的工作体验,也就是所谓的心流体验。
如何命名?
在一些命名格式上,可以遵循编码规范就好了。但是如何给一个类/方法/变量/枚举命名呢?
在问这个问题前,我们来问另外一个问题,那就是程序语言,所谓的语言是给谁看的?一是给计算机或者编译器能看懂。二是给我们人类看的。让计算器或者编译器看懂很容易,只要遵循程序的语法去写就 OK 了。但是如何让人更容易看懂,当然答案也很简单,就是好好命名。关于如何命名,一些笔者至今受用的命名准则这里这里简单介绍下。
使用业务相关的词汇命名而不是计算机相关的词汇
比如,SaveMgr 中的 Save 是保存,是业务相关的词汇。而SerializeHelper 中的 Serialize 则是计算机相关的词汇。这条准则在 业务/逻辑/UI 层会有很大的效果。而在 Framework 层或者说底层还是使用计算机相关的词汇比较好。
方法/函数命名用谓语 + 宾语方式命名
比如 PlayerData.Save,或者 SavePlayerData
类名和方法参数使用名词
表示一个动作状态时通过动词的不同时态进行命名。
比如 Connecting,Connected,Connect 表示连接的三种状态。
关于命名和规范就先讲到这里,命名是一门学问,其内容多得可以去写一本书去介绍了。如果想深入学习,建议首先看《代码大全》的第 11 章 《命名的力量》。
小结
还记得在前边说的架构的定义嘛?架构是“约定、规则、共识”,而确定各种规范也是准备阶段要做的事情,也是架构的一部分。
再次起航
在新的公