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

欢迎关注公众号：计算机视觉life，学习切忌单打独斗，这里有教程资料、练习做业、答疑解惑等，优质学习圈帮你少走弯路，快速入门！

本文来自知乎上的同名问题，本文对优秀的回答进行了整理，解释权归答主全部，若有侵权请联系删除。

请你们各抒己见，为初学者提供参考。感谢各位。

---

Yul8ulY：

重视模块化，重视抽象但不滥用
我刚接触编程的时候，在网上看到许多大牛写程序都十分注重模块化，所以我就下意识的模仿他们；后来看SICP，知道了抽象的好处，所以在写程序的时候会仔细思考抽象的问题。这些对我都有着很是大的帮助。
在一篇讲述程序员代码行数瓶颈的博客中（程序员的成长和代码行数的关系）提到，程序员在2k行、20k行、200k行等若干程序规模时会遇到瓶颈，若是不用更科学有效的方法，超过了这个行数代码就会混乱到难以维护。但我第一次写很大的程序时（8k+）并无感受到文中提到的瓶颈；我目前接手的项目有近900k行，我本身写的部分也已经快上10k，但我仍然没遇到文中提到的瓶颈。
针对这一现象，我作过一些实验。我在很不认真的写一些小程序时，也老是写的混乱不堪，我发现，这种状况下，程序行数超过200行我就觉的很难受了，在须要进行一点小的修改时，我每每须要花很长时间去寻找到底该改哪里，十分吃力——这种吃力感是我在那些精心思考的大项目里从未感觉过的。这说明了，我并无过人的天赋能在混乱中轻易找出清晰的脉络，那就是说，以前的如鱼得水，是由于好的习惯。
后来，我进行了深刻的思考。在模块划分合理、抽象合理的程序里，我能够简单的把一个个功能抽象为一个简单的黑盒，我不须要知道他们内部发生了什么复杂的反应，我只须要知道他们对什么样的输入会作出什么样的输出。这种抽象极大的减轻了大脑的负担，让我能够把精力更多的投入到真正须要考虑的地方。而那些混乱的程序里，我须要理清每一句话之间的关系，这无疑会极大的消耗脑力。这种状况下，200行就浑身难受就能够理解了——由于我用于维护项目关系所消耗的脑力已经远远大于了那些好程序里的消耗。
这个习惯，真的让人十分受益，请必定坚持。刚开始的时候，你或许以为花很长时间去思考程序的模块划分、抽象层级是十分浪费时间的无用功；但久了之后，你就会感觉到这种习惯带来的好处：它会在无声无息之间帮你消除掉许多瓶颈。并且还有额外的好处：当你习惯用模块
化组织你的思惟时，思惟能力也会有必定的加强。

李济深：

哈，这真是一个有意思的问题。
一些朋友说的好比尽早习惯作版本管理，一开始就造成良好的代码风格，我很赞同，另一些朋友提到DRY原则，大括号对齐，甚至还有free(p);p=NULL;这样的建议，都是很容易误导人的，这里但愿刚入门或者入门不久的朋友们学会独立思考，凡事打个问号，不要盲目遵循。
我我的以为最重要的一个习惯其实有不止一我的说了，就是想清楚以后再动手。这里我稍微展开说一下，由于“想清楚”实际上是一个很模糊的概念。怎样才算想清楚了呢？
我经常有这样的经历，对一个难题，通过了一番思考以后以为本身想到了一个比其余人好得多的方法，结果去实现的时候，发现原来是想的时候疏漏的一个细节，方法不可行，感到很挫败，不得不回头过去从新审视问题，浪费了不少时间。
怎样才能想清楚呢？
Leslie Lamport在斯坦福作了一个讲座（底下有连接，推荐）。里面引用了一句话：“Writing is nature‘s way of let you know how sloppy your thinking is” 我深有同感。怎么才能知道本身是否想清楚了呢？最天然的方式就是写下来。怎么写呢？这个因人而异，好比我在编码以前，会在以下两个问题里面迭代几回。

