一、Google: 如何做code review

本文的名词解释：

如果嫌文章太长，可以直接拖到文章后看总结

cr的标准

cr(Code review)主要目的在于确保Google的代码库代码质量越来越好。而所有相关的工具与流程皆是因应这个目的而生。为达到此目的，势必需要做出一连串的权衡与取舍。

首先，开发人员必须能够在自己负责的任务上有所进展。如果你从来没有向代码库提交改进过的代码，那么代码库就永远不会改进。另外，如果一个reviewer使cr都很难进行的话，那么开发人员就不愿意在将来进行改进。

另一方面，reviewer有责任确保每个change list（下称CL）的质量，保证其代码库的整体代码质量不会越来越差。这可能很棘手，因为通常会随着时间的推移，代码需要降级才能让代码运行起来，特别是当团队受到严重的时间限制时，大家觉得必须走捷径才能实现他们的目标。

此外，reviewer对他们正在review的代码拥有所有权和责任。他们希望确保代码保持一致、可维护，以及下文的“在cr中可以得到什么”中提到的内容。

因此，我们有以下规则，作为我们在cr中所期望的标准：

一般来说，当CL存在的时候，reviewer应该赞成它，此时它肯定会提高正在工作的系统的整体代码质量，即使这个CL并不完美。这是所有cr中的首要原则。当然，这是有局限性的。例如，如果一个CL添加了一个reviewer不希望在其系统中使用的功能，那么reviewer当然可以拒绝，即使代码设计得很好。

这里的一个关键点是，没有“完美”的代码，只有更好的代码。reviewer不应该要求作者在approve之前对一篇文章的每一小段进行润色。相反，reviewer应该权衡发展的需要和他们所建议的change的重要性。reviewer不应追求完美，而应追求持续改进。作为一个整体，提高系统的可维护性、可读性和可理解性的CL不应该因为它不是“完美的”而被延迟几天或几周。

reviewer应该随时可以留下评论，表达一些更好的东西，但如果不是很重要，可以在评论前加上“nit:”这样的前缀，让作者知道这只是一个他们可以选择忽略的修饰点。

cr有一个重要的功能，教开发人员一些关于语言、框架或一般软件设计原则的新知识。留下有助于开发人员学习新知识的评论是可以的。随着时间的推移，共享知识是提高系统代码健康度的一部分。你只需要记住，如果你的评论纯粹是教育性的，但对达到本文档中描述的标准并不重要，请在其前面加上“nit:”，或者以其他方式表明作者不必在本CL中解决它。

现实和数据推翻了个人喜好。在代码风格方面，风格指南（style guide）是绝对的权威。任何不在style guide中的一些点（如空格等）都是个人偏好的问题。代码风格应该与现有的一致。如果项目没有以前的统一风格，那就接受作者的风格。

软件设计的各个方面从来都不仅仅是一个纯粹的代码风格问题或者是个人喜好问题。它们是以基本原则为基础的，应当以这些原则为依据，而不仅仅是以个人意见为依据，有时几乎都没有选择的。如果作者能够证明（通过数据或基于原理的一些事实）他的方法是同样有效的，那么reviewer应该接受作者的偏好。否则，代码风格选择取决于软件设计的标准原则。

如果没有其他规则适用，那么reviewer可以要求作者与当前代码库中的内容保持一致，只要这些代码不会恶化系统的整体代码健康状况。

在cr的任何冲突中，第一步应该始终是开发人员和reviewer根据本文和《CL Author’s Guide》，尝试达成共识。

当达成共识变得特别困难时，reviewer和作者需要进行面对面会议，而不是仅仅试图通过cr的注释来解决冲突（不过，如果这样做，请确保将讨论结果记录在CL的评论中，以供将来的读者阅读）。

如果这不能解决问题，常见的解决方法就是升级。通常情况下，升级的途径是进行更广泛的团队讨论，让team leader参与进来，请求代码维护人员做出决定，或者请求技术经理提供帮助。不要因为作者和审稿人不能达成一致意见而让一个其他人袖手旁观。

在cr中要看些什么

注意：在考虑每一点时，一定要考虑cr的标准。

在cr中重要的是看CL的总体设计。CL中不同代码段的交互是否有意义？此更改属于你的业务代码库还是属于引进来的其他代码库？它是否与系统的其他部分很好地集成？现在是添加此功能的合适时机吗？

这个CL做了开发者想要的吗？开发者对这些代码的设计初衷用户有好处吗？“用户”通常既是终用户（当他们受到更改的影响时）又是开发人员（他们将来必须“使用”此代码）。

