做为合格的程序员需要写出别人看的懂的代码

最近，我做了多个项目的代码维护的工作，说白了就是修改别人遗留的代码，既然是要改别人写的代码，前提是先要看懂别人写的是什么意思，要实际怎么样的功能或逻辑。这是让我很痛苦的工作，在一些代码中我竟然发现传说中的中文变量命名，还有的是流水账式的代码，一个类或一个方法中写了上千行的代码，最头痛的就是业务逻辑断层的代码 （ 如：在业务中两个对象是有关联的，但在代码中却找不到或很难找到这种关联）。

基本上工作状况是经常一天下来就只改了不到到十行代码，大部分时间都是在看代码查代码。如果代码原作者在的话我想情况会好一些。

我可以这样对程序员的技术进行分类：

*.会写代码的程序员。*.会写代码也看得懂自己写的代码，*.会写别人看的懂的代码

我并不是要把程序员进行高低分类，做为一个专业的程序除了会技术外最重要的具备职业操守(对你写的代码要负责)，我也不是要对以前写代码的人进行评激，也许他们已经很尽力去完成任务。我只想用的我的一些经验去改善一下写代码的水平，同时可以改善思维、做人方式、生活质量和工作效能

1.多加点注释

这个道理每个程序员都明白，但能长久这么干的人没有几个（包括我在内，为了赶进度），其实写注释所用的时间比起花在代码上的时间那是少的多。似乎加注释是为了别人做的事，如果有这种想法，那么你就错了一半了，因为我认为写注释除了给别人看，还一个好处就是通过写注释再次检验你想的与你代码是否一至，并且你会从中发现问题。比如当前写了一个方法后，你准备加注释，但发现你没法去用简单的文字对这个方法进行描述，那说明你这个方法实现并不太理想或太复杂了，这个时候就需要思考了如何分解或重新定义这个方法了。其实加注释会带来很多方面的好处，如抽取接口或定义变量..... ，但无所谓那种好外，重点是验证你的思维逻辑与代码实现是否匹配(如果你的思维逻辑都有问题的话，我建议不要在这里浪费你的时间了)。（随便说下接口：很多人认为是先有接口才有实现，实际上在绝大数情况下刚好是相反的，当然你可以象前者那样做，先定义接口，但这种接口会在实现过程中不断的被变更。就好象法律上规定故意杀人是不对的，但不代表不能这样做，可以去杀人，只不过事后会受到法律的制裁）

2.适当的损失性能

这个不好的说，我还是用代码说事吧

C#

string temp = sr.ReadLine();
string productID = temp.Substring(7, 5);
string qty = temp.Substring( 12 , 4);
string doType = temp.Substring(16, 12 );
string serialNumber = temp.Substring(31, 8);

这段代码依据某种协议规则在指定的字符串中提取字段数据， 为了搞清楚它是否按协议实现的，我会对着协议一个一个的加数。我们再看另外一种写法

string temp = sr.ReadLine();
string productID = temp.Substring(7, 5);
string qty = temp.Substring( 7+5 , 4);
string doType = temp.Substring(7+5+4, 12 );

string serialNumber = temp.Substring(7 + 5 + 4 + 12 + 2 + 1, 8);

如果这样写我对着协议看就方便多了 , 当然这样会损失一些性能(要计算变多了)，

但我觉得这样在维护上的好处>损失性能（利大于弊）

又如：string s = "aaaaa\r\nbbb\r\ncccc......\r\nzzzz"  ;

//如果这是一超长的字符串的定义，你要在你陕小的窗口中拖动滚动条才能看完所有的字符串

我们可以这样写更容易看(这做不是绝对，还需依据当前环境做出正确的行为)

string s = "aaaaa"

+"\r\nbbb"

+"\r\ncccc

+ .......

+"\r\nzzzz"  ;

当然我们可以用StringBuilder来加以性能上的改善

3.管理好你的变量，不要让它到处跑

我们写代码的时候经常会定义变量，这个也不好说，还是看代码吧

class MyClass

{

string _Name1 = string.Empty ;

string _Name2 = string.Empty ;

string _Name3 = string.Empty ;

void FuncA() {   _Name1 = "abc"   } ;

void FuncB() {   _Name2 = "123"   } ;

void FuncC) {   _Name3= "456" ;  _Name1= "xxx" ;  }

}

也许这个代码比较少，不觉得这样做不算是什么大问题（我也是这么认为，代码一样能正常运行），你可以想象一下，当这个类下有很多的方法及代码，它是一个高内聚的类，我相信这会一场恶梦的开始，当你去维护这样的代码时，你会无法去确定代码中的某个变量的是全局还局部的，变量值是否改变，可否改变，使用变量的方法体之间是否存在直接的或间接的关系而带来负作用等，你要修改代码中任何地方，你都要看完所有的代码才敢小心的去做修改。

4.不要为设计而设计(死设计)

这个问题基本上是众所周知的，但还是很多人不知不觉就陷入了为了设计而不考虑业务或后期的维护等因素，导致把自己的代码推到一个死胡同(写好的就很难去改动)的局面，如果遇到这样的事，那就真的很倒霉了，如果做不到就只能推到重来。

以上只是本来心血来潮，分享一下本人这段时间维护别人写的遗留代码的一些个人看法。

我建议程序员同志们在下手写代码前，请思量再思量，要考虑清楚再下手也不过晚。(想做好任何事又何尝不是这样子呢)

行为源于想法，没有想法的行为叫感情用事。