编码规范不仅仅是命名

废话不多说，请直接看下面两段代码：
代码片段1：

<select name="degree">    <option value="">请选择</option>    <option value="1">小学</option>    <option vlaue="2">初中</option>    <option vlaue="3">高中</option>    <option vlaue="4">专科</option>       <option vlaue="5">本科</option>    <option vlaue="6">硕士</option>    <option vlaue="7">博士</option><select>

代码片段2：

<select name="degree">    <option value="0">请选择</option>    <option value="1">小学</option>    <option vlaue="2">初中</option>    <option vlaue="3">高中</option>    <option vlaue="4">专科</option>       <option vlaue="5">本科</option>    <option vlaue="6">硕士</option>    <option vlaue="7">博士</option><select>

请各位认真阅读这两段代码，这两段代码只有一个字符之差，对这两种处理方式，你有什么看法呢？

其实两种处理方式都有各自的特点，和适用的场景，我想说的不是这两种方式谁优谁差，而是这两种方式带来的程序处理上的差异，以及两种方式给我们团队带来的麻烦，这里记录下来引以为戒。

首先看第一种方式，在页面中用到下拉框的地方很多，大多都下拉框都需要一个空的选项来做默认值，通常情况下下拉框会用于两种场景：一是数据录入界面，二是数据查询界面。
我们先说数据录入界面，这个默认值需要我们在哪些地方考虑程序的处理呢？通常来说有以下几个方面：
1、表单验证，主要是非空验证（或者说是默认值验证）。代码1需要判断的是非空，而代码2需要判断是否为0.
2、后台默认值处理，即当degree提交的是默认值的时候数据录入如何处理，是禁止录入，还是将默认值提交到数据库。代码1需要判断的是非空，而代码2需要判断是否为0.
再来看数据查询界面，当以上两段代码放到数据查询界面的时候需要考虑的因素主要是当下拉框为默认值的时候查询条件是否启用，两段代码给后台带来的不同是一个判断空，一个判断1。

除了服务器端代码处理方式的不同之外，两种方式的差别也会带来网络数据传输量的极微小差别，如果你的网页不在乎这几个字符的差别的话这点不同可以忽略不计。

话题到此，有些程序员们可能会说区别并不大嘛，习惯问题。好吧这的确是一件小事，但是如果在一个项目中两中方式混用，会带来什么样的情况呢？

试想一下，在数据录入界面使用代码1，在查询界面使用代码2。
您可能会想，这样的话服务器端代码需要做的是数据录入界面判断空值，查询界面判断0不就行了。
的确如此，仅此而已。

可是实际情况是，程序员在写代码的时候使用最多的键应该算是Ctrl,C,V这三个键了吧，呵呵，程序员入门必备技能啊，谁不会啊。

切记，复制粘贴没那么简单，一定要细心，如果程序员都注意到了代码1和代码2的一个字符的差别的话还好。如果没有注意到的话问题就来了，程序员1习惯使用代码1，程序员2习惯使用代码2，而恰巧这两个程序员不是那么细心，漏掉了那个0，可能会带来前端和后端代码处理方式的不一致。
比如说前端使用代码1，后端使用代码2想对应的程序去处理。于是各种奇怪的BUG就出现了。
明明没有选条件，却一条记录查不出来，可选了条件却有记录。
当然排除这样的BUG不是什么难事，也不需要很高深的技术，但是却浪费了我们的时间，要知道，程序的一个小时可是值几十大洋啊。而在我们团队中这个规范问题带来的麻烦比这要大一些，花费了两个项目经理以上级别的工程师半天的时间。

怎么避免这个问题，很简单，就是规范。团队约定一种方式来去处理这类问题。所以规范不仅仅是命名，还有很多约定，类似的问题和场景其实有很多，如果您看到了这篇文章，请您花费一点时间回复这篇文章，把您遇到的场景留下来，我会来把您的回复整理出来，为后来人留下一点积累，避免小问题带来的大麻烦。