大多数情况下，我们希望开发人员在进行cr时能够对CL进行充分的测试，使其能够正常工作。但是，作为reviewer，仍然应该考虑边缘状况，寻找问题，尝试像用户一样思考，并确保仅通过阅读代码就不会看到错误。

如果你愿意的话，你可以自己去验证CL。如果改动会直接带来的用户可见的影响，比如说ui改动，验证CL的变化是非常关键的。

在阅读代码时，很难理解某些更改会对用户产生怎样的影响。对于这样的更改，如果不方便自己测试，则可以让开发人员演示该功能(demo)。

另外，在cr期间考虑功能性特别重要的点是，cl中是否并发式编程，理论上可能导致死锁或竞争条件。这些类型的问题很难通过运行代码来发现，通常需要有人（开发人员和reviewer）仔细考虑，以确保不会引入问题（注意，这也是不使用平行式编程的一个很好的理由，在这种情况下，可能出现竞争条件或死锁，这会使代码检查或理解代码变得非常复杂）。

一个CL是否复杂到超过预期的必须？针对任何层级的CL必须确认这几点：单行代码是否过于复杂？函数是否过于复杂？class是否过于复杂？“复杂”通常意味着该代码很难阅读，很有可能也意味着其他开发者在修改这段代码的时候引入其他bug。

其中一种复杂性就是过度设计(Over-engineering)造成的，开发者会让那段代码过度通用化，超过了原本所需，或者还新增了系统目前不需要的功能。reviewer应特别注意一下过度设计。鼓励开发者解决他们知道现在需要解决的问题，而不是推测将来可能需要解决的问题。当那些将来出现的问题出现的时候才开始解决它们，因为那时候你可以更加清晰看见问题的原样子。

请将单元测试、整合测试、端到端测试视为要求CL所做的适当变更。一般CL内除了生产环境的业务代码外，测试也应该要被加入其中。除非该CL是为了处理某个紧急事情而存在。

另外，也要确保测试是正确、合理、有用的。测试并非来测试它们本身，一般也极少为了测试而测试（如测试一下测试代码有没有问题又走了测试流程），因此我们要保证测试是有效的。

当代码真的有问题，测试是否会失败？如果被测试的程序发生改动时，测试是否会产生误报？每一个测试是否做出了简单而有用的断言？不同的测试方法之间的测试是否适当分开？

命名

开发者是否为了每一个东西都挑了一个适当的名字？一个好的命名意味着，通过名字就足以完整表达该东西的作用是什么或者要做什么。但是同时名字也不要长得难以阅读。

推荐参考文章：Clean code 101— Meaningful names and functions

注释

开发者是否用可理解的英文留下清晰的注释?这些注释是否真的必要?

通常注释是解析这段代码为什么存在的时候是相当有用的，而不应该去解释某段代码正在做什么。如果代码本身不能解释清楚的话，意味着它更加需要简化了。当然也有例外，比如解释正规的表达式或者复杂的算**在做什么的时候，注释解释这段代码正在做什么就相当有用。但对于大部分注释来说是用来说明那些不包含在程序本身但资讯，比如说为什么要这样子做的理由。

查看该CL之前的注释也很有帮助，或许有一个todo项目现在可以一处、一个评论建议为什么不要进行这种更改等等。

要注意的是，注释与class、module、function的文件不同。后三者要能够表达一段代码的目的、如何使用它、使用时行为。

Google对于主要语言都有提供风格指南（style guide），甚至包括大多数冷门语言，因此要确保CL遵循适当的指南上的说明。

如果你想改进CL中某些不包含在风格指南中的要点时，请在评论前加上Nit:，让开发人员知道这是你认为可以改善代码的小问题且并非强制性的。但记住，不要仅根据个人风格偏好阻止提交CL。

开发者不应该在 CL内同时包含主要风格的改动与其他代码的修改，这样会导致难以看出CL到底做出什么改动。同时也会让合并和回滚更为复杂，并产生其他问题。例如，如果作者想要重新格式化代码的话，让他们将新格式在一个新CL里面重构。

如果CL更改了构建、测试、交互、发布的时候，请检查是否也同时更新相关文档，包括README，g3doc页面和其他生成(generated)的参考文件。如果CL删除或弃用了一些代码，请考虑是否应该删除对应文档，如果缺少文档时请询问。

