1.你做的一切都有价值。没有无谓的忙碌工作，每次项目计划都应该直接给工作室或者游戏带来价值。

2.你做的一切都将被评估。在编写代码之前我们需要详尽的代码评估、扩展设计和分析讨论。因此每个实习生都至少有一个高级程序员辅导，以确保其成果不可挑剔。

3.无论最终是否雇佣你，我们承诺你在离开实习项目时已是一个优秀的员工。

       现在我被分配指导一个实习生，我发现这不仅仅是指导一个初级开发者的问题，而是一次机会来强迫自己明确完善自己的想法，这样我就可以清晰地把我在这份工作中多年经验传递给新人们。

      也许你并没有致力于开发下一个伟大的MMO游戏，但是我认为以下的建议对于任何人的早期的编程生涯中，都有重大意义。

 三思而后行

       老木匠有条准则：“砍一次，量两次。”大型项目的巨大挑战之一是：牢记一项决策或一个事情的所有附加的结果。有时，这些可能的结果很容易预见，而有时却无法提前知道。但是无论哪种方式，我们可以选择在编写代码时，仔细认真的思考。

       我个人喜好做的一件事是让重要的待改清单搁置一天左右，然后再带着崭新的想法来重新读取代码。我会试图怀着从未见过这些代码的心情来重新处理它，并进行代码评论。有两个需要考虑的方向：细节和宏观全局影响。

       一针见血地看破设计想法中所有后果是需要多年的经验和实践。这项技能有两个方向需要注意。首先，当你做出一个具有重大影响意义的决定时，并不意味着结果立即显而易见。其次，需要努力并有意识地让自己认识这种情况。最好的建议则是经常停下来进行尝试以及展望未来，这也是我接下来需要处理的问题。

善待未来的你

       我也会说：“善待那些看你写的代码的人们。”但是我更想强调，善待未来的你。通常情况，代码一旦被编辑，就会存在相当长一段时间。同样有两个方向我们需要考虑：细节和大规模影响。然而细节很容易在一开始被察觉，而附加影响和结果却总是难以预计。

        一些具体的例子可能更容易说明问题。对于细节而言，屡试不爽的方式则是简单格式。抱怨空格和括号的位置似乎显得过于偏执，但是这的确会产生影响。在读了20年的代码后，你能够轻而易举的识别常见的代码模式。特别是在一贯遵守严格格式标准的ArenaNet这里，做这项工作是非常省时的。想象一下，如果每个人都编写相似的代码，那么问题就会显而易见。如果当我在读一串格式化代码，被周围的事物影响的情况下，很难专注于代码本身的含义和意图。

        在一些大规模的代码中，总会伴随着源代码注释。源代码注释的方式在全世界一直都是一场没有硝烟的战争。即使是游戏开发公司ArenaNet内部对于源代码注释也存在风格多样化的观点。然而对于源代码注释，我们有一些非常有用的一致性观点。

       有时注释需要淡化处理，而有时却需要添加补充。注释只要具备以下三种情况中的任一一种情况则需要淡化处理。

*重复代码已有信息

*过时或者即将过时

*彻头彻尾的错误（由于复制/粘贴导致的问题）

给事物最恰当的名称

       这是更加细节的问题。任何团队通有的惯例对于代码的可读性和意图都有着举足轻重的作用。

       ArenaNet的代码标准文档中有许多具体的例子，但也有其他的惯例更常见，几乎可能适用于任何环境。例如，多元化是非常重要的。迭代变量应该是单数（ item/currency/character) ） 。容器（Containers）应该是复数（items/currencies/characters） 这同样适用于函数名，如果一个函数指代一件事情，将其命名为奇。如果指代多样，复数则更适当。

       通用名称是很难挑选，并需要花费大量心思来选择。如果函数的目的变化，那么请同时更改函数名称。请务必确保名称对应的意图（不要画蛇添足）。

浪费终将让你付出代价

       函数外不使用的参数，应该被删除。 （应该有专门的编译器警告， 你应该搭建你可以管理的错误最高警告级别）。同样，确保实际使用的所有变量，有各自的意义。确保函数调用有价值。例如，初始化一个变量，然后立即改变其值只会让读者感到迷惑。传递只不过一个字符串常量sprintf （ ） ，然后printf（）结果除了混乱不堪，还很浪费。

       一半是实际可读性而另外一半是真正的效率。像我们这样在大的代码库中，最后的崩溃不是由于大量浪费一段代码，而是随着时间的推移，随着成千上万微小的决定累积加起来。在阅读代码，以及如何在运行执行时的决定。内存和处理能力是要记住的东西。尤其是在巨大的资源环境下，他们可能会显得廉价不重要（甚至免费）。但不要忘了这一切是有成本的，这些成本累积速度有时比我们想象的要快得多。

       最终得出的处理办法是：惯例清理。如果你删除了一个功能，请务必确保其功能下的所有残留代码都要清理干净，包括代码注解，筹备代码，清理代码等等。在编辑时，人们从来不会忘记“逻辑”二字，但在删除时，却总将之抛之脑后。如果毫无逻辑的删除，只会给下个读者造成更多的混乱。请再次用挑剔的眼光重新审视自己编写的代码。

给它一个不错的首页

       代码跟数据一样都是极其重要的考虑因素。有些东西并不需要被包装分类--如果不能随身携带，没有可以共享的接口，那么自由函数比建造分类函数更有意义。在数据方面，尽可能严格审视一切数据，申报物品尽可能与实际使用一致。一些数据不需要文件级别的变量，在一些函数里只充当区域量。RAII是C++中的重要技术，应该大胆的使用。

       文件组织也是需要牢记的关键点。将相关的代码储存在独立的文件夹中是一个好习惯。把编程看做是一个管道，每个管段（模块）应该有各自具体独立的作用。要构建整个程序，你需要把每个管道的管段（模块/分类等）连接起来，将它整合成一个更复杂的机器。

多听听leader的建议

       你应该经常尝试模拟你工作的代码被其他人拥有这一情况。模仿它的风格，命名模式，架构决策等等。通常情况下，你可以让你的生活远离既定的管理，同时，你一定会给你的同行带来更大的压力。

       如果决策和模式模糊不清时，不要羞于询问。我知道，现在很多东西都模糊并且神秘，并且背后的原因也无法立即呈现。提问总是会有帮助的--如果问道事物背后的原因，那么你在提问的过程也是学习的过程。如果没有原因，或者是糟糕的原因，至少你获得了了一个机会，使事情变得更好。

清理你的发现

       我们作为团队的程序员应该有最高的志向之一是离开的代码比发现它更好。此范围从固定微小的细节到清理设计决策和添加文档。这是你应该尝试的，即使你没有在“自己的”代码 的时候，如果有客观的提升空间，实际上店主会感谢您抽出宝贵的时间，使他的区域更好。显然，这并不意味着你应该横冲直撞去改变每一个代码文件，在做出改变之前向物主进行咨询，绝对是有价值的。

不要停止学习

       事业稳定期是每个人都渴望的。有时候我们只是想要“到达”以及“得到”的感觉。的确你的职业生涯中有各种各样的里程碑，见证你技能和观点的成长改变。

       关键是永远不要停止追逐下一个挑战。即使已经编写计算机程序长达20年，我总是不停的吸收学习新的事物。学习过程要么选择不断更新运转，要么快速有效的死亡。

       当然，最后一则建议，提供给任何人： “不要死”。