35.注解优于命名模式：
一般命名模式表明有些程序元素需要通过某种工具进行特殊处理。
例如：JUnit测试框架要求用户一定要用test作为测试方法名称的开头。这种方法有几个严重的缺陷
首先，文字拼写错误会导致失败，但是没有任何提示。比如，把方法名称命名写成tsetSafety而不是testSafety时。JUnit不错报错，但是也不会执行测试。
其次，无法确保它们只用于相应的程序元素上。比如，将每个类命名为testSafety，是希望JUnit会
自动的测试这个类的所有方法，而不管什么方法名称， JUnit不会报错，也不会执行测试，因为它针对的是方法名，不是类名。
再次，它们没有提供将参数值与程序元素关联的好方法。比如，想要支持一种测试类别，它只在抛出特
殊异常时才会成功。异常类型本质是测试的一个参数，如果命名类不存在，或者不是一个异常，你只有通过运行后才能发现。
普通的Test注解只用于无参的static方法。
这表明Test注解应该在运行时保留，否则测试工具不知道；
Test注解旨在方法声明种才是合理的。
用于异常的ExceptionTest注解
36.坚持使用Override注解
它表示被注解的方法声明覆盖了父类中的一个声明。
代码检验code inspection
37.用标记接口用于类型（marker interface）
https://blog.csdn.net/Sziwu/article/details/52441569?locationNum=1&fps=1
例如 Serializable接口，里面没用任何方法。但是实现了这个接口就可以被传入ObjectOutputStream里面
优点：
1.标记接口所定义的类型是由被标记类的实例实现的。标记注解并没有定义这样的类型。
2.可以被更加精确地进行锁定。
标记接口：
标记注解：
38.检查参数的有效性
断言Assertion ：用assert来检查传进来的参数。（默认是关闭断言的）
构造器的参数检查是非常重要的。
39.必要时进行保护性拷贝
Java 是一种safe language。它对于缓冲区溢出、数组越界、非法指针以及其他的内存破坏错误自动免疫
假设使用类的客户端会尽可能地破坏这个类，所以必须要保护性地设计这些程序
对于不可变类，可以这样设计：
1.
2.防止别人把对象扯出来攻击
40.谨慎设计方法签名
谨慎地选择方法的名称；
不要过于追求提供遍历的方法；
避免过长的参数列表：1.将方法分解成多个子方法；2.创建辅助类；3.从对象构建到方法都采用Builder模式
对于参数类型，优先选择接口而不是类
对于boolean参数，优先使用2个元素的枚举类型。
41.慎用重载
这个例子会输出3个 Unknown Collection
42.慎用可变参数
担心在使用可变参数的时候，用户什么都不输入：
改为
简而言之，在定义参数数目不定的方法时，可变参数方法是一种很方便的方式，但是它们不应该被过度滥用。如果使用不当，会产生混论的结果。
43.返回零长度的数组或者集合，而不是null
对于一个返回null而不是零长度数组或者集合的方法，几乎每次用到该方法的时候都要判断返回值是不是null。这样做很容易出错。
返回null比返回零长度的数组避免了花销？1.在这个级别上关心性能不明智；2.每次返回的零长度数组可以共用
零长度的数组str被传入toArray里面，指明所期望的返回值。当stringList不为空的时候，会把它转化为数组；否则就将返回零长度的数组。
44.为所以导出的API元素编写文档
45.将局部变量的作用域最小化
要使局部变量的作用域最小化，最有力的方法就是在第一次使用它的地方声明。过早地声明局部变量不仅会使他的作用域过早扩展，而且结束得也过于晚了。局部变量的作用域从它被声明开始扩展，一直到外围块的结束。如果是在块外声明的，那么在使用完它后，在块外该变量仍然可见。
每个局部变量的声明都应该包含一个初始化表达式。如果还么有足够的信息来对一个变量进行有意义的初始化，就应该推迟这个声明，知道可以说i初始化为止。
但是遇到try-catch块的时候，变量的声明在外，变量的初始化在内，在try块之前还不能被有意义的初始化。