仔细review分配给你的每一行代码。有些东西，比如资料文件(data files)、生成的代码(generated code)、大型数据结构(large data structures)，你可以稍微扫过。千万不要在扫过开发者写的 class、函数、代码区块时，去假设它内部是没问题的。很显然的某些代码需要比其他代码更仔细的review。这是必须由你做出的判断，但至少你应该确定你理解所有代码在做些什么。

如果阅读代码过于复杂并且减慢review速度时，那么你再继续review前，要让开发者知道这件事，并等待他们为这段代码做出解释、说清楚。在Google我们聘请许多优秀的软件工程师，而你也是其中的一员。如果连你也无法理解的话，很可能其他人也不会。因此，你要求开发者去说清楚这段代码时，同时也在帮助未来的开发人员理解这些代码。

如果你能够理解，但觉得没有资格进行某部分的审核，请确保 reviewer中有一个适合(合格)的人来review该部分。尤其是针对安全性、并发性、可访问性、国际化等复杂问题时。

在充足的上下文下查看CL通常很有帮助。一般来说，cr工具只会显示修改部分周围的几行代码而已。但有时你必须查看整个文件以确保改动是否合理。比方说，你可能只看到添加4行新代码，但实际上查看整个文件时会发现这4行是被加在有50行的代码里，此时需要将它拆解为更小的函数。

以整个系统的角度出发来思考CL也是很有用的。该CL是否改善整体系统的代码质量，亦或是会让整个系统更加复杂？是否缺少测试？千万不要接受会降低整体系统的代码质量的CL。因为大多数系统是由于许多小改动的积累而变得复杂，因此阻止新的改动引入复杂性(尽管很小)也非常重要。

个人认为并非不要指出错误，而是多以鼓励来代替指出错误，让其他开发者更有动力想将事情做好。其实透过简单的一句话让对方知道哪里做得很好，未来他们会将继续保持下去，并为其他开发者带来的正面影响。

标明每个commit修改什么，帮助reviewer快速了解情况

此时就不要吝啬你的称赞了!

在cr时，请务必确保：

如何浏览CL

现在你已经知道review时要看些什么，但怎样才是review分散在多个文件中的改动有效的方法？

该改动是否有意义、合理？如果在第一时间认为不应该发生这种变化，请立即说明为什么不该这样做的原因。当拒绝类似这样的更改时，向开发人员提供建议告诉他们应该怎么做什么也是一个好主意。

例如，你可以说：“看起来你已经完成一些不错的事情，谢谢!但我们实际上正朝着删除你正在修改的FooWidget系统的方向前进，所以现阶段我们不想对它进行任何新的修改。不如重构我们的新BarWidget class如何？”

需要注意的是，reviewer在委婉拒绝该CL的同时也要提供替代方案，而且仍然保持礼貌。这种礼貌是很重要，因为我们希望表明即使不同意也会相互保持尊重。

如果你有几个CL里包含你不想这样做的改动时，你应该重新考虑开发团队的开发过程，或发布开发流程给外部贡献者知道，以便在任何CL被撰写前有更多的沟通。好是在他们开始投入前说“不”，避免那些已经投入心血的工作现在必须被抛弃或彻底重写。

提供替代方案让对方知道该怎么做，而非让其自行独自摸索。

指出问题，告知替代方案或指点方向

找到CL核心的部分的那些文件。通常CL内会有文件包含大量的逻辑改动，而它正是CL的主要部分。因此我们要首先查看这些主要部分。这有助于为CL的其他较小部分提供适当上下文，而且这样通常可以提高review速度。如果CL太大导致于无法确定哪里是主要部分时，请向开发者询问首先应当查看的内容，或者要求他们将CL拆分为多个CL。

如果在主要部分发现存在一些主要的设计问题时，即使没有时间立即查看CL的其余部分，也应立即留下评论告知此问题。因为事实上，因为该设计问题足够严重的话，继续review其他部分的代码可能只是浪费时间，因为其他正在审查的其他代码可能都将无关紧或消失。

立刻发送关于主要设计的评论非常重要有两个主要原因：

一旦确认整个CL没有重大的设计问题时，试着找出一个有逻辑顺序来review剩余档案，并确保不会错过其中任何一个。通常在浏览主要部分后，简单的方式是按照cr工具提供的顺序来浏览每个文件。有时在阅读主要代码前先阅读测试也是非常有帮助的，如此一来你就可以了解应该做、看些什么。

在Google我们优化开发团队共同生产产品的速度，而不是优化个人开发的速度。个人的开发速度很重要，但它不如整个团队的开发速度重要。当cr很慢时，会发生以下几件事：

