1700453170
（3）流行
1700453171
1700453172
一种潮流风行世界的时候必然有其诞生的原因（感冒也包括在内），一种编码格式的流行也必然有它存在的理由，我们完全可以借鉴流行的编码格式，没有必要对这种风格进行重塑，而且使用流行风格可以让新成员尽快融入项目，避免出现进入一个新环境而出现茫茫无助的状态。
1700453173
1700453174
不要让您的代码规范标新立异，独树一帜，跟随“风尚”也许是一种省事、省力、省心的最好编码风格。
1700453175
1700453176
（4）便捷
1700453177
1700453178
制定出来的编码规范必须有通用开发工具支撑，不能制定出只能由个别开发工具支持的规范，甚至是绑定在某一个IDE上。在小范围内独乐乐，可以提升代码的友好度，方便使用，但很难大范围内推而广之，特别是很难上升到工程级别。代码风格是为一个团队准备的，如果团队中就只有一个开发人员，基本上代码风格不会有太大差异，这是习惯和个性使然，但是如果团队中有多个成员，就需要防止给开发人员过度的自由了，不符合开发规范的代码要坚决予以重构，以使团队代码风格一致。
1700453179
1700453180
现在的项目中源代码逐渐增多，完全依靠人工来做代码走查很难查出问题，我们可以使用工具来统计代码，这里推荐使用Checkstyle，它可以自定义代码模板，然后根据模板检查代码是否遵循规范，从而减少枯燥的代码走查。
1700453181
1700453182
1700453183
1700453184
1700453186
编写高质量代码：改善Java程序的151个建议 建议145：不要完全依靠单元测试来发现问题
1700453187
1700453188
单元测试的目的是保证各个独立分割的程序单元的正确性，虽然它能够发现程序中存在的问题（或缺陷，或错误），但是单元测试只是排查程序错误的一种方式，不能保证代码中的所有错误都能被单元测试挖掘出来，原因有以下四点。
1700453189
1700453190
（1）单元测试不可能测试所有的场景（路径）
1700453191
1700453192
单元测试必须测试的三种数据场景是：正常场景、边界场景、异常场景。一般情况下，如果这三种测试场景都能出现预期的结果，则认为代码正确，但问题是代码是人类思维的直观表达，要想完整地测试它就必须写出比生产代码多得多的测试代码，例如有这样一个类：
1700453193
1700453194
public class Foo{
1700453195
1700453196
//除法计算
1700453197
1700453198
public int divid（int a, int b）{
1700453199
1700453200
return a/b；
1700453201
1700453202
}
1700453203
1700453204
}
1700453205
1700453206
就这一个简单的除法计算，如果我们要进行完整的测试就必须建立三个不同的测试场景：正常数据场景，用来测试代码的主逻辑；边界数据场景，用来测试代码（或数据）在边界的情况下逻辑是否正确；异常数据场景，用来测试出现异常非故障时能否按照预期运行，测试类如下：
1700453207
1700453208
public class FooTest{
1700453209
1700453210
//构建测试对象
1700453211
1700453212
private Foo foo=new Foo（）；
1700453213
1700453214
//正常测试场景
1700453215
1700453216
@Test
1700453217
1700453218
public void testDividNormal（）{
1700453219
[
上一页 ]
[ :1.70045317e+09 ]
[
下一页 ]