如此不规范的代码，是谁编写的？”“怎么可能是我编写的

前言养成良好的代码规范不是为了别人，也不是为了公司，而是为了提高自己的编程修养，提高自己认识事物的能力。让自己编写的代码可维护性更好、可重用性和可扩展性更强。

01

刚毕业时，到广州一家创业公司应聘软件开发岗位，做教育平台的小公司，加上老板才6个人，拿着1500工资的我非常开心，刚毕业时对薪资要求真心不敢期望，有公司收留就已经很感激了。

在做用户信息导入的时候，得把excel里面的手机号码都导入到系统，excel格式是没有固定模板的，只要execl有一个单元格是手机号码，就得导入。我不懂呀，丢饭碗怎么办呢？

在做程序员前，早就听人说过，程序员最关键的是解决问题，甭管你之前学没学过，只要在你职责范围内有需求，你都得想法设法处理。

想到这，心静了下来，上网查看相关资料，先用正则表示式匹配每个单元格，如是正确的手机号码，就执行入库流程。

自测的时候，发现excel 格式有2003版本和2007版本，用2003版本执行没有问题，用2007版本执行出现点问题，无法识别，由于经验不足，暂时没有解决方案，正好是下班时候，于是关电脑下班。实现这个功能，我用了2天的时间，虽然中间遇到一些问题，通过排查，定位问题，总算解决了。

演示给老板看时，老板看了一下效果，又看了一下代码，然后轻轻拍了我一下肩膀，说，“不错，小洪啊，平时不要总是想着准时下班啊，编码方面要多挑战，才能有进步啊”。

听了老板的话，脸都红了。能力不强时，不要总是想着准时下班，说的有一定的道理，在我们自身能力不强时，应该想方设法提升自身的能力，特别是刚毕业的时候，社会经验不足，要多学习，我整理了Android进阶资料大全，需要私信我【安卓

02

刚编写代码时，我和大多数人一样，为了完成任务，对于编码规范不是很重视，写完功能代码直接提交到SVN。因此也给自己带来不少问题，时间久了，当发现有bug时，排除问题，我得重新梳理一下基本流程，浪费了自己不少时间。

类似这样的经历不知你有没有有过：

回头看看自己一年前编写的代码，会不会惊讶地发现，

“哇塞，如此不规范的代码，是谁编写的？”

”确定是我写的吗？”

”我能写出这样惨目忍睹的代码？”

分分钟钟怀疑人生。

代码规范的重要性我们知道，但要真正做好，却是一件不容易的事情，需要我们在实践中慢慢的累积。

很多时候，并非程序的算法有多复杂，或是逻辑有多复杂，而是因为代码不规范，结果导致阅读代码越读越费劲，把精力都耗在这里了。

统一的代码规范可使得代码可读性大大提高， 在团队的合作开发中是非常有益而且很有必要。

如果代码没有统一的规范，每个人都按照自己掌握理解的那一套，那么整个项目的代码很可能就会出现风格迥异。即使是项目分工明细，每个人负责一个模块，等到了要整合代码的时候就尴尬了。

随着版本不断迭代，项目维护的成本越来越高，从而形成恶性循环。程序背后的架构设计固然重要，但良好的命名规范也不容忽视。不规范的命名不仅让我们对代码难以理解，更糟糕的是，会误导我们的思维，导致对代码的理解有偏差。

而良好的命名规范，则可以让我们的代码更加容易读懂，也能向读者正确表达事物以及逻辑的本质，阅读命名规范的源码理解没有那么费劲，会有一种享受的感觉。

有人喜欢对变量，str1，str2、，str3类似这样的命名，甚至还对其添加注释。有人可能认为注释越多，其他人看到的就会越好。其实不然，注释过多，或是一些冗余注释，反而会影响源码的可读性。如果我们良好的命名规范，结合了需要和命名。它可以省去许多不必要的注释。

对于方法命名，首字母一会儿大写，一会儿小写；一会儿全称一会儿简写；一会儿驼峰命名法一会儿匈牙利命名法。

当然，起一个好的名字不是件容易的事情。首先，既要有尽量多的提供变量信息，又要尽可能的保证名字短小精悍，还不能为了短小而随意采用缩写而导致阅读障碍，另外还要尽量保证以后程序更新后名称仍然能很好的描述其内容。

在编写代码中，要尽可能的遵守一个良好的命名规范，并且不停地的调整学习命名，从而逐渐掌握起一个良好名字的能力。

03

刚毕业时，项目实战经验不足，有时候迫于项目赶进度压力，有的因为繁琐的规范作出很多额外的工作，为不不影响项目开发进度，编码规范而渐渐被忽略。

这时我们更要注意自己做好代码规范，减少自己出现的错误。很多时候项目的压力一部分也是由于前期开发中遗留的众多的问题。

那些看似无用的东西要经过我们慢慢地累积由量变达到质变的时候，相信你能体会到其价值所在。

#最后
点击下方，就可以看规范文档
偷师阿里内部，月入20k程序员的Android规范文档