如果你并没有处于需要专注工作的时候，那么你应该在CL被提交后尽快进行review。review回复长的极限是一个工作日。若遵循以上指南，意味着一般的CL应该在一天内得到多轮review(如果必要的话)。

但有时候个人的速度优先度会胜过团队速度。如果你处于需要专注工作的时候(比方说写代码)，不要打断自己去做cr。

研究证实，若开发者在被打断后会需要很长时间才能恢复到原本顺畅的开发流程。因此，开发的时候，打断自己实际上会比让另一位开发者等待review来得更加昂贵。

取而代之的是，我们可以在投入到处理他人给的review评论之前，找个适当的时机点来进行cr。这有可能是当你的当前开发任务完成后、午餐、刚从会议脱身或从微型厨房回来等等。

总的来说个人回应评论的速度，比起让整个cr过程快速结束来得更为重要。即使有时需要很长时间才能完成整个流程，但若在整个过程中能快速获得来自reviewer的回应，这将会大大减轻开发人员对于缓慢的cr过程的挫败感。

如果真的忙到难以抽身而无法对CL进行全面review时，你依然可以快速的回应让开发者知道你什么时候会开始审核、建议其他能够更快回复reviewer，又或者提供一些初步的广泛评论。(注意:这并不意味着你应该中断开发去回复——请找到适当的中断时间点去做)。

很重要的是，reviewer员要花足够的时间来进行review，确保他们给出的LGTM，意味着“此代码符合我们的标准”。

尽管如此，理想的个人的回应速度还是越快越好。

在面对时区不同的问题时，尽量在他们还在办公室时回复作者。如果他们已经回家了，那么请确保在他们第二天回到办公室前完成。

为加快速度，在某些情况下reviewer可以给予LGTM或Approval，即便CL上仍有未解决的评论。类似情况会发生在：

LGTM评论对双方处于不同的时区时尤其值得考虑，否则开发人员会等待一整天才得到“LGTM，Approval”。

如果有人要求reivew时，但由于改动过于庞大导致你难以确定何时才有时间review它时，你通常该做的是要求开发人员将CL拆解成多个较小的CL，而不是一次review巨大的CL。这种事是可能发生的，而且对于reviewer非常有帮助，即便它需要开发人员付出额外人力来处理。

如果CL无法分解为较小的CL，且你没有足够时间快速查看整个CL内容时，那么至少对它的整体设计写些评论，并发送回开发人员以便进行改进。身为reviewer，你的目标之一是在不牺牲代码质量的状况下，避免阻挡开发人员进度，或让他们能够快速采取其他更进一步的动作。

如果你遵循这些准则，并且对于cr非常严格的话，后面你会发现整个cr流程会越来越快。因为开发者学到什么是质量好的代码，并于开头就提交一个很棒的CL，而这正恰好只需要越来越少的时间。而reviewer则学会快速回应，而非在过程中加入不必要的延期。

但不要为提高想象中的速度，而对cr标准和代码质量做出妥协，毕竟从长远来看它实际上并不会让任何事情发生得更快。

在某些紧急情况下，CL会希望放宽标准以求迅速地通过整个cr过程。但请看什么是紧急情况来知道哪些情况实际上属于紧急情况，而哪些不符合。

有时开发人员会推迟处理cr产生的评论。要么他们不同意你的建议，要么他们会抱怨你太严格了。

当开发人员不同意你的建议时，请先花点时间考虑一下他们是否是正确的。因为通常他们比你更了解代码，所以他们可能真的比起你来说对代码的某些层面具有更好的洞察力。他们的论点有意义吗？从代码质量的角度来看它是否合理？如果是的话，让他们知道他们是对的，然后让问题沉下去。

但开发人员也并不总是对的。在这种情况下，reviewer应该更进一步解释为什么认为自己的建议是正确的。一个好的解释通常展示了“对开发人员的回覆的理解”以及有关“为什么被要求做出改动”等信息。尤其是当reviewer认为给出的建议会改善代码质量时，便应该继续宣扬自己的论点。只要他们相信所需的额外的工作量终会改善整体代码质量。提高整体代码质量这件事，往往是经由每个微小的改动来发生。有时往往需要几番解释一个建议才能让对方真正理解你的用意。切记，始终保持礼貌，让开发人员知道你有听到他们在说什么，只是你不同意该论点而已。

reviewer有时会认为若自己坚持改进的话，会让开发人员觉得沮丧不安。的确开发人员有时会感到很沮丧，但这通常是十分短暂的，甚至后来他们非常感谢你帮助他们提高代码质量。一般来说，只要你在评论中表现得很有礼貌，开发人员实际上根本不会感到沮丧，这些担忧都仅存在于reviewer心中而已。沮丧很多时候是对于cr评论的写作方式有关，而并非来自reviewer对于代码质量的坚持。

