【转】9个编程好习惯，建议收藏

1万 · 2022-4-23 15:22

1多看官方文档

不要被这几个字吓到，官方文档其实都是宝藏。

一个成熟的技术诞生，可以没有博客没有书籍，但一定会有一个官方文档，毋庸置疑，它一定是最准确、最实时的资料。编写官方文档的人，也通常就是这些技术或者软件的开发者，他们是对这些东西最了解的人，所以编写的文档不仅质量非常高，通常内容也都是最新的。

因此，官方文档远比网上的各种博客和论坛等更适合入门学习。当我们遇到很多问题和技术细节的时候，认真将官方文档过一遍，你会发现很多问题和认识模糊的地方都会清晰起来。

程序员都应该掌握通过官方文档去学习一个技术的能力，掌握了这项能力，你就具备了学会其他一切技术框架的基础；而且原汁原味的官方文档，还能锻炼你的自我学习总结能力。

1万 · 2022-4-23 15:24

2.面向搜索引擎编程

很多人总以为无论什么都 Google 一下是一件很 low 的行为，但其实，普通程序员+ Google=超级程序员。

用好搜索功能，Google +Stack Overflow + GitHub 能解决你的大部分问题。

所以，在问别人问题之前，先自己搜索一下吧。

当然，超级程序员可不是会Google就行的，把 Google 到的东西吸收并运用起来，才是真正的能力。不过，无论是看官方文档也好，还是面向 Google 编程也好，都必须要掌握较好的英文能力。这样才能更好的阅读文档，搜索自己所需要的东西。

1万 · 2022-4-23 15:27

3.规范命名
ITWorld 曾经发起过一个“程序员最头疼的事情”投票，结果，近半数的程序员认为命名是最头疼的事情。

822336263a9ab045e0.png (254.71 KB )

下载附件

2022-4-23 15:24 上传

有时候代码写嗨了，命名的时候就开始放飞自我，gousheng、tiedan、xiaonaigou、i、j.....自己是写嗨了，其他人阅读起来就懵逼了。
所以，不论是内部变量还是全局变量，都要形成自己的一种命名规则，能够一眼看明白变量的意思。混乱或错误的命名不仅让我们对代码难以理解，更会误导我们的思维；反之，良好的命名，则可以大大提高我们的代码易读性，也能大大增强代码的可维护性。

1万 · 2022-4-23 15:28

4.认真注释
和命名一样让程序员头疼的还有两件事：写注释头疼，别人不写注释读着头疼。 之所以要写注释，是因为当你在写某个程序的时候，可能当下记得很清楚，这一段是什么机制、如何实现，但是当你写的程序越来越多，你会忘记当初为什么这样写，改动和交接也十分麻烦，对代码进行注释就可以有效避免这种情况。注释不仅可以让人读懂代码，甚至能让读代码的人获取更多信息。

421706263aa8b6948d.png (29.96 KB )

下载附件

2022-4-23 15:28 上传

不过，注释贵精不贵多。要杜绝大姨妈般的“例注”，漫山遍野的碎碎念注释，实际就是背景噪音。

1万 · 2022-4-23 15:29

5.不要重复造轮子

“不要重复造轮子（ Stop Trying to Reinvent the Wheel）”，可能应该是每个程序员入行被告知的第一条准则。写程序实际上是一个最能“偷懒”的工作：你现在费力实现的每一个功能，可能早已经有极好的解决方法贡献在开源社区，使用好现有的轮子和各种开源库，会让你事半功倍。

当然，要找到一个非常适合的轮子，是非常不容易的一件事。有时候费了九牛二虎之力找了轮子，却发现有这样那样的问题，最后还是无疾而终。

那么，什么样的轮子是一个好轮子呢？

开源，并且 License 宽松。
有文档，代码规范，接口友好，最好有实际用例。
社区相对活跃。
松耦合，定制容易。

总之，只要合适好用，都是一个好轮子。

1万 · 2022-4-23 15:30

6.多读多写代码
提高编程能力其实没有捷径，最佳方式就是多写代码。不过，除了写大量代码，提升编程能力还需要大量阅读别人写的代码。

559086263aaf2d3a19.png (674.06 KB )

下载附件

2022-4-23 15:29 上传

一来，阅读源码可以提高编程能力。学习都从模仿开始，不管是入门时阅读教程里的示例代码，还是进阶时阅读优秀项目源码，都是很好的学习方式。
二来，阅读源码可以提高 debug 能力。只有练习积累的阅读代码的能力，才能看懂代码，从而快速准确地定位代码中的问题。
最后，阅读源码可以帮助形成良好的代码风格 。“开发”不仅要写可以执行的代码，更是要写别人读得懂的代码，这对代码的维护和扩展大有好处。

1万 · 2022-4-23 15:31

7.预留开发时间

一个程序员能否精确评估开发时间，是一件非常重要的事情。不过对于新手程序员来说，宁可多算一周，不可少估一天。过于“乐观”容易让你的 boss 受惊吓。毕竟，在评估开发时间的过程中，你需要预设各种修改对其他模块的影响。一个修改后的单元测试，可接受测试，UAT 环境测试，再到上线，很多地方都是需要花时间的。一旦某个测试不通过，然后又得调试，修改，再进行单元测试......谁能保证每次修改都是一次通过的呢。