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 ]
[
下一页 ]