0. 作什么？（需求：白话）
1. 怎么作？（方法：伪码）
   关于作什么，其实就是分析需求，这里跟那个“需求分析”过程有些区别。怎么舒服怎么来，大白话，不拘一格，理清楚问题就行。我一般的作法就是以自言自语自我审问的方式把整个过程理出来，为了避免至于特别无聊，这部分一般会写得十分口语化。等这部分弄清楚以后，基本上伪代码的框架在内心面就有眉目了。接下来会尝试着写伪代码，写伪代码的途中一般会不断的进行重构或者跟第一步进行迭代，直到伪代码比较精简，逻辑上没有冗余的时候，就去喝杯咖啡，小个便，回来开始实现。实现的过程当中不免会有须要回到第一个步或者第二步进行迭代的时候，随着经验的提高，迭代的次数会变得愈来愈少。
   实际上0,1两步我都是在代码的头部大块注释里面完成的，这个部分能够直接成为十分容易理解的文档。实际中除了这块注释，我几乎不在代码里面写注释。除了少数实现的trick外。
   另外刚才提到写伪代码，引出了一个潜在的问题：怎么写伪代码？建议不要尝试着用算法导论或者一些论文里面的方法。那些数学符号或者不容易敲打的符号会严重的影响写伪代码的快感。我以为《The algorithm design manual》里面的伪代码格式就不错，可是由于实际中的伪代码可能比写一个算法复杂一些，因此还须要添加一些其余元素，好比我本身的伪代码格式其实有点像是Python代码。写伪代码的主要目的是弄清楚实现的逻辑。
   在第0步，其实不是每一个人一开始都能写得清晰的，须要经过长期写做来锻炼。因此不管是写日记，写博客仍是写情书，坚持下去，都能对往后写代码的能力有所帮助。
   时间不早了，最后再附送两个程序员生活小贴士：
2. 作笔记，OneNote或者EverNote，把遇到的bug，看到过的好trick，好文章，好照片都记录下来。
3. Eat your own dog food. 那些本身写过的能够抽离出来重用的代码或者脚本整理好同步到github或者bitbucket上去，不断增长和改善本身的dog food。
   Update 2015-07-22:评论里几我的提到free(p);p=NULL;是一个合理的建议。我想支撑这一点的理由是“悬空指针被复用的话很危险”。可是在你的程序里面每个p都存在被复用的可能吗？并非。因此每一次写下free(p)的时候就应该想这个问题。而后再考虑是否写p=NULL；由于惧怕而写下的这些冗余代码会极度影响代码的美观，这也是我认为从free(p)到p=NULL不该该成为一个顺手的习惯的缘由。---https://www.youtube.com/watch?v=6QsTfL-uXd8

闭嘴看我秀：

说一些基础的、适用于初学者的好习惯。

1.在开始编码以前先规划和组织代码

在项目的开始阶段，不要上手直接写代码，必定要先肯定代码的分层和架构。该分层和架构在必定程度上决定了将来整个项目的代码风格和维护性，对于项目的长期维护，代码架构的设计是一件很是重要的事情。
代码架构能够提供更好的可读性和可维护性。你们可能还记得刚开始写代码的时候，全部的代码都会集中在一个文件，甚至一个函数中，好比

 

 

随着需求的增加，代码量的扩大，这样的代码是很难阅读和进行维护的，因而咱们会使用重构的手段去让代码更便于维护和阅读：

 

 

进一步，咱们将代码分散在不一样的文件、文件夹中，经过良好的命名，咱们甚至能够在不去看具体的代码实现的状况下，仅仅经过文件名就能判断出在作的事情：
│   main.c
│
├───job
│       first.c
│       second.c
│       third.c
│
└───other        
other file
就文件来讲，能够从文件名上，分清哪些是头文件、哪些是源文件、哪些是第三方库、还有各类功能模块的细分等。
就代码来讲，包括统一的命名风格，封装在同一个文件里的代码的相关性足够强等。
一个好的架构还应该尽量的提升代码的可扩展性。
你要知道需求变动太TM正常了，新增需求也太TM正常了。所以好的架构，必需要考虑到这些状况的发生，由于他们是必定会发生的。因此，必定要避免把代码写死。

2. 避免大块重复代码，小块也不行

一个很是好的编程习惯是确保为代码建立函数或类，以便有时重用。当你的编码过程当中屡次出现重复的代码块，这样很臃肿、很鸡肋，你就应该想他们是否应该封装成一个函数或类。专门为能够反复使用的功能构建专用文件。例如，数据库调用（例如打开数据库链接，选择数据，插入数据，更新数据，删除数据和关闭链接）都应该转换为函数。经过没必要重写冗余代码行，也会使你的工做变得更加容易。你须要作的就是调用该函数，简单、清洁、并且容易。
例如，如下是将记录插入MySQL数据库的PHP函数示例：

 

 

