Nutty Coder

译者的话： 在一个开发团队中，很重要的一点是要遵循一个统一的风格，这样才能便于相互之间在代码上进行快速的交流和理解。反之，如果团队中的每个人只是按照自 己的个性去写属于个人风格的代码，这必然会造成项目代码的五花八门，互相之间难以沟通，整个项目的代码质量低下，BUG率攀高，软件的可维护率也极差。长 此以往，国将不国，团队将不团队，最终软件极有可能以一种极其混乱的状态收尾，这真是一个悲剧。 每一个C++程序员都有自己的编程风格，虽然大家的风格迥异，但也一定有一些共通的地方。我希望能找到一个对于C++风格的归纳和总结，这样在以后 我的工作中，对我自己，甚至对我工作的团队，当然也对于正在阅读的你，能够有一个帮助和参考。所以，我决定翻译Google的这篇C++风格参考指南。当 然，真正促使我去翻译这篇文章的原因是，我是一个C++技术和简洁代码风格的狂热追捧者。 注意，这只是一篇参考，它是Google的C++风格，你并不一定严格的遵循所有的规则，永远记住很重要的一点，风格永远跟着你的团队走。 本人能力有限，所以不一定每个地方都翻译的准确，另外一些不太好翻译的专业名词首次出现时，我会标注英文原文。 原文：Google C++ Style Guide 背景 （Background） C++是很多Google开源项目所使用的开发语言。正如每一个C++程序员所熟知的，C++有很多强大的功 能，但功能强大也同时意味着复杂性(complexity)，使得代码bug率更高且难以阅读和维护。 这篇参考指南 (guide)的目的在于，通过详细描述应该做的(dos)和不应该做的(don’ts)，来控制我们撰写C++代码时的复杂性。这些规则令程序员在高效 利用C++语言特性的同时，还能让手工写出的所有代码(code base)易于管理。 风格(style)，或者可 读性(readability)，我们把它称作为“用来管理我们C++代码的常用惯例(convention)”。不过用“风格”这个术语有些不当，因为 这些惯例并不只是指代码源文件的格式。 让代码可管理，一种方式是加强代码的一致性(consistency)。令任何一个程序员能够快速的理解另一个程序员所写的代码是非常重要的。如果 代码保持统一的风格并且遵循惯例，我们可以更加轻松的使用“模式匹配”(pattern- matching)推断出，不同的符号分别代表什么。创造这种代码公共性(common)需要习语(idiom)和模式(pattern)，使得代码易于 理解。在某些情况下，也许有好的理由来改变某些风格规定，但为了获得一致性，不管怎样我们还是得保持风格。 这篇参考指南所关注的另一点是C++的功能膨胀问题。C++是一个有很多高级特性的庞大语言。在某些情况下，我们限制甚至禁止使用一些特性。这样做 是为了保持代码的简洁，并避免因使用这些特性而带来各种常见的错误和问题。指南里会列出这些特性，并解释为何限制使用它们。 Google 所开发的开源项目遵守这篇参考指南里所列出的规定。 注意，这篇指南不是C++教程，我们认为所有正在阅读的同志们都是熟悉C++的。 头文件（Header Files） 一般而言，每个.cc文件都有一个关联.h文件。但也有一些例外，比如用于单元测试(unit test)的.cc文件或者只包括一个main()函数的小型.cc文件。 正确的使用头文件可以让代码的可读性、规模(scale)和性能(performance)得到很大的改观。 接下来介绍的一些规则将会引导你越过使用头文件时的各种陷阱。 #define防护（The #define Guard） 所有的头文件都应该使用#define防护来防止多重包含(multiple inclusion)，格式是 1<PROJECT>_<PATH>_<FILE>_H_ 为了保证唯一性(uniqueness)，该格式应该基于源文件在整个项目中的路径。比如说，项目foo中的头文件foo/src/bar/baz.h应该用如下的格式： 123456#ifndef  FOO_BAR_BAZ_H_ #define FOO_BAR_BAZ_H_ … #endif //  FOO_BAR_BAZ_H_ 头文件依赖（Header [...]

