由于“跟我混”的一些小伙伴编程功底相对来说比较薄弱，以是在此总结一篇“编程内功心法”帮助他们渡过职业生涯的第一个瓶颈期。顺便，也造福一下途经的有缘的同学！
于是有了此文。
首先，思考一个问题，何谓编程？编程便是写代码吗？
所谓的编程，实在便是不断的对这个现实天下中的问题建立模型并将其固化为代码自动化实行的过程。
~ Bug辉 《GoF设计模式 - 阐明器模式》
在对问题建立模型的过程中，我们会碰着非常多不同层面的问题，以是我们须要很多领域的知识去办理这些问题。
我们须要管理被操作的数据，由于数据与数据之前是相互有关联的。将数据构造化，常日是编程的第一步。关于构造化数据的干系理论以及实践，须要有一个专门的学科分支或者说课题去研究——数据构造。
我们须要办理一个详细的问题，这个详细的问题如何一步步去办理，过程是怎么样子的——算法。
我们须要将办理方案进行自动化，并以代码的形式进行交付——编程措辞。
如果将一个抽象的模型进行编码实现，如何实现“这个功能”，如何实现“那个功能”——编程技巧。
问题的规模大了，浩瀚代码糅合在一起，连程序员自己都看不懂了！
怎么来拆分、模块化这些代码——设计。
代码量已经到了一个人无法完成的地步了，须要团队分工互助才能完成了——工程化。
你写的代码我看不懂，没法调用或者很难调用，我写的代码你也看不懂，或者很丢脸懂。还怎么愉快的玩耍——编码风格/编码规范。
问题的规模连续扩大，到了系统工程的规模了，之前学的套路已经不管用了！
怎么来构建这个别系才能实现精确、安全、高性能、高可用——架构。
然而这些也只是一个别系工程中的冰山一角！
这是一个弘大的体系。也正是由于软件开拓须要考虑到的问题太多且团队成员水品参差不齐，以是团队开拓中并不是每个程序员做的事情都是一样的。每个人都有自己的角色、低级工程师、中级工程师、高等工程师、架构师、CTO。。。
以是编程不仅仅只是堆砌代码！
说到这里，我想起来了一件事情——为啥业界普遍鄙视培训出来半道出家的新人？人与人的差异是很大的！
我见过培训出来也很牛的。实在，说到底，被鄙视的并不是所有人。而是那些培训了几个月之后创造随便找个事情也能拿“高薪”然后还自认为编程很大略的新人。由于这种经历给了他们一种错觉——编程如此大略，我培训几个月也会嘛！
有点像刚学会开车的新司机，很嚣张的对老司机说“开车很大略嘛！
你看我也会啊！
”。措辞和开拓工具只是招式，这是外功。而编程思想、履历是内功。这些内功并不是靠短短几个月的培训能够节制的，这一点有点像中国制造业和日本制造业的差异。动不动赶英超美可不好。。。
编程并不大略！
这是一件很严明的事情。不过本日，我没有办法先容完所有的方面！
或者说，到本日为止，我也并没能节制所有领域的知识。以是本日我只是分享一些关于编码本身的一些履历。
其余，本文紧张分享如何写代码，并不是如何用Java写代码。以是文章中各种措辞都有可能涌现。
编码风格先来一个圈内的段子。
大部分程序员在事情中都很讨厌这四件事情：
写注释
写文档
别人不写注释
别人不写文档
o(∩_∩)o 哈哈。。中枪了没！
这个段子实在反响出来一个问题，即大部分代码都须要通过大量注释和文档来解释才能将意图传达给掩护这些代码的程序员！
然而，就像上面的段子说的那样，写大量的注释和文档实在是一件很麻烦的事情。以是很多时候，由于嫌麻烦，注释和文档就没写，导致掩护代码的人相称的痛楚。这个苦同学们肯定都是体会过的！
相称于给你个精密仪器要你掩护还不给解释书。
实在，冲破上面那个段子描述的那个怪圈的一个很有效的手段便是统一编码风格。精良的代码可以实当代码即注释，代码本身就可以非常清晰的表示出它的意图来，让别人可以很随意马虎读懂。这便是所谓的可读性！
打算机科学领域中最难的两件事是命名和缓存失落效！
命名并不大略，很繁芜。好的名字可以见名知意，非常随意马虎理解。之以是说命名难是由于命名的过程同时也是观点提取的过程！
对问题建立模型，须要提取观点并授予其“术语”。这个过程实在是“万里长征”中最难的一步。毕竟，设计也好，架构也罢，都有成熟的套路可以参考。唯独这个过程，是须要程序设计者自己进行充分的思考的创造性事情！
以下是总结出来的一些命名履历：
一个类是某物、某事、某人的抽象，是数据与行为的凑集体。这恰好符合名词的定义，因此 类名 是一个名词！
方法名 或者说 函数名 是某操作或者某过程的抽象，是一个动作。这恰好符合动词的定义，因此函数名常日是一个动词。
变量名宁肯长一些解释清楚用场也不要用a、b、c之类的无意义的名称，除非是循环计数器中用i、j、k等约定俗成的一些变量名。比如pageIndex和pageSize就要比取名成i和s好!取成这种和用稠浊器稠浊过后的代码一样的名称没有什么好处，如果算法比较繁芜的话，过一段韶光恐怕自己都会看不懂。
变量名最好包含变量本身的业务含义。比如ListstudentList = new ArrayList<>();就比Listlist = new ArrayList<>();好很多。如果同一段代码里再涌现一个List的话，这样就可以很方便的取名为teacherList或者teachers而不是list1和list2这样的毫无意义的名称!
英文不好怎么办
这个问题怎么说呢。。
作为一名程序员吧，根本的英文还是要懂的。要不然发展也随意马虎碰着天花板，学不好编程的。毕竟，最新的技能、办理方案、工具都是从国外传过来的。如果是办理一些根本性的问题，每天只做做CRUD，彷佛英文确实不怎么用得上。但是一旦碰着一些本色性问题，恐怕只能到英文网站上找喽！
ㄟ(▔ ,▔)ㄏ 不要跟我说你编程可以不须要Stack Overflow。copying and pasting from stackoverflow 可是终极编程大法！
o(∩_∩)o 这句话可是编程的真谛啊！
(如果你看不懂这个梗那你有可能是伪程序员)
实在，话说回来，实在未便应用英文的时候，我认为也可以用拼音命名。这个问题上可以务实一点，实事求是。但是，拼音和英语混用的做法就不太好了。最好别这样！
逼格不高。
怎么添加代码注释
关于注释，我们须要办理的第一个问题是如何添加代码注释。
对付Java、C#之类的措辞，有专用的文档注释语法，很好处理。对付C/C++，则按约定的格式解释一下类和函数、代码片段的浸染和意图即可，至少编译器会进行静态检讨。在Python中，有更牛逼的文档字符串这样的措辞级特性支持，看注释用help()很方便。不过对付Lua这样的弱类型阐明型措辞，注释就比较难处理了。这里以Lua为例给出一种注释的办理方案。
借用Java措辞文档注释的风格。
文件注释，或者说类/模块注释。
函数注释
tips: Lua中可以通过metatable机制实现类和继续，这一点与Javascript通过原型机制来实现类和继续有点类似。
注释里该写些什么
我们首先来看个反例。
首先这个方法名本身就取得不好，这个暂且不说，先说注释问题。这里的注释犯了几个错：
1. 方法注释为“查询”，这切实其实便是废话!方法名已经见告别人这是查询方法了，还在这个注释里写这两个字有什么意义呢?而且到底查询些什么这里也没说!
2. 参数没有注释。没有描述每一个参数的意义以及取值范围等!
3. 什么情形下会抛出PageIndexOutOfBoundsException没有描述清楚。
4. “定义一个整型变量”这种垃圾注释就不要写了，这么大略的语句谁看不懂啊!如果要注释，也是写上这个变量的含义。
这里我们先不考虑设计问题（分页索引号最好做成可以自己调度成合理值），下面再来看改进注释之后的代码。
改完之后的注释有没有觉得信息更全很多！
虽然说代码本身便是最好的注释，但是必要的注释还是得写上去，毕竟调用的时候别人没法预测你的索引号到底从0还是从1开始。其余，如果函数内算法比较繁芜，可以在代码块内注释，也可以在函数注释上直接写清楚这个函数内部的大概算法/逻辑。代码写出来便是给别人调用的，如果没有基本的注释信息，那么每次调用你的代码的时候，都得去看一下你的函数内详细逻辑才能知道怎么调用。这显然是非常低效的！
命名与注释这两个基本方面没做好的话，会影响到全体团队的运作。也便是说，你封装的东西并没有给队友节省什么韶光，别人用到你的代码的时候，又须要花上一些韶光去读你的代码。如果团队里每个人都这样，那全体团队都会极其低效。我个人是非常不愿意与这种代码风格恶劣的人互助的。
参考规范关于编码风格的问题，本文只说命名和注释这两个方面。关于缩进、空格、断行、空行等其他方面的问题，可以参考本节给出的参考规范。
不同的企业会有不同的编码规范，以是这里没有办法给出一个符合所有公司的规范。不过制订自己团队的规范的时候，可以参考一些大企业的做法。以下是天下上最大的互联网公司谷歌的编码规范，同学们可以参考这个。
Google Java Style Guide
Google C++ Style Guide
Google Python Style Guide
Google HTML/CSS Style Guide
Google JavaScript Style Guide
非常处理非常与返回值有什么不同
在C措辞中，我们的函数常日会返回一个整型值作为状态码用于关照客户端调用的结果。比如0表示成功，非0表示失落败。并且可以通过不同的数值来表示不同缘故原由导致的失落败。然而在Java、C#、C++一类面向工具措辞中，一样平常不会用返回值来表示状态。返回值一样平常用于表示返回的业务值，而非常用于关照客户端程序运行状态改变了。
什么时候须要抛出非常
关于这个问题，我想到了一句极其精髓精辟的话：当函数无法完成其流传宣传的任务的时候抛出非常！
比如上面的那个日子，当listArticle方法由于各类缘故原由无法查询出文章列表的时候，则抛出非常。
抛出非常在这种场景下是非常有必要的，由于这样其他人调用你的代码时可以非常放心的去调用，只要调用了你的方法，就会返回文章列表。如果无法返回文章列表，则会抛出非常。完备不用在调用这个函数的时候去疑惑是否实行成功了。
再来一句至理名言：
甘心终止程序也不要带错运行下去。
也便是说，碰着缺点的时候，甘心抛出非常终止程序，也不要带着错运行下去。这是在掩耳盗铃!
非常须要携带什么信息
首先，非常的类型本身会带有非常种类信息。其次，非常的message属性可以带上更详细一些的信息。这里须要把稳，千万不要像下面这么做。
抛出非常了肯定是实行失落败了呀！
带上这种信息有什么用，不是带了一句废话嘛！
该当是下面这样
日志
谈到日志，首先要搞清楚一个问题，日志是干嘛用的？
用来记录运行时的缺点信息啊！
是啊。彷佛大家都知道日志是干什么用的，但是为什么写起代码来就会忘却初衷呢！
来看看代码：
这里的代码是什么意思呢？程序员们该当都能明白的！
很显然，这位程序员是想借助这些标记来调试，想知道代码到底实行到哪一行了。但是，这里很明显地犯了两个错。
1. 为什么是System.out.println(\公众\公众);而不是logger.debug(\公众\"大众);?
2. 为什么是1、2而不是一些更明确的笔墨信息呢?
在这里，合理的办法是下面这样。
我想给正在犯上面的错的同学提个醒：
1. 利用日志框架，并用得当的级别输出日志非常主要。
好多程序员从来不卖力也不参与运维干系的事情，乃至是做了好几年的Web都从来没有自己发布过网站。以是压根没有后期掩护的意识！
如果没有这些日志，当项目上线之后，运维的背锅侠兄弟创造网站挂了之后只能直接重启，然后当作什么也没看到。由于没有排错的线索。
2. 输出有效信息。
不要去输出一些像1、2、3、成功、失落败、hello这样的毫无意义的日志，要输出logger.debug(\"大众邮件发送任务成功入队。任务id：\"大众 + taskId);这样的有效信息。
大概当时你调试的时候，在你看来这些奇怪的字符串是故意义的，但是在其他人看来，这些便是天书。运维的背锅侠会提刀过来砍你的!其余像\"大众-------开始实行--------\"大众这种对运行期间定位问题没有半点好处的日志就不要输出了!自己用可以，提交代码前一定要删掉。
3. 日志中带上高下文信息。
伶仃的一句缺点日志常日没有什么实际浸染。比如上面的例子中，如果在找不到指定的模板文件的时候未将发送邮件时指定的模板文件名输出，那么排错的时候无法知道到底是少了哪个模板文件。
4. 不要在日志中输出用户的敏感信息。
千万不要在日志中输出像用户密码、邮件内容之类的涉及用户隐私的敏感信息，也不要去输出像验证码的值之类的敏感信息。
参数校验在你对外公开的方法前先插入一些检讨参数的代码，以确保方法被“精确的姿势”调用。比如：
参数校验的浸染
如果在对外公开的主要方法开始的位置不插入校验参数的代码，有时恐怕方法须要运行到方法内部比较深的位置才会抛出一个非常来。而且那种情形下，抛出的非常可能就会有各种各样的了。比如空指针、除零非常等。
这种情形下，很难一眼看出引发这个非常的根源是参数传错了。须要对你的代码进行一番调试才行！
如果一开始就在代码的入口插入了校验参数的代码，那么调用的时候，一眼就能看出来是参数传错了导致了一个非常。这样其他程序员看到这个非常之后就会去看一下你的方法注释。他一看，哦！
原来分页索引号是从1开始计数的，那么这个问题就会就此打住，给团队节省了韶光。
参数校验问题是会影响团队运行效率的一个很关键的成分。以是，请同学们重视起这个问题来。我们都是工程师，团队作战的，自己写代码快不叫快，全体团队快起来才叫真的快！
用好断言，可以让你的代码更健壮。
tips: Java中默认断言是不开启的，以是建议忽略Java措辞的断言，自己处理。
什么时候须要进行参数校验
我认为一个方法或者函数在知足以下条件时有必要进行参数校验：
方法或者函数是对外公开的，不是私有的。
参数有可能为空指针的时候。
参数的合理值无法通过方法名、参数名、参数类型一眼看出来的时候！
比如上面那个pageIndex是从1开始计数的，但别人并不知道你是从1开始计数的。
如果对每一方法都进行校验的话，实在挺麻烦的。程序员的韶光是很宝贵的，没这么多闲工夫。不过在知足上面条件的情形下，最好还是校验一下。由于做了这个校验，你自己是会轻微摧残浪费蹂躏几分钟的韶光，不过从团队整体来看，总的调试损耗的韶光却降下来了。要记住方法/函数写出来便是给别人调用的！
参数校验须要做到什么程度
我有一个标准，便是把自己当成调用这些代码的那个人，把自己想象成有可能以任何“姿势”调用的菜鸟(实际上也有可能是不理解你的代码的大牛)。如果这个时候自己也有可能会犯某些错(比如没把稳边界值，没把稳是否可空)，那么这个时候是必须要做校验的。对付一些已经在其他层做过处理不太可能有缺点的值的情形，可以不做校验。比如你的UserService中有一个署名为public void register(User user)的方法，用于注册一个用户。这种情形下，可以只校验一下user参数是否为空，而不用对user的username、password属性进行校验(用户名密码长度是否合法等)。由于你在上一层掌握器层模型绑定的时候已经做过非常严谨的校验了。当然，这里如果你有充足的韶光，也可以校验一下。详细做到什么程度，还须要你根据情形去自己把握。
后记编码规范便是用来约束别人的！
o(∩_∩)o 哈哈！
开玩笑的啦！
实在很多时候，出于各种缘故原由，如“项目周期紧”、“项目还在探索阶段可行性未知，先实现了再说”、“项目中其他代码已经这样了，破罐子破摔”等，终极导致的结果可能便是我们这些自称“有履历”的程序员自己也不一定能写出完备符合这些理念的代码来。或许是吧！
ㄟ(▔ ,▔)ㄏ
我承认，我也写过奇葩代码。
但是，这彷佛并不是你这个作为未来精良程序员的人不思进取的情由。
小时候，老师教我们要老实，但是老师自己也不见得能完备做到。我们可以由于这个鄙视他。
终年夜后，体验过了生活中会有很多的无奈，不再鄙视“不老实”的老师。乃至低下了崇高的头，自己也变得那般样子容貌。
未来，你还会教诲你的后代“要老实”吗？
恐怕会！
由于，精良的理念，不管结局如何，都该当去提倡！
本文的不雅观点仅代表现在的我，人是会发展的，来日诰日的我或许又会有新的见地！
如果你不认同部分不雅观点或者还有其他的精良理念，可以给我留言。我们一起发展！
原作者为Bug辉（Elvin Zeng、zenghui、曾辉也行）
原文链接：https://www.bughui.com/2017/08/21/how-to-write-code/
