编程生涯中，哪些好习惯值得坚持？

先说结论：重视模块化，重视抽象但不滥用，保持代码美观易读，先理顺逻辑，再写代码。

当我们刚接触编程时，会在网上看到许多大牛写程序都十分注重模块化，因此许多同学就会模仿他们，之后同学们可能会去看 SICP，了解到了抽象的好处，然而就会记住在写代码时思考抽象类的问题，这些都是比较有帮助的。

以往一直有这么一句话：“程序员的成长与代码行数之间的关系非常微妙”。

例如在之前力扣君看到一个资生大牛写的一篇文章中有这么一段话：程序员在 2K、20K、200K 行等规模时会觉得自己明显的遇到瓶颈。

如果不用科学的方法学习，可能超过上述这些行数的代码就会难以自立。

所以说，保持一个良好的编程习惯，一定会让你在学习和工作中事半功倍，受益终身。

曾经在程序员论坛发起过一个投票“程序员最头疼的事情有哪些”，结果非常有趣，近半数程序员会认为命名是最头疼的事。

规范的命名对于阅读程序是如此重要，所以在阅读代码时，理解一个变量和函数都是从名字开始的。它是什么？它的职责是什么？这些问题从名字就应该看出来，如果名称需要注释来补充，那就不算是好名字。

例如：将变量名

// 记录提交结果valmessage;

修改为：

valcommitResult;

将函数名

/*** 获取办公室电话号码*/fungetTelephoneNumber(){}

修改为：

fungetOfficeTelephoneNumber(){}

宁可名字取长一点，也不要起个模糊的名字。一个清楚的变量名还会带来可搜索的好处。即使在写二分算法时，也尽量别用"l"和"r"来指代左右边界，换成"left"和"right"会更好。

不过，变量名也并非越长越好，去除变量名中的冗余也是一个好习惯。Variable 一词永远不应当出现在变量名中，Table 一词永远不应当出现在表名中。nameString 与 name 没区别，moneyAmount 与 money 没区别， customerInfo 与 customer 没区别， theMessage 也与 message 没区别。

命名风格应该保持统一，每个概念对应一个词。如果一堆代码中既有 Controller，又有 Manager，还有 Driver，Presenter，就会令人困惑：他们之间有什么区别？为什么不全用 Controller？如果同一概念可被多个词语描述，请确定其中一个名字，并在你的代码中一以贯之。

总之，取一个精准的名字是一名优秀程序员的基本功。从一开始学习编程时，每次取名都应仔细思考，切不可草草了事。

大家可以感受下两种格式的代码：

classSolution{funfib(N:Int): Int{   if(N==0) return0   valf=IntArray(N+1)   f[0]=0   f[1]=1   for(iin2..N) {f[i]=f[i-2]+f[i-1]}   returnf[N]}}

classSolution{   funfib(N: Int): Int{       if(N==0) return0       valf=IntArray(N+1)       f[0] =0       f[1] =1       for(iin2..N) {           f[i] =f[i-2] +f[i-1]      }       returnf[N]  }}

一定记住需要先理顺逻辑，再写代码

有些程序员可能每天都在修复昨天和大前天的 Bug

你是否有过这样的经历：代码删了又写，写了又删。

在敲代码之前，先问自己一个问题：我写下这行代码是真的能用上吗？会不会有逻辑漏洞？思考清楚业务流程之后再写代码，往往事半功倍。

以之前同学经历的项目为例，项目已经做了一年， 除了三方库，代码量共有两万行，平均算下来，开发者一年来每天只需要写 55 行代码。这样看来，开发者的每一天都差不多是”很闲的“，然而开发者每天都忙得不得了，从早到晚都在码代码。这些代码量如果纯粹敲出来，最多十个小时就可以完成。我们应该用大部分的时间思考代码逻辑，不要花大量时间将代码删了又写，写了又删。磨刀不误砍柴工，事先做好全面的考虑，争取让写下的每一行代码都有价值。

另外美观的含义是整洁易读，之前看过一个实验，一个程序员非常不认真的写了混乱不堪的小程序，这种情况下，程序行数超过 200 行就觉的非常难受了，在需要进行一点小的修改时，往往需要花很长时间去寻找到底该改哪里，十分吃力——这种吃力感大概只有经历过的同学才有体会。

这说明了，大部分人并没有过人的天赋能在混乱中轻易找出清晰的脉络，也就是说，好的习惯一定会带来好的结果，想如鱼得水，那必定需要注重美观。

梳理代码逻辑是有一定方法的，例如：

通过画图工具先将逻辑画出来，流程图、UML 图、时序图、思维导图都能对你有所帮助。

写接口之前先模拟出假数据，测试逻辑层没有问题之后再写接口，可以避免写出的接口不合适。

善于写伪代码，将程序需要实现的每个步骤先用抽象的伪代码写出来。具体实现时再将伪代码细化。

写代码之前先编写测试用例，将你期望的输入输出写在测试用例中。

开发者应该保持爱折腾的习惯，不安于现状，才能做到与时俱进。软件之所以叫软件，正是因为它是”软”的，需求随时在更新，上星期的代码放在今天也许就不再合适。也正因为软件是软的，我们可以很方便的通过重构改进它。只要有良好的测试用例，就大胆的重构吧！这里列出一些应该重构的时机：

• 当你需要添加一个新功能，突然发现程序耦合严重，导致新功能不是那么好添加，那就先将程序重构到可以方便的添加新功能。

• 当你阅读代码时，发现程序可读性低，导致理解上的困难，显然代码还不够清晰，先将其重构到一眼能够看出结构。

你找到一种更好的实现方式，千万不要因为现有的代码仍然可用就置之不理。尝试将你的想法实现出来。即使失败了，你也会更能理解为什么代码是现在这个样子。

如果程序中用到数据库操作，一定要记得定时备份。数据库备份有诸多好处：可以防止数据丢失，可以在程序出错时方便数据回滚。而且它并不需要太多的成本，只需要写个脚本完成定时自动备份，并删除过老的备份数据即可。如果数据库没有做备份，而数据库又被误操作删除了的话，那就等同于晴天霹雳。所以代码也需要及时备份，使用版本管理系统可以解决这个问题。用上 Git，随时 commit，丢失代码的情况几乎不可能发生。

养成这些看似不经意的小习惯，真的十分让人受益，如果没有，那请尽快重视起来。如果有，请一定坚持。

BY / 

本文作者：力扣

编辑&版式：Janson

声明：本文归“力扣”版权所有，如需转载请联系。

点个在看，少个 bug