背景 | Context SVN是软件项目中广泛使用的版本控制工具，其作用涉及到软件过程中的多个环节。TortoiseSVN可以集成于Windows系统资源管理器中，简便易用，被很多Windows环境开发人员选作SVN客户端。除了常用的Checkout, Update, Commit等功能，TortoiseSVN还有一些高级特性可以为开发者提供更多便利，比如我现在介绍的“Client Side Hook Scripts | 客户端‘钩子’脚本”。 关于钩子 | Hooks Hook机制被广泛使用于系统开发和应用程序框架，是为软件提供可扩展性的一种手段。Hook机制的一种基本实现是：在主程序/框架代码控制流上的某些节点调用一个约定的函数，扩展代码则通过重写这个约定的函数来实现在特定时机的扩展功能。（参见WordPress PlugIn API）。在不同的系统中Hook也有很多其它形式的表现。一般来说hook不被设计为影响主要流程的因素。 TortoiseSVN客户端的钩子们 | TortoiseSVN Client Side Hooks 作为一种需要编译后运行的软件，TortoiseSVN以调用用户配置的外置脚本（比如批处理文件，com+，以及本文例子中的WScript）的形式实现hook（而非在代码中加入扩展函数）。TortoiseSVN为SVN中使用频度最高的两个操作commit和update提供了六个“钩子”如下： start-commit: 在用户选择commit功能，而commit对话框出现之前被调用。 pre-commit: 在用户在commit对话框上选定将要提交的文件并写好日志，点击提交，而客户端向SVN服务器发送数据之前。 post-commit: 无论提交是否成功，在提交过程完成后，post-commit hook将被调用。 start-update: 在update-to-revision对话框出现之前被调用。 pre-update: 在用户确认更新，而实际向服务器取回数据的动作发生之前被调用。 post-update: 无论更新是否成功，在更新完成之后被调用。 在调用任何一个钩子脚本的时候，TortoiseSVN会将此时可用到的信息作为参数传入脚本中。比如当前工作路径，影响到的文件，版本，可能的错误信息等等。关于TortoiseSVN Client Side Hooks的更多信息请参阅TortoiseSVN文档中的相关章节。 故事 | Story 麻烦 | Troubles 以下两端废话的大意是我们有时会不小心向SVN提交一些不该提交的代码，所以需要一些除了态度以外更好的办法来对将要提交的代码进行必要的检查： 我所在前端开发团队几乎每天都要使用Firebug──一种用于前端调试的很棒的Firefox扩展。为了在javascript运行时设置断点，我们会在代码中加入”debugger;”语句，同时”console.log”常常被用于在代码的某处向Firebug控制台输出某个对象，以便我们查看运行时数据。问题是，这些语句只有当Firebug存在（以及IE8在打开开发者工具）的时候才会被正常执行，否则执行至此处时javascript引擎将抛出异常，中断其后的过程。 在开发过程前期，将含有调试代码的改动提交到SVN不会有明显的危害，开发者也可以在某个关键版本前将所有此类代码移除。但是随着项目推进，QA, Writer, Build等不同团队介入，越来越多的“用户”会在不定时使用SVN上的代码。想像一下，项目经理使用最新的Build去给老板演示，却发现所有的主要功能都莫名其妙的无法完成，是怎样的一种窘境。 显然，将用于调试的代码提交至SVN多多少少是一种不职业。但是就我所在的团队的现实而言，我们在前后一年的时间里没有解决这个问题。态度决定一切这种话应该理解为“没有态度万万不行”，而只有态度没有好的方法恐怕也难以解决问题。所以我们需要一种方法，帮助粗心的开发者避免这种麻烦。 方法 | [...]

Intro As the browser applications get more and more complex in years, some of them are designed to deploy on multiple domains for reusing, maintaining, as well as some special requirements. Also some Internet campanies provide their data (search, medias, user auth.,etc) to the public as web services on their domains. In order to meeting [...]