如果代码可以被团队中的每个人轻松理解，那么代码就是干净的。干净的代码可以由原作者以外的开发人员阅读和增强。可理解性带来了可读性、可更改性、可扩展性和可维护性。
一般规则
遵循标准约定。 保持简单愚蠢。越简单总是越好。尽可能降低复杂性。 童子军规则。让露营地比您发现时更干净。 始终找到根本原因。始终寻找问题的根本原因。
设计规则
将可配置数据保持在较高水平。 更喜欢多态而不是 if/else 或 switch/case。 独立的多线程代码。 防止过度配置。 使用依赖注入。遵循德墨忒尔法则。一个类应该只知道它的直接依赖关系。
可理解性提示
保持一致。如果你以某种方式做某事，那么所有类似的事情也以同样的方式做。 使用解释变量。 封装边界条件。边界条件很难跟踪。将它们的处理放在一个地方。 优先选择专用值对象而不是原始类型。 避免逻辑依赖。不要编写依赖于同一个类中其他内容而正确工作的方法。 避免否定条件。
命名规则
选择描述性且明确的名称。 进行有意义的区分。 使用可发音的名称。 使用可搜索的名称。 用命名常量替换幻数。 避免编码。不要附加前缀或类型信息。
函数规则
小。 做一件事。 使用描述性名称。 喜欢更少的争论。没有副作用。 不要使用标志参数。将方法拆分为几个独立的方法，这些方法可以在不带标志的情况下从客户端调用。
评论规则
始终尝试用代码来解释自己。不要多余。 不要添加明显的噪音。 不要使用右大括号注释。 不要注释掉代码。只需删除即可。用作意图解释。 用作代码说明。用作后果警告。
源代码结构
代码小浣熊
代码小浣熊是基于商汤大语言模型的软件智能研发助手，覆盖软件需求分析、架构设计、代码编写、软件测试等环节
51 查看详情 垂直分隔概念。 相关代码应垂直密集显示。 声明接近其用法的变量。 依赖函数应该关闭。 类似的功能应该很接近。 将函数放在向下的方向。 保持简短。 不要使用水平对齐。 使用空格来关联相关事物并分离弱相关事物。 不要破坏缩进。
对象和数据结构
隐藏内部结构。 更喜欢数据结构。 避免混合结构（一半对象和一半数据）。应该很小。 做一件事。 少量实例变量。 基类应该对其派生类一无所知。 拥有许多函数比将一些代码传递到函数中来选择行为更好。 优先选择非静态方法而不是静态方法。
测试
每个测试一个断言。 可读。快。独立。 可重复。
代码味道
刚性。软件很难改变。一个小小的改变会导致一连串的后续改变。脆弱。由于一次更改，该软件在许多地方出现故障。 一动不动。您无法在其他项目中重复使用部分代码，因为涉及风险和工作量。 不必要的复杂性。 无需重复。 不透明度。代码很难理解。
我想的就这么多，但还有更多。
请阅读整本书。
感谢您阅读总结，希望对您有所帮助。
网站：
https://kaleemelahi.co
给我买一杯咖啡：
https://buymeacoffee.com/kaleemelahi
以上就是整洁的代码摘要的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/390070.html
微信扫一扫 
支付宝扫一扫 
