新手程序员在工做中须要注意的问题

 

须要学习的最重要的东西是“自我规范”。这些规范就是：尽量地写出最简洁的代码;若是代码后期会由于改动而变得凌乱不堪就得重构;尽可能删除没用的代码，并添加注释。

请谨记这一点，要懂得“自我规范”，也不能一旦代码“起效了”就立马置之脑后。若是全部的变量都命名错误，可是代码依然能够完美地运行，那么这些代码绝对乱糟糟得让人不忍直视。将功能代码改进为简洁代码可能在短时间内是看不到回报的。这就是为何你须要“自我规范”这一步骤了。这也是为何实习工做是如此必要：一个好的上司是至关注重代码质量的(即便所谓“好代码”的定义对于每一个程序员都不同)，从而迫使实习生和初级程序员不得不反复修改。

 

下面本文举的例子都是新手程序员写代码的时候常常出现的：

 

名存实亡的函数/变量/类

这些函数、类和变量实际所作的事与其名字所表达的含义并不一致。片面看名字是正确的，可是联系实际的话，有的甚至是绝不相关的。

举个例子，这两个类：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的方法就得变了，而后咱们就不得不实行“霰弹式修改”(即处处修改)策略，一处一处地修复。

 

此处的通常规律是，若是是很是具体的代码，那就不要复制，即便本来的代码超级之短，调用函数甚至比直接写须要更多的代码，也应该封装成函数。

上面讨论的这些内容已经讲得很是透彻了。不少内容甚至你在大学中就学过。可是如今要面临的挑战是你须要一步步地从被动遵照到主动铭记于心养成一种习惯。