如何编写更棒的代码:11个核心要点
作为一个合格的程序员,有太多的理由促使你去编写干净利落且可读性强的代码。最重要的是因为你编写的代码,将来会有很多人一次次地阅读。当你有 一天回过头来看自己的代码时,你就会明白编写优雅的代码是多么的重要。另外,如果别人来阅读你编写的代码,你是否想知道别人看到那些烂代码无比抓狂的感 受。因此,花多一点的时间去编写优雅的代码,将来说不定会给你节省更多的时间。
那么,如何编写更棒的代码,下面是 11 条基本规则:
- 保持方法简短扼要
- 永远永远不要将同一个变量用于不同的目的
- 尽可能让变量和方法的名称能够描述要实现的功能
- 尽可能将变量定义在最靠近它们的地方
- 不要出现让人费解的数字
- 要像对待朋友一样对待你擅长的语言
- 不要逆常规而行
- 千万小心过早的优化代码
- 要常常重构经过测试的代码
- 不要沉溺于过度的设计技巧
- 随时随地学习新的知识
下面我们来对每一点详细展开介绍。
1、保持方法简短扼要
尽管很多人都遵循这条规则,但是它依然很重要。总的来说,编写的方法最好能在首屏完全显示。试想,如果你需要滚动页面才能看到整一个方法,那是 一件多么分散注意力的事情。一个方法最好能保持在 5 – 20 行之间,当然,你也要视具体情况而定,并不是一概而论的。对于 getter 和 setter 方法,通常只需一行代码,所以它们看起来更像是类成员的存取访问器。
2、永远永远不要将同一个变量用于不同的目的
一个变量应该只能被用于一个目的,我们可以通过使用常量(C++中用 const 标识,Java 中用 final 标识),帮助编译器优化代码编译,也可以向程序标识“这个变量是不能被改变的”,这样我们编写的代码就有更好的可读性。
3、尽可能让变量和方法的名称能够描述要实现的功能
一段通俗易懂的程序代码,应该是任何人只要看了代码,就能明白程序是用来干嘛的。所以我建议大家尽量少用缩写,除非是程序界公认的简写习惯,像下面的简写习惯:
src - source pos - position prev - previous
如果你觉得描述性的简写方式没有价值,你可以比较一下n, ns, nsisd 和 numTeamMembers, seatCount, numSeatsInStadium
4、尽可能将变量定义在最靠近它们的地方
当你在盖房子的时候,总不希望把锤子放在别人家的院子里吧,相反,你会把盖房的工具放得尽可能近,定义变量也是同样的道理。
int foo = 3; int bar = 5; // bunch of code that uses "bar" // but doesn't care about "foo" // ... baz (foo);
我们可以这样重构代码:
int bar = 5; // bunch of code that use "bar" // but doesn't care about "foo" // ... int foo = 3; baz (foo);
当你把变量的声明跟使用它的地方相隔太远的时候(甚至是超过一屏),那的确会给你带来很大的麻烦。你会经常滚动页面去寻找这个变量,导致你很难在大脑中保持代码之间的连贯性。
5、不要出现让人费解的数字
任何时候,你要比较一些常量时,都要将它们定义成 constant 类型。团队之间调试代码时最让人头疼是出现下面的代码:
il < 4384
把它替换成下面的代码该多好:
inputLength < MAX_INPUT_LENGTH
6、要像对待朋友一样对待你擅长的语言
学习一种新的编程语言是一件很有趣的事情,从中你可以用很酷的方式学到新东西。还有就是让一个对某种语言很专业的人去学另外一种语言,很多时候 会让人心有余而力不足。举个例子,你让一个 Java 大牛去学 Ruby,他应该会用 Ruby 的方式去解决问题,而不是继续沿用 Java 的解决问题的思想。
当你需要循环输出 5 遍”Hello World“时,Java 代码应该会是这样:
for (int i = 0; i < 5; i++) { System.out.println ("Hello world!"); }
但是用 Ruby,你也许会这样写:
for i in (0..5) puts "Hello world!" end
这些看上去都很不错,但是最完美的方式可能是下面这样:
5.times { puts "Hello world!" }
7、不要逆常规而行
每一种编程语言都有自己的约束习惯,总的来说,大家对 Java 的编程习惯可能会了解得比较多,我们一起来看看其中的一些习惯:
- 方法名以小写字母开头,后面紧跟的是大写字母开头的单词,比如 veryLongVariableName。
- 类名一般都是大写字母开头的单词组合。
- 常量的命名都是大写字母的单词,之间用下划线隔开,比如 MY_CONSTANT
- 左大括号应该跟 if 在同一行
只有在迫不得已的时候才能打破这种规则,千万不要因为不喜欢这种做法而违背已经约定好的编码习俗。如果你身为团队一员,想改变一些编码规则的话,那也可以,不过当你把自己的代码分享给没有你这种习惯的队友的时候,棘手的问题会迎面而来。
8、千万小心过早的优化代码
过早的优化是所有问题的根源,至少电视上是这么说的…你的首要任务是编写容易理解的代码,而不要求你能很快写出来。除非你的程序运行很慢,否则谈优化都是为时太早。如果你想优化你的程序,那么得先找出程序的问题,这就是我们需要 profilers 这个工具的原因。
在没有找到问题源头就去优化代码,这样做你所要付出的代价就是破坏了程序的结构,至少会丧失程序的可读性。如果你发现程序运行缓慢了,也不要盲目地重构代码,要先找到导致运行慢的根本原因。
千万不要傻乎乎地去解决根本不存在的问题。
9、要常常重构经过测试的代码
世上没有绝对完美的事情。尽管你认为自己的代码已经写得非常完美了,过一段时间也要经常去看看它,也许那时你会对自己大骂:”怎么会那么傻!”
有一种提高代码质量的方法,那就是经常重构通过测试的代码。所谓通过测试,我指的是程序要能正常工作,你可以通过自动化测试或者手动测试来确保这一点。
首先你要确保程序能够正常运行,第一次我们并不需要写出多么完美的程序,能用就行,接下来我们可以慢慢重构,让它逐渐变得完美。这种开发方式很 有 TDD 的味道,关键在于你需要熟悉重构的每一个环节。如果你熟练使用一些高级的 IDE,像 IntelliJ IDEA,那你的重构工作将会简单很多。
重构完以后,也许你会碰到很多这样那样的问题,甚至会破坏正常的程序,这就是我们要利用自动化测试的原因了。当你重构完以后,跑一遍单元测试就能避免这些令人头疼的问题了。
10、不要沉溺于过度的设计技巧
当我第一次接触到设计模式这一概念时,我觉得自己找到了“圣杯”。这些精妙的设计思想可以让你工作更加顺利,也可以让你的设计浅显易懂,因为你 可以简单的说“我使用了观察者模式”,而不同大费周章的解释一通。然而问题来了,由于有些问题看起来太自然太简单了,你会把那些设计模式的思想应用到任何 地方,为什么不把这个类设计成单例模式(singleton)?干嘛不去创建一些工厂类呢?
于是用 80 行代码就能完成的脚本,结果你用了 10 个类,15 个接口和一堆泛型和注释,这其中的 97% 代码并没有做实质上的事情。设计模式虽然非常有用,可以帮助你简化设计,但是这并不是说你可以到处使用它们。你可以使用设计模式,但是不能将它滥用了。
11、随时随地学习新的知识
编程就是一项随时学习新事物的工作,当你学到了新的类库或者编程语言时,你会迫不及待地丢掉老的代码,进而去重写它们。然而有很多理由说明你不该这么做。
将一个新的类库或者框架应用到现有的项目中就会出现类似的问题。比如说你正在为一个 Web 项目写 Javascript,但是中间你发现了 jQuery,这时候你会迫不及待想把 jQuery 应用进去,而丢掉原来的 Javascript 代码,即便你根本没用 jQuery 写过任何项目。
最好的方式是你先用 jQuery 学着写一些简单的例子,把你项目中要用到的技术都学会。比如说你想要用 AJAX?就先在项目之外写一些关于 AJAX 的简单例子,等到完全掌握了,就可以将老代码从项目中移除。
如果你热衷于编程,我强烈推荐你阅读 Steve McConnell 编写的《Code Complete》,它将永远改变你的编程思维。
译文链接:http://www.html5tricks.com/11-tips-to-coding-better.html
翻译作者:蒋丽丽