在过去的7年半期间里，我带过的软件实习生超越一打，也看到过数以百计的在校生和毕业生的档案。我发现很多事件他们都须要学习。或许你会说，我说的不 就是某种特定的技术、算法、数学，或许其余特定方式的常识吗？没错，这确实是须要学习的，但却并不是最关键的事件。他们须要学习的最关键的物品是“自我规 范”。这些规范就是：尽或许地写出最繁复的代码；假设代码前期会由于改变而变得混乱不堪就得重构；尽量删除没用的代码，并减少注释。
我花了很多期间来督促这些实习生去学习这些内容。我经常会问他们，怎样样能力成为一名低劣的程序员，他们也通常会回答说，代码应该明晰易懂易于保养。这确实是我想听到的声响，但是很少有年轻的程序员真的能够一直如一地贯彻这一点。
请谨记这一点，要懂得“自我规范”，也不能一旦代码“起效了”就立马置之脑后。假设一切的变量都命名失误，但是代码依然可以***地运转，那么这些代 码相对乱哄哄得让人不忍直视。将配置代码改良为繁复代码或许在短期内是看不到报答的：代码原本就可以上班，在清洁之后依然可以上班。这就是为什么你须要 “自我规范”这一步骤了。这也是为什么实习上班是如此必要：一个好的下属是相当器重代码品质的（即使所谓“好代码”的定义关于每个程序员都不一样），从而 迫使实习生和初级程序员不得不重复修正。
上方我举的一些例子都是新手程序员写代码的时刻经常出现的：
徒有虚名的函数/变量/类
这些函数、类和变量实践所做的事与其名字所表白的含意并不分歧。全面看名字是正确的，但是咨询实践的话，有的甚至是毫不相关的。
举个例子，我上一期的实习生写了两个类：EditorGUI和EditorObjectCreatorGUI。用于处置编辑界面的代码。让我哭笑不 得的是，用于创立新对象的是EditorGUI，而EditorObjectCreatorGUI只能经过处置不同的对象启动导航。两者的含意居然是截然 相反的！即使代码还算相对便捷，但我还是花了相当长的一段期间用来了解它，由于一开局我是在一种齐全相反的假定基础过去了解的。这种状况的处置方案十分简 单：重命名EditorObjectCreatorGUI为EditorObjectNavigationGUI即可，这样就易于了解多了。
这种状况我看到过很多。之所以会出现这种状况是由于代码在上班环节中出现了演化。在选用名字的时刻或许还是正确的，但到了写完代码的那一刻，就徒有虚名了。关键是要时辰铭刻命名规律。你得明确你减少的物品能否依然合乎函数和类的称号。
混乱的类
另一个疑问是类很乱：类做了很多不相关的事件。新配置的减少很便捷，但是缓缓的，你会发现你的代码变得臃肿不堪，各种不相关的配置随处可见。有时刻，臃肿与否也并不指的是类的大小：某个类或许只要几百行，但依然囊括了不属于它的代码。
为什么会出现这种状况呢？举个例子：假定由于某种要素，某个GUI类须要剖析什么样的纹理可行（或许是有按钮要用来选用纹理）。假设这个GUI类是 惟一须要这个剖析结果的类，那么在GUI类中这样做是无心义的。但是，由于某种要素，一个齐全有关的gameplay类也须要这些消息。所以你须要将这些 纹理查问的消息从GUI类传给gameplay类。这时刻，其实这个GUI类曾经变大了：由于它外面其实还包括了TextureAnalyser类。处置 方法也便捷：将TextureAnalyser类宰割为一个独自的类，GUI类和gameplay类都可以经常使用它。
关于这一条阅历规律很多人提出质疑：要是我减少的配置依然适宜原来这个类的名字呢？假设确实不适宜，那么我就必定重命名，或许将其宰割成独自的类，抑或用代码写成一个不同的类吗？
假设你不能为你的类想出一个适宜的名字，给人的觉得就会不舒适。假设你不能在类的名字中形容它的目的，那么就会显得乌七八糟。有时刻我们还须要将某个臃肿的类宰割成几局部，并各自取一个失当的名字。
过于宏大的类
这和上一点——混乱的类有些相似：很多物品一点一点地都减少到类中，而后它无法防止地就臃肿了。在这种状况下，这样一个类依然是无心义的，但就是长 得太大个了点。这么个硕大无朋岂但繁琐，而且很容易出现bug，由于少量的代码须要用于操作同一个私有成员变量，所以我们很容易漠视一些细节。
宰割一个曾经长得很大的类其实是相当单调的。这也会成为一个应战，假设类中的代码高度交织在一同的话。再加上它曾经在上班，修复时不能减少新配置，这样一来，我不得说，宰割一个过于宏大的类，不能严厉地自我规范是不行的。
依据在Ronimo的广泛阅历，类坚持在500行代码以下、函数坚持在50行代码以下是最适宜的。不过有时刻，这样做反倒无法行，也不理智。但是普通说来，一旦类或函数超出了那个界限我们就可以想方法重构，并将之宰割为更小更易于治理的片段了。
关于代码注释
简直一切的示例代码都会蕴含注释好了的代码片段，而不说明为什么。这段代码须要修复吗？旧的代码能否曾经被取代了？为什么那儿要写这些代码？大家都知道没有注释的代码经常不知所言，但不知何故，很多人都会遗记在自己的代码上注释。
并行逻辑和代码重复
还有一个疑问就是我经常能在若干个代码段处看到相似的逻辑。
例如，我们可以从纹理这个称号知道它大略的指标对象，比如说是“TreeBackground.dds”。为了知道纹理能否可以用于tree，我们 审核了文件名以便知道它是不是以“tree”开的头。或许经常使用SDK的话我们用filename.beginsWith（“tree”）可以很快地检测出 来。只是这句代码这么短，我们往往会选用哪个中央须要，就间接复制粘贴。当然这样就是代码重复了，而正如每团体都知道的，我们应该防止重复代码，但假设复 制的代码是如此之短，我们往往会遗记这一点，很人造地就间接copy了。此处我们面对的疑问也是显而易见的：兴许前面我们审核某个纹理能否适宜tree的 方法就得变了，而后我们就不得不履行“霰弹式修正”（即四处修正）战略，一处一处地修复。
此处的普通规律是，假设是十分详细的代码，那就不要复制，即使原本的代码超级之短，调用函数甚至比间接写须要更多的代码，也应该封装成函数。
上方探讨的这些内容曾经讲得十分透彻了。很多内容甚至你在大学中就学过。但是如今要面临的应战是你须要一步步地从主动遵守到主动铭刻于心养成一种习气。这也是为什么Ronimo中的实习生最关键的不是学习常识，而是学会自我规范。