编写代码是一种艺术，认识错误是我们代码改进的重要途径之一。以下情况并非大家都能碰到过，但希望提高代码质量的人都引以为戒。以下各种情况，都是初学者经常犯的错误。
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加载完毕，就提交了数据。或者用户本机的时间是错误的，你默认显示的当前日期也就是错误的。或者用户使用一些表单提交工具提交数据。
所以在程序中，服务器段校验比不可少，不但要校验数据格式，还要做逻辑校验，比如默认时间不能比当前日期还晚。