. y2 T1 I. p- a- }2 j! h5 s( _8)、 方法命名(*)方法的命名应当使用动词,头一个字母小写,以后每个内部单词的头一个字母大写。在方法名的选择上应意义明确便于记忆。对于属性的存取方法,应使用getXXX()和setXXX()名称,以isXXX(),hasXXX()来命名返回值为boolean 类型的方法。# o m/ h0 y6 n0 o# Q2 a* O6 D0 R
% W9 z: ?4 V' E. }/ w9 e' w, O以上几条如果符合就算是好代码了吗?当然不是,这只是代码中最基本的命名规范而已,就算不符合最多就是代码不好看,没什么其他影响。8 e1 n3 U2 {* F
' E, ~$ `; b: k! q代码逻辑规范5 B6 A" H8 `( J% I
, r/ P- |) t% ]5 p, }3 p% q! X
1)、需求、设计中的重点功能(结合需求/设计的评审产出) ( l' V( m- e3 m F7 A( C r/ ?7 T! S$ j6 N# q$ _' h, W" h
2)、代码格式校验 : r3 V% u& z9 e/ [% Eaction/façade等系统入口是否有数据格式校验! H7 e- g3 b. H) t$ U y4 Q6 C
需要存入数据库的数据字段是否有长度校验, X" y; L$ }' ~) @- h# [
9 o& d$ O' @8 j6 z- G3)、分支/循环" {8 |! E6 D9 t! f
if-else/switch是否处理了所有分支 . n( E5 N+ s' [1 _1 p) _4 V# h分支的条件语句是否有“副作用”;即,条件语句是否会改变系统状态/数据等6 a1 d" L9 H& N
循环边界是否覆盖了所有元素: n \3 g C, d# j9 N
是否有死循环等 ! i- r6 p) T" O x, r. |" [$ p: t- N) F: p
4)、异常处理6 O2 r. G4 h* e! |! h& u5 v
是否有“吃掉异常”的情况 4 y& t4 w! D0 ^& I是否记录了异常日志 r3 S! J2 t5 ~9 l
如果二次抛出,是否有合理的异常层次/结构 ; H$ P& _ l0 {/ K5 W C如果内部处理,对异常的处理是否能保证后续代码正常运行$ ?6 l: _8 G2 z4 R+ O
; A- ]- _9 c' Z# N/ M5)、单元测试9 T k4 N. D! n$ ?% A' y
是否有单元测试 7 B0 Y) u6 b0 C! Z- i7 \' l单元测试是否自动化 ! t! p9 A: Z3 V; a单元测试是否能完整覆盖需求 7 [; ^/ J' \0 i, A* O! z1 I% ^' D( }5 q * O6 v2 a7 k; s2 F6)、 事务处理! V" F) c. f$ \8 Y$ ~1 K
事务范围是否合理;或者说,是否把不必要的操作放到了同一个事务中& z: m& o4 q* V
事务传播方式是否合理(required,never,new等配置) 3 W+ R3 p5 V) B, |1 [1 k/ U& r6 H/ f! {5 A8 N' {4 N
7)、sql语句. k/ e5 j! k O3 [9 {! c- w* w
sql语句是否正确 1 c M6 B+ S* E使用mybatis的动态语句时,是否有潜在的sql语法问题 5 C2 A Z* c* X6 d " d; \3 k9 v8 F* j2 T8)、第三方组件 1 V" n# e- Z5 f8 N使用Redis,RabbitMQ等组件,是否真的对组件完全了解,在使用的过程中是否正确执行了开启与关闭操作。; e2 {: F @4 d4 i, i
( v1 M9 X! }" Y( e. j9 l3. 可继承性。代码重用性,根据新的功能不用修改目前代码或是很少修改吧所需要的功能添加上去。" K/ K$ Q7 T' X8 K3 I+ H! ? s
@# J$ ?! x. E- [( x( C' a+ Q4. 可测性、可配置性和已修复bug。把所设计的代码根据功能进行,尽量少的bug。项目模块化,根据模块的配置进行项目的组装,成为新的项目。 , f* r B) ]7 |# B2 m1 }: K& O8 o& V' N6 O
$ j: @: Q& m8 C0 o: c3 m
{1 A G6 u! \ 关于其他方面的说明定义: 0 Y: G: F/ D0 v; B $ Z$ ?$ n. B3 K/ T 'Good code' is code that works, is bug free, and is readable and maintainable. Some organizations have coding 'standards' that all developers are supposed to adhere to, but everyone has different ideas about what's best, or what is too many or too few rules. There are also various theories and metrics, such as McCabe Complexity metrics. It should be kept in mind that excessive use of standards and rules can stifle productivity and creativity. 'Peer reviews', 'buddy checks' code analysis tools, etc. can be used to check for problems and enforce standards. 1 m7 `6 Q" `9 x1 |8 w' o' D" ^' I1 ^: J5 w0 S
另外,来自 MSDN END BRACKET 栏目的作者 Paul DiLascia ,也列出了优秀代码应有的物质:不管你用什么语言进行开发,所有的优秀代码都会展示出共有的经典品质:简练,易于理解,模块化,层次性,设计良好,高效,优雅,并且清晰。, q$ I9 n" U4 `3 Z2 ^
--------------------- # ?% b2 e# E( s* ^* B# V+ g
作者:美丽海洋 ) _! p) e( E S$ ]( f# R4 o
来源:CSDN 7 l) X7 e5 ^6 P6 w0 Q7 Y1 w$ S2 w! k/ ^! h7 M+ P2 w7 @# Z
$ V( i% q8 ]- h: {' H7 S* o