每个程序员都能写出能运行的代码，但不是每个人都能写出好读好改的代码。好代码是什么样的？简单说，就是别人看一遍就懂，改起来顺手，测试起来也方便。具体来说：

• 容易看懂：代码像说话一样清楚，起名字让人一看就明白

• 容易修改：改这里不会影响那里，每个部分只管自己的事

• 容易测试：写测试用例不费劲，各种情况都能照顾到

• 结构清楚：相关的放一起，不相关的少联系

• 简单直接：不耍小聪明，不做现在用不上的功能

记住：能运行的代码只能完成任务，好代码才能让项目活得长久。

下面这这些方法，帮你写出今天能跑、明天好改的代码。

起名字要清楚

起名字是门学问，好名字比写注释还有用。

1. 用有实际意思的名字，别用a、b、c这种

2. 名字要体现业务含义，别只写技术细节

3. 用容易读、容易念的名字，方便讨论

4. 用方便搜索的名字，找起来快

5. 别加没用的修饰词，比如Data、Info这种

6. 尽量别用缩写，除非大家都懂

7. 布尔变量用is、has、should、can开头

8. 布尔变量别用否定形式，比如isNotReady就不如isReady清楚

9. 整个项目用同样的命名规则

10. 布尔变量用形容词

11. 类名用名词

12. 同一个意思别用不同词，比如user和account混用

13. 方法名用动词，比如getUser、saveOrder

14. 名字长度要适中，太短没意思，太长难读

写方法要专注

好方法应该只做一件事，并且把它做好。

15. 方法要短小，最好不超过30行

16. 参数要少，超过3个就要想想能不能简化

17. 别用布尔值当参数，这通常说明方法做了太多事

18. 方法尽量不要有副作用

19. 用枚举代替标志位参数

20. 用空行把不同逻辑分开

21. 如果30秒内看不懂方法在干嘛，就该重写了

22. 避免方法里嵌套太深，超过3层就难读了

23. 及时去掉没用的代码

24. 把复杂计算拆成小方法

25. 错误处理要统一

写类要职责分明

好的类应该像公司的部门，各管一摊，互不越权。

26. 一个类只负责一件事

27. 类不要太大，超过100行就要注意

28. 公共方法不要太多，5个以内比较好

29. 把小任务拆成私有方法

30. 按执行顺序排列方法

31. 多用组合，少用继承

32. 别让类之间关系太复杂

33. 内部实现细节不要暴露给外面

写注释要恰当

代码本身应该就能说明白，注释是辅助。

34. 能不用注释就不用

35. 别写一看就知道的废话

36. 别过度依赖注释

37. 用好名字代替注释

38. 注释主要解释“为什么这么做”

39. 注释可以说明隐藏的逻辑

40. api文档要写清楚

41. 过时的注释要及时删除

42. 复杂的算法可以加注释说明

写测试要可靠

测试是代码的保险，好测试能让你安心改代码。

43. 测试名字要说清楚测试什么场景

44. 用Given/When/Then的结构组织测试

45. 用Arrange/Act/Assert的步骤写测试

46. 测试里别用if、for这些逻辑

47. 一个测试只测一个行为

48. 用有意义的测试数据

49. 隐藏无关的测试细节

50. 断言要反映业务要求

51. 测试结果要稳定，每次跑都一样

52. 用参数化测试减少重复

53. 模拟依赖时，优先用fake对象

54. 测试要跑得快

55. 测试之间要独立

56. 测试要能重复运行

57. 测试要能自己判断对错

58. 测试要覆盖正常、异常、边界情况

提交代码要规范

清楚的提交记录能让团队合作更顺畅。

59. 早点提交，经常推送

60. 提交信息要说清楚为什么改

61. 提交信息用现在时态

62. 提交里附上相关任务链接

63. 一次提交只做一件事

64. 提交前跑一遍测试

65. 别提交调试用的临时代码

避开这些坏味道

有些代码问题很常见，要特别注意。

66. 别用魔法数字，用常量代替

67. 过长的条件判断要简化

68. 少用全局变量

69. 参数列表别太长

70. 别滥用基本类型，用合适的类型建模业务

71. 嵌套别太深

72. 控制圈复杂度

73. 难测试的代码通常有问题

74. 别重复代码

75. 别过度设计

76. 别提前优化

代码格式要统一

一致的格式让代码更好读。

77. 团队用同样的编码规范

78. 用自动化格式化工具

79. 限制每行长度

80. 别用水平对齐

81. 遵守缩进规则

82. 变量在用的时候声明

83. 大括号风格要统一

84. 导入语句要整理

记住这些核心原则

写好代码要遵循一些基本原则。

85. 不要重复自己（DRY）

86. 保持简单（KISS）

87. 不做不需要的事（YAGNI）

88. 告诉对象做什么，别问它状态（Tell, Don‘t Ask）

89. 单一职责原则

90. 里氏替换原则

91. 接口隔离原则

92. 依赖倒置原则

93. 多用组合，少用继承

94. 分而治之

95. 高内聚

96. 低耦合

其他实用建议

还有一些小技巧也很管用。

97. 用好IDE的重构功能

98. 熟练使用快捷键

99. 按功能组织文件结构

100. 结对编程

101. 删掉没用的代码

102. 记住代码是给人读的

103. 可读性比耍小聪明重要

104. 大多数时候，可读性比效率重要

105. 让代码比你接手时更干净

106. 早点测试，经常测试

107. 早点重构，持续重构

108. 多做代码审查

109. 重复出现3次的代码就要抽象

110. 尽量避免用NULL

111. 能运行的代码不等于好代码

112. 没有测试就不可能有好代码

113. 代码要像写文章一样有结构

114. 及时还技术债

115. 多读好代码，学习别人的写法

写好代码不是一朝一夕的事，需要不断练习和反思。从今天开始，每次写代码时多想一步，多用几个这些方法，慢慢你就会发现，你的代码质量真的提高了。好代码不仅让现在的你省心，也让未来的你感谢现在的自己。

本文内容仅供个人学习/研究/参考使用，不构成任何决策建议或专业指导。分享/转载时请标明原文来源，同时请勿将内容用于商业售卖、虚假宣传等非学习用途哦～感谢您的理解与支持！

链接: https://fly63.com/article/detial/12942