一个常见的推迟原因是开发人员希望完成任务(这可以理解)。他们不想通过另一轮cr来批准这个CL。此时他们通常会说在以后的CL进行整理，所以你现在应该要给LGTM。当然部分开发人员非常擅长这一点，并且立即送出一个修复问题的后续CL(follow-up CL)，但根据过往经验，这种后续“清理行为”非常少见。除非开发者在CL获得批准之后立刻进行清理动作，否则这事根本不可能发生。这不是因为开发人员不负责任，而是因为他们可能有很多其他工作要完成，于是清理工作便会在成堆的工作中被遗忘。因此，通常好坚持开发人员在代码在合并后清理它们。因为让人们「稍后清理」是致使代码库质量状况下降常见的状况。

如果CL引入了新的复杂性的话，除非是紧急情况，否则必须在提交之前将其处理掉。如果CL导致暴露周围的问题且现在无法解决它们的话，开发人员应该将缺陷记录下来并分配给自己，避免后续被遗忘。又或者他们可以选择在代码中留下TODO的注释并链接到刚记录下的缺陷。

如果你先前以相当宽松的标准并转趋严格的进行cr的话，一些开发人员会开始大声地抱怨。一般来说，提高review的速度会让这些抱怨逐渐消失。这些抱怨可能需要数个月才会消失，但终开发人员会看到严格的review所带来的价值，因为严格的review帮助他们产生的优秀代码。而且一旦发生某些事情时，大声的**者甚至可能会成为你坚定的支持者，因为他们会看到变得review变严格后所带来的价值。

如果你遵循前面所有*作，但仍然遇到无法解决的双方之间的冲突时，请参考前面的cr的标准以获取有助于解决冲突的准则和原则。

二、Google推出的所有软件

Google这个公司现在已经是“家大业大”了，他们总是隔三岔五地推出一些新鲜的服务，让业界跟着也兴奋一把。不过历年来Google所发展出来的服务和软件实在太多了，究竟他们已经有了什么服务？现在就来看看吧。

Add to Google

这是一个提供网页信息的站点，主要的功能是把自己的主页介绍给Google让他收录，而时间上较长，起码一两个月才会被Google收录，但是一旦收了你的主页，知名度会更快地上升。

Blogger

Google提供的Blog服务，现在已经有中文版本了，大家可以上去安个家，把地址写到本文评论让大家去浏览。

Froogle

这是一个专业的引擎，可以输入你想要购买的东西，然后得到符合关键词的结果出来，可以比较一下各个购物网站不同的价格，挑选合适的地方进行购买。

Gmail

Gmail是是Google提供的当前流行的免费邮件服务，提供了超过2GB的储存空间。

Google AdSense

Google提供的广告服务，你是否遇到有不知来源的IP经常**点击你的广告，而你无法知道IP所以无法禁止，你是否想知道你的广告在哪个或者哪些页面点击率高，而又不受渠道数量的限制，它主要针对Google Adsense的规则，在不违反规则的前提下为用户提供及时详细的广告点击统计信息。

Google AdWords

Google提供给商家的特殊广告站点，只要有人点击这里就会按一定规则向商家收费，算是网络上的分类广告。

Google Alerts

这是一个新闻定制站点，可以通过邮箱定制你需要的内容，然后得到相关的讯息。

Google Analytics

Google推出的免费提供的网站统计服务，只需要简单注册，即可帮助站长分析自己的站点情况，而且里面的内容非常详细，不光小网站有用，大网站更是可以作为一个参考的指标。

Google Answers

Google的问答站点，可以回答你很多不知道的问题，类似的还有百度出的百度知道，现在这个站点开始进入收费模式，你可以悬赏进行问题答案的购买。

Google Base

这个服务相对于Google其它服务的专业化，或许显得比较杂*，里面也是可以让我们提交不同的信息给Google，让它出现在Google的搜索里面。

Google Blog Search

这是一个针对Google博客的搜索服务，专门收集其中的海量信息。

Google Book Search

Google的书籍搜索服务，其实也是Google引擎的一个小延伸而已，不过在这里搜索到的结果比较专业和集中。

Google Bookmarks

Google的**网络书签服务，整合了Google工具条4.0和Google搜索历史，此服务还处于beta测试阶段，目前看到的Google Bookmarks还没有共享功能，类似个人网上收藏夹。

Google Calendar

