pl 折线编码java 解析_编码常见问题(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中应该实现接口的必须要实现接口  比如applogic19.拷贝，还是拷贝  愚蠢的错误往往隐藏在不断的拷贝中，既然有重构，还要那么多拷贝干吗呢？    先写这么多吧，总之要牢记一点，你怎样对待程序，程序就会怎样对待你！