编写代码是一种艺术，认识错误是我们代码改进的重要途径之一。以下情况并非大家都能碰到过，但希望提高代码质量的人都引以为戒。以下各种情况，都是初学者经常犯的错误。

1.1       字符串没有判断是否为空

1.1.1        直接插入数据库

这种情况经常出现在服务器的java代码中，当从用户输入的表单中获取用户输入的信息时，通常认为客户端输入的信息就是我们想要的信息，直接插入到数据库。结果，数据库中出现了很多“null”的值。随便举个例子，通常在保存到数据库前，首先需要拼接sql,举例：

String name = paramsMap.get("name");

String gender = paramsMap.get("gender");

String sql= “insert into user（name,gender） values(‘”+name+

’,’”+gender+”’)”; 

正常情况，当用户填写了name和gender时，此代码没有问题。可现实并非我们想象的那样好，在这里，这里的name的取值通常有3种情况，null，“null”（通常这种情况是客户端没有处理好）和”name”,只有最后一种情况是正确的，其他的两种情况都并不是我们所想要的。也就是说，看似简单的代码，却只考虑了三分之一的情况，其他的三分之二的情况却没有考虑。结果，这就是为什么我们在上网时，为什么查看某些账单时，经常会出现null这种用户感觉很困惑的“汉字”。

正确写法：

String name = paramsMap.get("name");

String gender = paramsMap.get("gender");

if(name==null || name=”null”){

    name=””;//如果为空，设置为空,数据库不会存储值

}

String sql= “insert into user（name,gender） values(‘”+name+

’,’”+gender+”’)”; 

当然，以上判断方法也可以写成一个公用方法，直接调用。

1.1.2        直接截取

还是以上面代码为例：如果我们想把名称里面第一个字提取出来当做姓，单独存储起来，怎么办？看以下代码：

String name = paramsMap.get("name");

String lastName = name.substr(0,1);

String gender = paramsMap.get("gender");

String sql= “insert into user（name,last_name,gender） values(‘”+name+

’, ’”+ lastName +”’,’”+gender+”’)”;  

看似没有什么问题，正常情况下，这段代码没有一点问题。可是，在实际的生产环境，这段代码可能在后台不停的报空指针异常。试问，当name为空时呢？或许你会说，在客户端控制为必填项，那如果这在业务上并非用户关注点呢，不是必填项呢？这里只是一个举例，程序中有很多这样类似的代码，总是认为参数是完整的，参数就是我们想象的那种格式。

正确写法：

String name = paramsMap.get("name");

String lastName =“”;//默认为空

if(StringUtils.isNotBlank(name)){

LastName=name.substr(0,1)

}

String gender = paramsMap.get("gender");

String sql= “insert into user（name,last_name,gender） values(‘”+name+

’, ’”+ lastName +”’,’”+gender+”’)”;

所使用StringUtils类为org.apache.commons.lang. StringUtils

1.2       根据位置取值

在某些有规律的表单值，比如像列表，我们经常使用这种方法来获得所有用户输入的数据项，然后按照html输入的顺序，依次取值，然后再做进一步处理。然而这种代码的可维护性很差。例如：原来的顺序是姓名，性别和年龄，现在需要在年龄前面插入一列，名称是联系方式，打乱了原来的顺序。那么所有取值的代码都要把取值的顺序修改一遍，这是列表的属性比较少的时候，如果一个列表的列超过了20个，而要插入的位置是第2列，那你的悲剧就来啦。

代码举例：

Var name = arr[1];

Var gender=arr[2];

正确的写法：

不要依赖属性取值，根据键值进行取值。

1.3       ID重复

这个是在html中经常出现的错误。但是当时用extJs时，这个错误却很难排查。

推荐的方法：

在命名id时，加上前缀，例如用户管理界面，所有的ID都以USER开头。或者企业用户，则添加公司的域名。

1.4       代码堆积

这个也不能算一个错误，通常一个方法超过100行，其可读性就已经很差，但作为一个企业，稳定是大家最期待的结果，所以，前辈写好的代码，我们只在其基础上修改，增加功能，拷贝代码注释旧代码，结果一个方法越来越臃肿，由几百行扩大到几千行，甚至上万行。出现问题，推卸责任，说代码之前就是这样写的。

正确方法：

如果是新增加功能，单独出一个方法写功能，在原来的方法里只需要一个调用或一个判断即可，而不要直接在原来的方法里面写代码。

如果原来的方法已经很臃肿，拆分可以独立出来的代码，然后再做修改。

1.5       太信赖客户端

比如时间和日期格式。

或许，这是按模块分配任务的悲剧，如果一个人既写客户端，又写服务器端代码，那么他可以把那个模块运行的很好。可是开发只占20%，我们却要花80%的时间来修改一个模块。那个人开发完，拍拍屁股走人，另一批人就要花80%时间来修改那个人留下的bug。其中有些隐藏较深的bug就是客户端信赖。比如：

举例1：日期，在客户端通常是选择的，格式都是固定的，而且也是正确的，在服务器端只需要获取保存即可。

举例2：某些日期是显示给用户看的，默认为当前时间，是不能改变的，在服务器端也是只需获取保存即可。

以上只是最常见的两个例子，系统发布后是怎样的呢？某些日期并不合法的日期格式也给保存到数据库。默认的当前时间会出现在当前时间之后。提交的数据也是千差百错。这是因为，用户不一定按照你的思路出牌。他不使用你的日期控件，或者还没有把你用的JS加载完毕，就提交了数据。或者用户本机的时间是错误的，你默认显示的当前日期也就是错误的。或者用户使用一些表单提交工具提交数据。

所以在程序中，服务器段校验比不可少，不但要校验数据格式，还要做逻辑校验，比如默认时间不能比当前日期还晚。