Google的日历服务，可以很方便地管理自己生活上的行程安排，例如参加会议的时间、看病的预约时间、约会时间、吃饭订餐时间等等。可以将一个人的所有行程都管理起来。

Google Catalogs

Google做的邮购搜索服务，对于国人来说好象用处并不是特别地大。

Google Code

Google用来推广及发展开源软件的一个服务，一个适合程序员的源代码公开站点。

Google Code Search

Google代码搜索可以用来搜索各种函数的定义以及相关的示例代码，还可以直接使用普通的表达式搜索以获得更精确的结果。

Google Compute

Google的网格计算，可以将一些超大规模的计算量分散到全球不同国家地区的电脑上，以尽快得到结果，这是些有益全球的计算，希望有电脑的朋友都参加。

Google Desktop

这是一个放置在桌面上的工具条，在这个工具条里可提供新闻，天气，Email等小程序，了解新的信息。

Google Directory

Goolge制作的超大型人工分类目录，让网页根据重要性来排列。目录搜索服务可满足那些想要浏览某特定主题下相关信息的用户。

Google Earth

这项服务提供了地球上大部分地区的卫星图片查询，尤其是大城市的图片更加地多，让你如宇航员一般身临其境，足不出户也可了解世界各地。

Google Groups

Google提供的群组服务。利用它你可以创建邮件列表、阅读新闻或者是和志同道合的用户分享你感兴趣的东西。

Google Homepage

是Google提供的主页服务，你可以定制它，它提供了天气、新闻、占卜等各种各样的服务。

Google Image Search

Google的图片搜索，几乎是Google早的服务了，这是它的图片搜索页面，相信大家都用过吧，图片搜索的精确度还是不错的。

Google Labs

Google实验室的一些服务链接，从这里可以看到它们又有什么天才的发明。

Google Local

Google本地搜索，通过这一服务，用户可以使用关键字搜索在特定的城市查找某一类型的公司，并在电子地图上显示这些公司的具**置。这项服务现在有了中国版本。

Google Maps

Google地图搜索服务，让你浏览到世界各地的地图、公路等信息，比较上面提到的卫星地图来说，比较传统。

Google Mo**le

Google手机上网用户的服务，只要手机能连上这外网站，即可象用PC一样搜索图片、关键字等信息。

Google Movie Showtimes

Google提供的电影上映时间搜索服务，只要输入一个地方的邮政编码或地址，就可以搜索到当地的电**及电影的上映时间。

Google News

Google新闻站点，将新的新闻呈现在大家的眼前，上面的所有新闻都是由Google特定的电脑自动聚合的。

Google Notebook

类似一个网摘工具，以插件的形式安装于浏览器，记录你在浏览网页时看到的有用的信息。

Google Page

Google推出的免费个人主页服务，用户可以在这里获得一个100M大小的免费主页空间。

Google Reader

Google的**RSS阅读器，Reader依靠RSS和Atom技术，可帮助用户及时获得信息，用户不必自己检查更新喜欢的站点，Google Reader可以帮你。

Google Ridefinder

美国12个城市的公交车和出租车的相关搜索。

Google Scholar

学术文章搜索引擎，高年级学生的必备，尤其一些经常需要撰写一些论文的朋友。

Google Send to Phone

利用网络发送手机短信的服务，感觉上没什么特别。

Google Sitemap

Google的Sitemaps计划，旨在对网站信息搜索进行加速，增强索引能力。Google称：“这种协作搜索系统将进一步提高覆盖和刷新速度，使用户使用Google索此功能实现优化。”Google呼吁网站管理员在网站服务器中放置Sitemaps格式的文件。这样，Google的搜索引擎就可以看到那些网页在网站内，那些网页内容被修改了。

Google SMS

GOOGLE SMS服务，是通过SMS查找特定信息的一项技术。它可以提供驾车服务，在无线产品中支持SMS。

Google Suggest

这是一个猜测你意图的测试站，当用户关键词搜索框中输入文字时，下拉清单将显示候补搜索单词或短语一览。还将显示找到的各单词或短语的网页数。从候补中选择单词或短语便可搜索。

Google Talk

Google推出的即时**聊天工具，当时挺火*的，业内很多人都说能跟各大即时聊天工具一拼，可是现在没多少个人用了，影响较低。

Google Toolbar

Google的搜索工具条，上面有很多实用功能，搜索、拦截弹出窗口、查看网页PR值等等一大堆。

Google Trends

Google趋势服务，可以得到人们对于不同事物的关注程度，Google通过分析全球的搜索结果，分析处某一搜索关键词在Google被搜索的频率和相关统计数据。

