-
让变量的命名
名副其实
,如果变量名称需要注释来补充,那就不算是名副其实。 -
废话就是冗余,
Variable
一词永远不应该出现在变量名中。 -
类名和对象名应该是名词或名词短语。
-
方法名应该是动词或动词短语。
-
可以考虑将相应的构造器设置为
private
,强制使用参数的静态工厂方法名。 -
函数的第一规则是要短小,第二条规则是要更短小。
-
每个函数都只说一件事,而且,每个函数都依序把你带到下一个函数,这就是函数应该达到的短小程度。
-
函数应该做一件事。做好这件事。只做这一件事。
-
最理想的参数数量是零(零参数函数),其次是一(单参数函数),再次是二(双参数函数),应尽量避免三(三参数函数)。
-
如果函数看来需要两个,三个或者三个以上参数,就说明其中一些参数应该封装为类了。
-
用代码本身来表达意图,而不是通过注释。好的代码不需要注释。
-
随着时间的流逝,注释会越来越背离代码。因为程序员一般不维护注释。
-
不要注释代码:让别人觉得想删又怕以后有用。
-
概念相关的代码应该放到一起。相关性越强,彼此之间的距离就该越短。
-
一般而言,自上向下展示函数调用依赖顺序。也就是说,被调用的函数应该放在执行调用的函数下面。
-
一个开发小组应该使用一样的代码风格来编写代码。
-
对象暴露行为,隐藏数据;数据结构暴露数据,没有明显的行为。
-
错误处理很重要,但如果它搞乱了代码逻辑,就是错误的做法。
-
测试代码和生产代码一样重要。它需要被思考,被设计和被照料。它该像生产代码一样保持整洁。
-
把单元测试清晰地拆分为三个环节:1.构造测试数据;2.操作测试数据;3.检验操作是否得到期望的结果。
-
Given-when-then约定:given一个上下文,指定测试预设;when进行一系列操作,即所要执行的操作;Then得到一系列可观察的后果,即需要检测的断言。
-
系统应该由许多
短小
的类而不是少量巨大的类组成。每个小类封装一个权责
,只有一个修改的原因,并与少数其他类一起协同达成期望的系统行为。 -
在理想系统中,我们通过扩展系统而非修改现有代码来添加新特性。
-
软件系统应该将启始过程和运行过程逻辑分离开。对象的初始化和运行逻辑分离,spring的IOC就遵循这一法则。
-
单一权责原则(SRP)认为方法/类/组件应当只有一个修改的理由。并发设计自身足够复杂到成为修改的理由,所以也该从其他代码中分离出来。
-
不要将系统错误归咎于偶发事件。
-
注释只应该描述有关代码和设计的技术性信息。
-
注释应该提及代码自身没提到的东西。
-
删除注释掉的代码。
-
基类应该对派生类一无所知。
-
用多态代替If/Else或Switch/Case。
-
魔术数
指的是那些不能自描述的数字,如果数字可以自描述,不需要使用变量来定义它。 -
如果要让函数之间有
时序耦合
,比较好的做法是让上一个函数产生下一个函数所需的结果。 -
名称的作用范围越大,名称就该越长越准确。
03-27
03-27
“相关推荐”对你有帮助么?
-
非常没帮助
-
没帮助
-
一般
-
有帮助
-
非常有帮助
提交