编码常见问题(PL/SQL和Java)

帮忙的捉刀之笔，有问题请和我联系:)

编码常见问题(PL/SQL和Java)
1.PL/SQL数据类型不正确,比如aac001是varchar2类型，但是编写时没有使用''括起来，虽然程序可以查询出来，但是为日后的性能问题埋下了隐患。
 SELECT AAC002 FROM AC01 WHERE AAC001=123456;
 SELECT AAC002 FROM AC01 WHERE AAC001='123456';
2.代码超长
  不论是在java中还是在pl/sql中，超长的代码都不利于理解和维护。java中一般合适的代码长度在50-100行之间。
  PL/SQL中目前没有这方面的规范，就个人理解，最好不要超过150-200行。
3.超长的SQL语句
  超长的SQL语句非常不便于理解，大量的业务逻辑包含在SQL的WHERE中，这样的SQL既不便于Tuning，也不利于维护。FROM中所包含的对象最好不要超过3个。
  能写超级复杂的SQL并不是一种骄傲。
4.SQL语句的大小写混乱，关键字一会大写，一会小写，非常不利于Oracle解析。
  在PL/SQL中，可以借助PL/SQL Developer工具来格式化。但在Java中只能靠编码人员注意。
5.使用代码值而不是代码名称。
  SELECT AAC002 FROM AC01 WHERE AAC008 = '1';
  SELECT AAC002 FROM AC01 WHERE AAC008 = PKG_A_MACRO.DEF_AAC008_EMP;
  可以看到，如果AAC008的代码值变化，
  第一种方法要把所有的SQL都要查找一遍，很可能出问题；
  第二种方法只需要改PKG_A_MACRO里面的宏定义，凡是调用的都不需要修改。
6.大量应用全局变量
  全局变量会破坏程序结构，全局变量值的维护会发生在程序代码中的任何一点，很多错误都不容易调试，而且程序无法做到组件化，难于替换。
7.PL/SQL中使用游标未关闭
  Java端的DB访问一般都使用成熟的ORM工具，这种问题会比较少。PL/SQL中要注意及时关闭cursor，而且要注意异常发生时的cursor的状态。
8.关于错误信息
  很多人为了图方便，会将错误信息直接拷贝到各处，这样虽然编码省事了，但会为以后的调试带来隐患。应该对不同的错误提示不同的信息，而且要尽量能够通过
  错误信息还原当时的环境，这样会非常方便测试，带来的直接好处就是工作效率大大提高。
9.异常处理时的资源处理，对于发生异常时，要做到相应资源的释放，如数据库连接和文件读写是否已经放开，还有事务。
10.在程序代码中对数据库的操作不要随处乱扔，比如对AC01的修改，在很多地方都出现，一个UPDATE语句，在一个业务的A段代码中出现，在B段代码中也出现，
  如果某一天AC01的结构发生了变化，比如要写入一个通用的业务流水号，那很不幸，你只能一个一个的去修改UPDATE语句，而且还要加倍小心。
  正确的做法应该是，尽量封装DB访问到一个方法中。这不只是对PL/SQL，即使采用ORM，也要注意，尽量减少对DB的分散访问。
11.老生长谈，甚用GOTO
  在Java中，使用goto的情况现在已经很少了，而PL/SQL中仍然有使用GOTO的地方，这时要考虑重构代码流程。
12.循环变量
  因为编码人员图方便，使用拷贝的方式拷贝循环代码，这样很有可能将循环变量重复。
  for(int i=0;i<10;i++){
      for(int i=2;i<10;i++){
     
      }
  }
  虽然懒了一时，有自己吃亏的时候。
13.ROWNUM=1
  ROWNUM=1,是个很微妙的东西，他能把你的错误化为无型。往往代码中增加了这句话就不报错了，^_^好高兴哦，不报错了。等等别着急，先看看算的对不对。
  隐藏错误不如尽早暴漏错误，尤其是在关键业务中，比如划账户，如果错误已经产生，那就冲好咖啡好好加班吧。
14.对每一个SQL语句要增加执行判断。
  当在一个过程中执行大量的SQL语句时，而最后只有在一个地方捕捉，出错的时候就慢慢调吧。
15.你的注释够不够？
  没有足够好的注释，你就等着以后维护你程序的人骂你吧。不写注释的人是可耻的...
16.尽量避免在Java代码中写SQL语句
  有ORM为什么不用呢？而且还可以避免字段的变化。
17.留意那些没有被初始化的java对象
  看他们是否会报空指针错误。
18.java中应该实现接口的必须要实现接口
  比如applogic
19.拷贝，还是拷贝
  愚蠢的错误往往隐藏在不断的拷贝中，既然有重构，还要那么多拷贝干吗呢？
 
 
先写这么多吧，总之要牢记一点，你怎样对待程序，程序就会怎样对待你！