Google Video

这又是一个新的尝试，Google推出的视频搜索内容丰富，不过国内用户好象会受到一定的限制。

Google Web Accelerator

可以加速网页的载入，尤其是对付一些我们网络访问较慢的外国网站更是好用

Google Web Search

Google网站默认的搜索服务。

Google Webmasters

Google网站管理员中心，提供了一系列网站管理员常用的功能列表，包括“提交网站”，“Sitemaps”，“支持论坛”等等。

Hello

Hello即时聊天工具，是一个极小的即时通信客户端，它和Google的看图软件Picasa一起工作，能让你和亲人好友分享图片。

Picasa

超强的图片管理显示的软件，得益于其高效的图片管理模式，我们可将电脑里所有的图片都让它归类，分析。它现在已是免费软件，大家可以让ACDSee下岗了。

三、Google发布了哪些JS代码规范

这次给大家带来Google发布了哪些JS代码规范，使用Google发布的JS代码规范注意事项有哪些，下面就是实战案例，一起来看一下。

Google为了那些还不熟悉代码规范的人发布了一个JS代码规范。其中列出了编写简洁易懂的代码所应该做的佳实践。

代码规范并不是一种编写正确JavaScript代码的规则，而是为了保持源代码编写模式一致的一种选择。对于JavaScript语言尤其如此，因为它灵活并且约束较少，允许开发者使用许多不同的编码样式。

Google和Airbnb各自占据着当前流行的编码规范的半壁江山。如果你会在编写JS代码上投入很长时间的话，我强烈推荐你通读一遍这两家公司的编码规范。

接下来要写的是我个人认为在Google的代码规范中，与日常开发密切相关的十三条规则。

它们处理的问题都非常具有争议性，包括tab与空格、是否强制使用分号等等。还有一些令我感到惊讶的规则，往往后都改变了我编写JS代码的习惯。

对于每一条规则，我都会先给出规范的摘要，然后引用规范中的详细说明。我还会举一些适当的反例论证遵守这些规则的重要性。

使用空格代替tab除了每一行的终止符序列，ASCII水平空格符（0x20）是唯一一个可以出现在源文件中任意位置的空格字符。这也意味着，tab字符不应该被使用，以及被用来控制缩进。

规范随后指出应该使用2个，而不是4个空格带实现缩进。

// bad

function foo(){

????let name;

}

// bad

function bar(){

?let name;

}

// good

function baz(){

??let name;

}不能省略分号每个语句必须以分号结尾。不允许依赖于JS自动添加分号的功能。

尽管我不明白为什么会有人反对这个规则，但目前分号的使用问题显然已经像“空格 vs tab”这个问题一样产生了巨大的争议。而Google对此表示分号是必须的，是不可省略的。

// bad

let luke={}

let leia={}

[luke, leia].forEach(jedi=> jedi.father='vader')

// good

let luke={};

let leia={};

[luke, leia].forEach((jedi)=>{

jedi.father='vader';

});暂时不要使用ES6 module由于ES6模块的语义尚不完全确定，所以暂时不要使用，比如export和import关键字。一旦它们的相关规范制定完成，那么请忽略这一条规则。

//暂时不要编写下面的代码：

//------ lib.js------

export function square(x){

return x* x;

}

export function diag(x, y){

return sqrt(square(x)+ square(y));

}

//------ main.js------

import{ square, diag} from'lib';译者注：感觉遵守这条规范不大现实，毕竟现在已经有babel了。而且使用React时，佳实践就是使用ES6模块吧。

不推荐代码水平对齐Google的代码规范允许但不推荐对代码进行水平对齐。即使之前的代码中做了水平对齐的处理，以后也应该避免这种行为。

对代码进行水平对齐会在代码中添加若干多余的空格，这让相邻两行的字符看上去处于一条垂直线上。

// bad

{

tiny: 42,

longer: 435,

};

// good

{

tiny: 42,

longer: 435,

};杜绝var使用const或let来声明所有局部变量。如果变量不需要被重新赋值，默认应该使用const。应该拒绝使用关键字var。

我不知道是因为没有人能说服他们，还是说因为旧习难改。目前我仍能看到许多人在StackOverFlow或其他地方使用var声明变量。

// bad

var example= 42;

// good

const example= 42;优先使用箭头函数箭头函数提供了一种简洁的语法，并且避免了一些关于this指向的问题。相比较与function关键字，开发者应该优先使用箭头函数来声明函数，尤其是声明嵌套函数。

