习惯的改变和习惯的建立

        每个人都有每个人的习惯，习惯有多有少，有好有坏。有一句常说的话，那就是“习惯成自然”，“自然”的东西影响是巨大的。好的习惯可以让你事半功倍，不好的习惯有可能就像一颗颗定时炸弹，随时埋下隐患。我要说的习惯是我们在平时开发过程和解决问题中的一些习惯。

       我讲的主题是改变坏的习惯，建立好的习惯。

      先从坏习惯说起，每一个的习惯都不尽相同，坏习惯也一样。我有一个习惯，在删除文件时选中文件后，喜欢用Shift＋Del键，没有等待对话框的显示就快速回车确定。对于确实没有用的文件这样做没有丝毫影响，反而感觉自己很熟练。但是有一次删除文件后突然意识到文件没有另外备份，为时已晚，我已经快速按了回车键，那可是个及其重要的文档啊，后来只能重写。这是一个很小的习惯，但是这是一个不好的习惯。

       坏习惯可以举出很多例子，比如：写代码时不加注释，代码格式紊乱，遇到问题时轻率确定原因，简单问题复杂化，不确定的全文替换，命名的随意性，先写代码后写文档，惰性习惯等等。

      对应于坏习惯，那当然是好习惯了。

l         编码时，加上简明扼要的注释是非常好的习惯。注释包括几项内容：代码建立者，修改者，代码建立时间，代码修改时间，功能描述，修改原因。特别一些重要的改变，含义的说明需要在注释中体现出来。

l         使用好的代码格式个好习惯。整齐有效的代码格式大大增强了代码的可读性和可维护性。起始语句跟结束语句对齐，括号对齐，同等级别代码的对齐，不同级别代码有层次缩进，折行书写等等这些都是好的代码格式的特征。

l         不要轻易使用全文替换。全文替换是个双刃剑，用的好，事半功倍，用的不好下场将非常的惨。

l         使用良好的命名习惯。比如在命名时使用var1,var2,var3……如果是自己刚写的代码，可能熟悉变量含义，过了1个星期，1个月，或者1年试试看，也许你自己也不知道什么意思了，更加悲惨的是另外一个人去读这些代码，呵呵，难度挺高！好的命名是第一原则按项目中规定的命名规范；其二如果没有项目规范按照逻辑语义翻译所得名称简写；其三不能按语义翻译，则使用汉语拼音；其四汉语拼音过长，那么采用编号，加上注释；

l         沟通至上的习惯。沟通是解决问题的一个非常好的途径。很多问题，你苦思冥想，就是解决不了，也许其他人一语点播你就撤悟了。另外，沟通可以让你心情舒畅不至于那么郁闷了，特别是软件蓝领们，当你实现一个东西客户、领导不理解你时，苦闷之心向谁说呢，沟通一下，吐吐苦水也挺好。

     上述好习惯仅仅举例说明一些好习惯，并不是说你就按照这个习惯实行。其实好的习惯也是需要因人而异。一个习惯只有在自己经过检验后，才能发现好的还是坏的，是需要改变的还是维持的。

“Habit rules the unreflecting herd” (William Wordsworth)。“习惯驱使着没有思想的羊群” （威廉·华滋华斯）。这句话说的很有道理，习惯可能影响的不是你的一个事件，可能是你的思想，你的一生！