编程中，有哪些好的习惯从一开始就值得坚持？

た入场券 2022-01-25 20:08 193阅读 0赞

![1240][]

> **点关注，不迷路；持续更新Java架构相关技术及资讯热文！！！**

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

## 给变量、函数取个好名字 ##

ITWorld 曾经发起了一个”程序员最头疼的事情“投票，结果非常有趣，近半数的程序员认为命名是最头疼的事情。

![1240 1][]

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

例如：将变量名

// 记录提交结果
    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 行代码。这样看来，开发者的每一天都差不多是”很闲的“，然而开发者每天都忙得不得了，从早到晚都在码代码。这些代码量如果纯粹敲出来，最多十个小时就可以完成。我们应该用大部分的时间思考代码逻辑，不要花大量时间将代码删了又写，写了又删。磨刀不误砍柴工，事先做好全面的考虑，争取让写下的每一行代码都有价值。

![程序员的时间分配][1240 2]

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

*  通过画图工具先将逻辑画出来，流程图、UML 图、时序图、思维导图都能对你有所帮助。
 *  写接口之前先模拟出假数据，测试逻辑层没有问题之后再写接口，可以避免写出的接口不合适。
 *  善于写伪代码，将程序需要实现的每个步骤先用抽象的伪代码写出来。具体实现时再将伪代码细化。
 *  写代码之前先编写测试用例，将你期望的输入输出写在测试用例中

## 大胆重构 ##

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

*  当你需要添加一个新功能，突然发现程序耦合严重，导致新功能不是那么好添加，那就先将程序重构到可以方便的添加新功能
 *  当你阅读代码时，发现程序可读性低，导致理解上的困难，显然代码还不够清晰，先将其重构到一眼能够看出结构。
 *  你找到一种更好的实现方式，千万不要因为现有的代码仍然可用就置之不理。尝试将你的想法实现出来。即使失败了，你也会更能理解为什么代码是现在这个样子。

PS:关于重构的更多知识可以阅读 Martin Fowler 所著的《重构改善既有代码的设计》，软件开发不朽的经典。

## 定时备份 ##

> 年轻时，我曾在网上问一个命令行怎么写，有人教我 rm -rf / …

如果程序中用到数据库操作，一定要记得定时备份。数据库备份有诸多好处：可以防止数据丢失，可以在程序出错时方便数据回滚。而且它并不需要太多的成本，只需要写个脚本完成定时自动备份，并删除过老的备份数据即可。如果数据库没有做备份，而数据库又被误操作删除了的话，那就等同于

![1240 3][]

同样，代码也需要及时备份，使用版本管理系统可以解决这个问题。用上 Git，随时 commit，丢失代码的情况几乎不可能发生。

## 写一份完善的 README ##

github 上有非常多的好项目，无一例外，他们都有一份完善的 README。 README 是程序的门面，有助于别人及时发现你写的好项目（不要奢望每个人都有闲情逸致来阅读你的源码）。况且 README 文档的好处不止于此，它还可以帮助自己梳理逻辑，理清思路。

写好 README 之后，随着项目的演进及时更新它，不会花太多时间，但能让你随时都对项目有个整体的把握。绝对值得一试。

[1240]: /images/20220126/b99db3f8968b4c5abe1aa0cc8a85abf5.png
[1240 1]: /images/20220126/a52944b61e7b4243aad464f0b9cd56e8.png
[1240 2]: /images/20220126/92e7fd809eb34fc09a2688df998e6da9.png
[1240 3]: /images/20220126/1622d932e4d844c9a339796209dca831.png