坦白说，我曾以为箭头函数的作用只在于简洁美观。但现在我发现原来它们还有更重要的作用。

// bad

[1, 2, 3].map(function(x){

const y= x+ 1;

return x* y;

});

// good

[1, 2, 3].map((x)=>{

const y= x+ 1;

return x* y;

});使用模板字符串取代连接字符串在处理多行字符串时，模板字符串比复杂的拼接字符串要表现的更出色。

// bad

function sayHi(name){

return'How are you,'+ name+'?';

}

// bad

function sayHi(name){

return ['How are you,', name,'?'].join();

}

// bad

function sayHi(name){

return `How are you,${ name}?`;

}

// good

function sayHi(name){

return `How are you,${name}?`;

}不要使用续行符分割长字符串在JS中，\也代表着续行符。Google的代码规范不允许在不管是模板字符串还是普通字符串中使用续行符。尽管ES5中允许这么做，但如果在\后跟着某些结束空白符，这种行为会导致一些错误，而这些错误在审阅代码时很难注意到。

这条规则很有趣，因为Airbnb的规范中有一条与之不相同的规则

Google推荐下面这样的写法，而Airbnb则认为应该顺其自然，不做特殊处理，该多长就多长。

// bad(建议在PC端阅读)

const longString='This is a very long string that \

far exceeds the 80 column limit. It unfortunately \

contains long stretches of spaces due to how the \

continued lines are indented.';

// good

const longString='This is a very long string that'+

'far exceeds the 80 column limit. It does not contain'+

'long stretches of spaces since the concatenated'+

'strings are cleaner.';优先使用for...of在ES6中，有3种不同的for循环。尽管每一种有它的应用场景，但Google仍推荐使用for...of。

真有趣，Google居然会特别指定一种for循环。虽然这很奇怪，但不影响我接受这一观点。

以前我认为for...in适合遍历Object，而for...of适合遍历数组。因为我喜欢这种各司其职的使用方式。

尽管Google的规范与这种使用方式相冲突，但Google对for...of的偏爱依然让我觉得十分有趣。

不要使用eval语句除非是在code loader中，否则不用使用eval或是Function(...string)结构。这个功能具有潜在的危险性，并且在CSP环境中无法起作用。

MDN中有一节专门提到不要使用eval语句。

// bad

let obj={ a: 20, b: 30};

let propName= getPropName();// returns"a" or"b"

eval('var result= obj.'+ propName);

// good

let obj={ a: 20, b: 30};

let propName= getPropName();// returns"a" or"b"

let result= obj[ propName ];// obj["a" ] is the same as obj.a常量的命名规范常量命名应该使用全大写格式，并用下划线分割

如果你确定一定以及肯定一个变量值以后不会被修改，你可以将它的名称使用全大写模式改写，暗示这是一个常量，请不要修改它的值。

遵守这条规则时需要注意的一点是，如果这个常量是一个函数，那么应该使用驼峰式命名法。

// bad

const number= 5;

// good

const NUMBER= 5;每次只声明一个变量每一个变量声明都应该只对应着一个变量。不应该出现像let a= 1,b= 2;这样的语句。

// bad

let a= 1, b= 2, c= 3;

// good

let a= 1;

let b= 2;

let c= 3;使用单引号只允许使用单引号包裹普通字符串，禁止使用双引号。如果字符串中包含单引号字符，应该使用模板字符串。

// bad

let directive="No identification of self or mission."

// bad

let saying='Say it ain\u0027t so.';

// good

let directive='No identification of self or mission.';

// good

let saying= `Say it ain't so`;总结就像我在开头所说那样，规范中没有需要强制执行的命令。尽管Google是科技巨头之一，但这份代码规范也仅仅是用来当作参考罢了。

Google是一家人才汇聚的科技公司，雇佣着出色的程序员来编写优秀的代码。能够看到这样的公司发布的代码规范是一件很有趣的事情。

如果你想要实现一种Google式的代码，那么你可以在项目中制定这些规范。但你可能并不赞成这份代码规范，这时也没有人会阻拦你舍弃其中某些规则。

我个人认为在某些场景下，Airbnb的代码规范比Google的代码规范要出色。但不管你支持哪一种，也不管你编写的是什么类型的代码，重要的是在脑海中时刻遵守着同一份代码规范。

相信看了本文案例你已经掌握了方法，更多精彩请关注Gxl网其它相关文章！

推荐阅读：

express默认日志组件morgan的详细介绍

Vue基于Nuxt.js实现服务端渲染的具体步奏