如何编写更棒的代码:11个核心要点

本文作者html5tricks,转载请注明出处

本文是html5tricks原创翻译,转载请看清文末的转载要求,谢谢合作!

作为一个合格的程序员,有太多的理由促使你去编写干净利落且可读性强的代码。最重要的是因为你编写的代码,将来会有很多人一次次地阅读。当你有一天回过头来看自己的代码时,你就会明白编写优雅的代码是多么的重要。另外,如果别人来阅读你编写的代码,你是否想知道别人看到那些烂代码无比抓狂的感受。因此,花多一点的时间去编写优雅的代码,将来说不定会给你节省更多的时间。

那么,如何编写更棒的代码,下面是11条基本规则:

  1. 保持方法简短扼要
  2. 永远永远不要将同一个变量用于不同的目的
  3. 尽可能让变量和方法的名称能够描述要实现的功能
  4. 尽可能将变量定义在最靠近它们的地方
  5. 不要出现让人费解的数字
  6. 要像对待朋友一样对待你擅长的语言
  7. 不要逆常规而行
  8. 千万小心过早的优化代码
  9. 要常常重构经过测试的代码
  10. 不要沉溺于过度的设计技巧
  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的编程习惯可能会了解得比较多,我们一起来看看其中的一些习惯:

  1. 方法名以小写字母开头,后面紧跟的是大写字母开头的单词,比如veryLongVariableName。
  2. 类名一般都是大写字母开头的单词组合。
  3. 常量的命名都是大写字母的单词,之间用下划线隔开,比如MY_CONSTANT
  4. 左大括号应该跟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》,它将永远改变你的编程思维。

译文链接:https://www.html5tricks.com/11-tips-to-coding-better.html
英文原文:11 tips for better code
翻译作者:蒋丽丽
转载必须在正文中标注并保留原文链接、译文链接和译者等信息。]

扫描下方二维码关注公众号

发送消息 jymm 获取 解压密码

分享HTML5/CSS3技术;jQuery插件;Vue、React等前端开发组件

热门推荐

如何编写更棒的代码:11个核心要点》上有10条评论

  1. 编码者

    第10点深有感触,总是想应用一些优秀的设计模式,最后弄得不伦不类,说到底还是功力不够啊

    回复
      1. 柚子皮870

        看着不舒服,看了下原文是:Be friend with your languageLearning new language is always fun, you can learn to do things in new cool way. There is one big downside of being pro in one language while learning other one though. Say you’re Java developer trying to learn Ruby. You should learn how to do things the Ruby way, instead of trying to apply your skill in doing things the same way you’d do them in Java.这段说的应该是和“你在学的新语言”做朋友,而不是“擅长的语言”,用ruby风格写ruby代码,不要把自己擅长语言的风格带入。比如python的pythonic,要去了解每个语言自己的准则,哲学。还有几处觉得欠妥 you can learn to do things in new cool way.你会学到用新的很酷的方式解决问题You should learn how to do things the Ruby way,你应该学着用ruby的方式解决问题第11条: Learn new things by prototyping是说通过写一些简单的例子的方式来学习新东西,不要直接在生产环境下使用自己还不熟悉的新技术,跟“随时随地”完全没有关系

        回复
  2. anthony

    译者明显不是程序员。第一条,“保持方法简短扼要”,简短是对的,扼要就是脑补了。程序不是文字,不能只写要点,每一个细节都要清清楚楚的写下来,绝对不能摘要,概述。“编写的方法最好能在首屏完全显示”,这里有两个错。”编写的方法“,原文英文用复数表示一类事物,中文用单数,即”一个方法“,当然如果你知道方法就是函数,也可以改用函数。”编写的“不知道从哪里来?另一个错是“首屏”,这个没有首尾?此句应为“一个方法(的长度)应该与屏幕相称。后面的没有看了,读原文去了。P.S.原文写得也挺差。

    回复
      1. anthony

        居然又推送给我了,看看是不是“咬文嚼字”第二条.reuse a variable没译出来。此条的第二句,making variable constant,不是“我们可以通过使用常量”吧。最后一句:make your code scream This variable is not going to change, 不是“也可以向程序标识“这个变量是不能被改变的”。第三条,标题不知道为什么这么修改,原文是”Use self-descriptive variable and method names“。第四条,”their first usage”没了。第五条,让人费解的数字”No magic numbers“,意思对,不过这是术语。“Whenever you compare something against constant value, it should be defined as constant”,两个constant分别是,常量值(文字值)和常量。第六条,Be friend with your language,不是对待朋友,而是与之做朋友。这条的意思是按语言本身的方式做事(友好的方式),不是按自己习惯的方式(粗暴的方式)。第七条,Conventions就是编程规范。按本文的译法,这段的意思都不对了。第八条,premature optimization是术语,不成熟的优化。不是过早。这里没有早晚,是说优化三要素:有必须解决的性能问题,明确的瓶颈和有效的解决方案。第九条,Always refactor the code after you test it,根本不是你说的意思,而是”只重构通过了测试的代码。”特别提醒读者,常常重构从来不是一个优秀的实践,重构可以主要是为了代替重写,不是得到优秀代码的正确方法。正确的做法是,一次性写好,需求变更时重构,没事别动它。第十条,overengineering叫作”过度设计“。最后有一句话,“Design patterns are very useful tool to simplify the design, which doesn’t mean using them everywhere you can. ” 设计模式是简化设计的实用工具,不应把它们用到所有能用的地方(,从而导致过度复杂的设计”。第十一条,prototyping是原型,称为“例子”“实例”可能不能表达“构造接近设计目标的模型”这样的含义。本条是说不要在产品中尝试新技术,而是构造原型,再移入产品代码。这句话其实译错了“Try it on simple example outside the project and after you fully understand it, throw it away and move into production.”应该是“在项目之外,用简单的代码尝试它,当你(确实)明白了,抛弃(项目外的)代码,把(这些代码)移到产品中去。针对原文的评论,这11条其实不是一个层面,并列在一起本身就不合适,只能说是有用,但不全面也不系统,code complete明显系统而全面,本文可以看成是code complete的读书笔记。

        回复

发表评论

电子邮件地址不会被公开。 必填项已用*标注

您可以使用这些HTML标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>