代码整洁之道:想要成为一个更好的程序员,你要注意这些方面
在我们的认知里,工程师和程序员是有区别的,程序员是属于那种做什么事情都是按部就班,没什么独立思考能力。但其实,程序员也可以看做是工程师,他们有工程师的思维,做一个项目需要考虑全局。
编程和写作都是在构建自己的世界,作家可以用文字构建自己的世界,在那个世界里,他想要什么样的角色,自己去生成。编程跟写作有共通之处,编程也是在构建自己的虚拟世界,在这个世界里可以去做一些他想做的事情。
跟文字一样,编程语言没有高低之分,真正的工程师需要掌握多种语言,工程师的作用就是他知道这个地方用什么语言实现最好。
但是除了会写代码,代码的整洁程度也很重要。这不仅仅让自己理清思路,也能方便他人看懂我们的代码,提高效率。
普通的工程师堆砌代码,优秀的工程师优雅代码,卓越的工程师简化代码。如何写出优雅整洁易懂的代码是一门学问,也是软件工程实践里重要的一环。
一本很有名的书籍《代码整洁之道 》,推荐大家去看看。
本篇文章重点将从注释、命名、方法、异常、单元测试等多个方面总结了一些代码整洁最佳实践。
注释
不要给不好的名字加注释,一个好的名字比好的注释更重要
不要“拐杖注释”,好代码 > 坏代码 + 好注释
在文件/类级别使用全局注释来解释所有部分如何工作
一定要给常量加注释
团队统一定义标记
TODO 待处理的问题
FIXME 已知有问题的代码
HACK 不得不采用的粗糙的解决方案
在注释中用精心挑选的输入输出例子进行说明
注释应该声明代码的高层次意图,而非明显的细节
不要在代码中加入代码的著作信息,git可以干的事情不要交给代码
源代码中的html注释是一种厌物, 增加阅读难度
注释一定要描述离它最近的代码
注释一定要与代码对应
公共api需要添加注释,其它代码谨慎使用注释
典型的烂注释
不恰当的信息
废弃的注释
冗余注释
糟糕的注释
注释掉的代码
唯一真正好的注释是你想办法不去写的注释
不要有循规式注释,比如setter/getter注释
不要添加日志式注释,比如修改时间等信息(git可以做的事情)
注释一定是表达代码之外的东西,代码可以包含的内容,注释中一定不要出现
如果有必要注释,请注释意图(why),而不要去注释实现(how),大家都会看代码
适当添加警示注释
命名
尽可能使用标准命名方法,比如设计模式,通用学术名词等
命名要找更有表现力的词
使用更专业的词,比如不用get而使用fetch或者download
避免空泛的名字,像tmp
使用具体的名字来细致的描述事物
给变量名带上重要的细节,比如加上单位ms等
为作用域大的名字采用更长的名字,作用域小的使用短名字
变量类型为布尔值表达加上is,has,can,should这样的词会更明确
变量名称长短应该与其作用域对应
别害怕长名称,长而具有描述性的名称比短而令人费解的名称好
函数名称应该说明副作用,名称应该表达函数,变量或类的一切信息,请不要掩盖副作用,比如CreateAndReturnXXX
方法
函数不应该有100行那么长,20行封顶最好
if else while等控制语句其中代码块应该只有一行,也就是一个函数调用语句
函数的锁进层次不应该多于两层
一个函数只做一件事,一个函数不应该能抽象出另外一个函数
某个公共函数调用的私有函数紧随其后
最理想的参数是零参数,最长不要超过三个入参,尽量不要输出参数
如果函数传入三个及以上参数最好将其抽象为类
标识参数十分丑陋,向函数传入布尔值用于区分不同业务的做法很丑陋,应该拆分为多个函数
别返回null值,抛出异常或者返回特殊对象,尽量避免NPE
别传入null值
异常与错误
抽离try catch包含的代码块,其中代码块抽象为一个函数
抛出的每个异常,都应当提供足够的环境说明,已便判断错误的来源与处所
不要将系统错误归咎于偶然事件
并发
分离并发相关代码与其它代码
严格限制对可能被共享的数据的访问
避免使用一个共享对象的多个同步方法
保持同步区域微小,尽可能少设计临界区
单元测试
不要怕单元测试的方法名字太长或者繁琐,测试函数的名称就像注释
不要追求太高的测试覆盖率,测试代码前面90%通常比后面10%花的时间少
使用最简单的并且能够完整运用代码的测试输入
给测试函数取一个完整性的描述性名字,比如 Test _
测试代码与生产代码一样重要
如果测试代码不能保证整洁,你就会很快失去他们
每个测试一个断言,单个测试中断言数量应该最小化也就是一个断言
FIRST原则
快速 Fast
独立 Independent 测试应该相互独立
可重复 Repeatable 测试应当在任何环境中重复通过
自足验证 Self-Validating 测试应该有布尔值输出
及时 Timely 最好的方式是TDD
独立 Independent 测试应该相互独立
可重复 Repeatable 测试应当在任何环境中重复通过
自足验证 Self-Validating 测试应该有布尔值输出
及时 Timely 最好的方式是TDD
代码结构
代码行长度控制在100-120个字符
可能用大多数为200行,最长500行的单个文件构造出色的系统
关系密切的代码应该相互靠近
变量声明应该靠近其使用位置
若某个函数调用了另外一个,应该把他们放在一起,而且调用者应该放在被调用者上面
自上向下展示函数调用依赖顺序
应该把解释条件意图的函数抽离出来,尽可能将条件表达为肯定形式
不要继承常量,比如接口中定义常量,不要使用继承欺骗编程语言的作用范围规则
模块不应了解它所操作对象的内部情况
DTO(Data Transfer Objects)是一个只有公共变量没有函数的类
对象暴露行为,隐藏数据
不要使用“尤达表示法” 如 if(null == obj),现代编译器对if(obj = null)这样的代码会给出警告
一般情况使用if else,简单语句使用三目运算符
通常来讲提早返回可以减少嵌套并让代码整洁
设计
类应该足够短小
类应该满足单一权责原则(SRP),类和模块只有一个修改理由
类应该只有少量的实体变量
类应该遵循依赖倒置原则 DIP(Dependency Inversion Principle),类应该依赖于抽象而不是依赖于具体细节
类中的方法越少越好,函数知道的变量越少越好,类拥有的实体变量越少越好
通过减少变量的数量和让他们尽量“轻量级”来让代码更有可读性
减少变量
缩小变量的作用域
只写一次的变量更好,如常量
最好读的代码就是没有代码
从项目中消除不必要的功能,不要过度设计
从新考虑需求,解决版本最简单的问题,只要能完成工作就行
经常性地通读标准库的整个API,保持对他们的熟悉程度
简单设计
运行所有测试
不可重复
表达了程序员的意图
尽可能减少类和方法的数量
以上规则按重要程度排列
无论是设计系统或者单独模块,别忘了使用大概可工作的最简单方案
整洁的代码只提供一种而非多种做一件事的途径,他只有尽量少的依赖。明确定义并提供尽量少的API
减少重复代码,提高表达力,提早构建,简单抽象
相信每一个优秀的工程师都有一颗追求卓越代码的心,在代码整洁工程实践上你有哪些好的建议?一起来讨论看看吧~
本文作者:竹涧
如果你也想成为程序员,想要快速掌握编程,这里为你分享一个学习基地!
里面有资深专业软件开发工程师,在线解答你的所有疑惑~C语言入门“so easy”
资料包含:编程入门、游戏编程、课程设计、黑客等。
代码整洁之道:想要成为一个更好的程序员,你要注意这些方面相关推荐
- 如何编写好的代码/成为一个更好的程序员
如何编写好的代码/成为一个更好的程序员 几个月前,有一位演讲者来到公司谈论优美的代码,他的论点是优美的代码以许多不同的形式出现.简单中有优美,折衷中有优美,稳定性上有优美,功能上有优美,坚固性上有优美 ...
- 如何成为一个更好的程序员,或者说是学习者?给你七个建议!
点击关注上方"五分钟学算法", 设为"置顶或星标",第一时间送达干货. 转自编码之外 今天庆哥就来和大家聊聊,如何成为一个更好的程序员,毕竟别人都说程序员都是屌 ...
- 30分钟,让你成为一个更好的程序员
我相信激励是非常重要的.这也是为什么我常常把时间管理(这些书激励我不管改进我的时间管理方法)的书和软件开发拿出来看看.我最近刚看完一本 书,"Apprenticeship Patterns: ...
- 冥想五个程序r_冥想将使您成为一个更好的程序员:这就是方法。
冥想五个程序r 什么是冥想? (What is Meditation?) Meditation can be many things depending on whom you ask. In thi ...
- 如何成为一个更好的程序员,应重视哪些方面?
点击蓝色"架构文摘"关注我哟 加个"星标",每天上午 09:25,干货推送! 来源:www.cnblogs.com/xiaozhi_5638/p/1018694 ...
- 【好书推荐】你想要的编码规范都在这里 | 《代码整洁之道》
目录 一.引言 二.书籍简介 三.好代码自己会说话 1. 清晰的变量命名规范 2. 好注释与坏注释 3. 错误处理 四.总结 一.引言 你好,我是小雨青年,一名程序员. 今天为你推荐的书籍是<代 ...
- 重读【代码整洁之道】
一.前言 [代码整洁之道]很经典,但也有些过时,翻译上也有些啰嗦,但总体上是好书.通过对本书核心内容的摘抄,结合自己的经验,整理了一些精简的点,这样你就省的去啃那本400多页的书了. 软件质量 = 架 ...
- 代码整洁之道(一)最佳实践小结
摘要: Any fool can write code that a computer can understand. Good programmers write code that humans ...
- 2015年第11本:代码整洁之道Clean Code
前一段时间一直在看英文小说,在读到<Before I fall>这本书时,读了40%多实在看不下去了,受不了美国人啰啰嗦嗦的写作风格,还是读IT专业书吧. 从5月9日开始看<代码整洁 ...
- 【整洁之道】如何写出更整洁的代码(上)
如何写出更整洁的代码 代码整洁之道不是银弹,不会立竿见影的带来收益. 没有任何犀利的武功招式,只有一些我个人异常推崇的代码整洁之道的内功心法.它不会直接有效的提高你写代码的能力与速度,但是对于程序员的 ...
最新文章
- java打包_java工程打包(方式一)
- 在vmware workstation上安装系统
- 解决bootstrap-table多次请求只触发一次的问题
- STL set容器的一点总结
- Struts 动态FORM实现过程
- Thymeleaf模板引擎处理日期输入框回显问题type=“date“类型的坑 和 单选按钮、复选框的回显
- PID控制器改进笔记之六:改进PID控制器之参数设定
- (62)SPI外设驱动协议(一)(第13天)
- QT5开发及实例学习之十九图形视图体系结构
- DevOps: 一例高负载多并发服务器连接池满的异常排解过程
- 一文搞懂什么是禁忌搜索算法Tabu Search【附应用举例】
- 2020年总结以及2021年的计划
- 韩寒等50名作家3.15联袂声讨百度侵权
- 阳春三月,花开醉满青春
- 35个非常出彩的 Flash 网站作品欣赏
- 算法笔记胡凡 7.3.4 连接各点时代码有误
- 互联网快讯:中国联通推出5G视频热线;极米Z6X Pro、极米H3S持续热销;丰速运与云快充达成合作
- IP,ARP,以太网--网络层与数据链路层详解
- ADB interface 驱动下载,以及使用,Because an app is obscuring a permission request settings can’t verify your
- 360个人图书馆禁止复制问题