3 . 使用易于阅读的命名约定

不管你正在开发什么类型的代码，命名约定都很重要。你建立的变量名称，函数名称，类名称和任何其余程序名称越人性化，你后续的开发和引用就会越容易。由于全部代码并不都是同一天写的，并且一个项目每每由不少人共同参与，好的命名约定能够大大提升编码效率，还能够下降你在同事心中的傻逼程度。

 

 

4 .给代码多添加注释，即便它看起来很明显

就算它写在脸上，也必定要注释、注释、注释。由于当你正在处理代码的时候，它确定是易懂的，否则你也写不出来这样的代码。可是，当你再次回到该代码时，你可能彻底看不懂。并且这也会大大减轻同事的负担，换位思考一下，假如老大让你改一下同事A没有注释的代码，可能改一下只须要2个小时，看懂得两天，你内心确定万匹草泥马奔腾。

特别是若是该代码中有大量嵌套元素。对这样的代码块的右括号进行注释也是一种好习惯。

 

 

5.在构建时测试和调试代码

每次建立代码块时，都应该对其进行测试和调试，以确保它正常工做。不要蒙头就是写，而后写完了以后在调试，避免为了找到错误而筛选数百或数千行代码。不只须要在构建代码时测试和调试代码，还须要确保打开全部错误报告，以便在实际操做中实际查看错误。好比PHP，你还须要确保在php.ini文件或user.ini文件中打开这些设置，该文件一般位于根目录中。

 

6 - 实现版本控制系统

版本控制是编程的一个重要方面。当你构建一个简单的软件时，你可能不会在一开始就考虑版本控制。可是，随着时间的推移，你将须要改进该代码，不管它是什么类型的代码。并且，随着你的改进，你将须要跟踪你的版本。请记住，编程不仅是编写代码行，你必须可以正确地组织代码并跟踪你的工做。
保留版本也是很好的，这样你就能够不时地检查一下，看看你在以前的版本中作了什么，或者可能带回你在先前版本中删除但如今想要重用部分的代码。这是一个很好的习惯。所以，你须要一个能够控制版本的工具好比git。

Ryan：

遇到不清楚或不懂的知识点，先去看官方文档！先！去！看！官方！！文档！！！！
不少官方文档是英文的，硬着头皮也要看！看着看着就习惯了。
刚开始读英文文档会费时间和精力，可是等你回过头来再看，你会以为这才是最恰当的选择。为何酱讲？
且不说你的英文水平获得提高（这是程序员没法回避的问题），耐性获得锻炼，什么叫官方文档？！两个痣：权威！准确！当你习惯了在百度上百度一些似是而非，似懂非懂的答案时，甚至有的文章观点彻底不同，你就会懂我在说什么了。固然，我并无否定网上有好的答案和文章，我本身也常常看别人的博客。只是，做为初学者，你的水平很难去辨别一些文章，观点的好坏对错，而这可能会对你理解一些知识带来致命的误导！
因此，做为初学者，咱们应该多读官方文档，不要浮躁，要知道任何成长都没有捷径！共勉。

坐家：

可能不算一个编程习惯，算一个工做习惯吧。要懂得拒绝，要懂得说不(知道)，也要懂得主动要工做。拒绝的理由能够是：忙着呢；这块不归我负责；xx更加适合作这个；这个须要老大赞成才能作 …….。这样你能够少作不少可有可无的事情，专一于本身负责的或者感兴趣的工做上。拒绝主要对普通同事，其余部门的要求，对老大不能随便拒绝，只能说不知道。不知道的理由能够是：没作过啊；不熟悉啊；很久没碰这个了 ……。这样老大会给你更多时间，你能够把一件事情作好而不是作完。主动要工做：当你不太忙或者当你手上的工做完成时间可预期的时候，向老大要工做。主动选择那些你负责的和你感兴趣的工做要。这样，当你拒绝和说不知道的时候，老大就不会以为不爽了。  有些工做是颇有趣的，你不要别人就会要走 :)