编写程序常见问题总结

前言

编写程序过程中，不加注意，会出现好多微不足道的小毛病，有些问题非常低级，尤其是在对代码规范要求不严格的公司里，这些毛病积累起来，可能会要了软件产品的小命，回顾了最经做的几个项目，总结了以下问题。我自己整理的，有问题欢迎讨论！

常见问题

一、 C# 代码编写方面

1、 不能因为项目进度而牺牲代码质量，不然代码质量会严重影响你的项目进度。

2、 对代码质量的要求多么苛刻都不过分，省一分钟的将就，会浪费一天的维护时间。

3、 从DataTable或DataGridView控件中取值时，不要用数据序号标志取哪一列的值。

(1)： dr[0]、dr[2]、this.dataGridView1.Rows[e.RowIndex].Cells[6].Value

(2)：dr[“userName”]、dr[“ISBN”]、this.dataGridView1.Rows[e.RowIndex].Cells["targRID"].Value

l 中字段多时很难一一对应，伤神费力;

l 的方法耦合性强，如果取值的语句中列的顺序变了，程序就得跟着变。

l 可按照(2)中的方法用 名字来标志列。

4、 方法间传值，应尽量避免用很长的数组做为参数。原因是：值不好对应、耦合性太强。

可以用哈希表、封装成一个类、用结构体来实现。用哈希表Key、类属性名、结构体的属性名来标识。



5、 变量定义在循环结构内和定义在循环体外的区别。

for(int i=0; i < 10 ; i ++) { int j = i; }

int j=0; for(int i=0; i < 10 ; i ++) { j= i;

讨论：

（1）中的写法是每次循环都要为变量j分配一个新的空间。结束一次循环后，会自动回收本次循环的变量，但根据语法规则，这种声明方式是没任何问题的。

（2）中变量要定义一次，多次赋值，少了频繁地定义与回收。建议使用（2）的方法。

6、 代码中尽量不要有汉字，DataTable列名、DataGridView的列名尽量不用汉字。

(1)：if(orderState==”下单成功”)

(2)：if(orderState==”OrderOK”)

遇到订单状态等可以枚举的值 ，可以定义一个枚举。

7、 不能用方法返回的异常信息，做为程序流程判断的标准。如下：

int Count =UpdateZt(Managerid, targetZt,ref err); if(err.IndexOf("未将对象引用设置到对象的实例")!=-1){….}

8、 遇到非托管代码部分，要手动释放内存。可以定义Try{ } catch {} finally{} 结构，将释放内存的操作放在finally内。以下是平台未释放excel进程的例子。



9、 所有有可能为null的地方都要判断，杜绝理想编程。包括：页面传的值 、方法返回值等。

10、 所有界面上要输入数字的地方，都要做类型判断,页面和后台代码都要验证。





11、 适时地用缓存。不重要的系统设置、基础字典信息等不经常更新的东西非常适合放入缓存。

12、 SQL语句不要以拼字符串的方式组织。要以变量方式。存储过程中也要以参数形式。

(1) 拼字符串方式容易造成SQL注入式攻击，有的网站能用（' or 1'='1' or '1'='）登录。

(2) 拼字符串方式会因特殊字符造成执行失败，如语句中有 单引号、冒号等。

(3) 拼字符串方式的语句不利于数据库级别的优化。因为Oracle数据库可以缓存一部分语句，如果再遇到相同的语句，就能提高执行效率，而以变量方式的语句，每个执行的语句是相同的。



13、 有数据库多表同时操作时，一定要用事务。

14、 注意float类型值在加减乘除时，会出现误差的情况。



15、 程序中定义变量，起名要有意义，不要定义名字类似“XX”、”XXXX”、“sdfs”的变量，当时想着，先实现，再改名，然而之后一般不会去改。

16、 不要写太长的方法。比如有100多行或者几百行，甚至上千行，那肯定有问题，肯定可以分拆成几个方法。一可以将共同的部分封装，二能提高方法的可读性。

17、 取前多少行的写法不同，取得的结果也是不同的

取最新出版的10个商品（带order by的） 1 、第一种写法 select spxxid, spbh, CBNY, pm, dj, zz, dt, xt, WSJG from jt_j_spxx where SFSJ = 1 and cbny is not null and rownum<=10 order by CBNY desc 结果是前10行里符合条件的再排序 2、 第二种写法 select * from (select spxxid, spbh, CBNY, pm, dj, zz, dt, xt, WSJG from jt_j_spxx where SFSJ = 1 and cbny is not null order by CBNY desc) where rownum <= 10 结果是符合条件的排序后，再取前10行

18、 在新建立一个方法前，确认是否已存在实现些功能的方法，不要造成重复编写。（别人已写过）

19、 程序优化是一个日常性的过程，当初设计比较好的程序结构可能会有所修改，每次修改完，最终要求的功能实现了并不算完，应该再想想是不是应该封装的封装，应该调整的调整。如：

(1) 当时为了快速达到效果，定死的变量你提取出来了吗？（email）

(2) 你有没有将可以封装的部分提取出来，别的地方可以很容易地调用？（tjbb 的 title）



Ztid 为什么不提取出来呢？

(3) 能合并调用一个方法就合并调用一个，可以方便维护。

(4) 你有没有优化写法，将没用的操作、没用的变量去掉。（有的对数据库的操作最后没有用到）

(5) 你有没有将将删除代码留下的空行去掉，使代码美观？

20、 文件操作不判断文件夹是否存在？

21、 有没有对界面上输入长度进行限制？（）

22、 添加/修改数据库中时间字段值的时候，不要用DateTime.Now取当时值，应该让数据库取sysdate值。

因为如果是asp.net程序，Web服务器的当前时间可能和数据库中的sysdate不一致;

如果是WinForm程序，客户端机器的当前时间更有可能和数据库服务器的系统时间不一致。

23、 修改一个方法时，看一下有几个地方引用了这一个方法，你的修改会不会涉及到其他功能。

二、 Asp.net WebForm编程方面

1、 尽量减少访问数据库的次数。但和代码独立性有冲突。

2、 尽量不要在C#程序、JS程序里拼接html代码，尤其是带 style=’***’、class的html标签不要写到代码里。（）

3、 Js、css、html 要分开，视情况而定，是否各自放入一个文件中，不要都写在页面中，这个可以使得程序规范，也可以加快网站速度。

4、 Response.Redirect("Index.aspx"); 要写成 Response.Redirect("Index.aspx", false);不加false参数，就会报““正在中止线程””错误，原因不明。

5、 避免按钮重复提交，尤其是在前台页面上容易出现些类问题，此问题有时候非常严重

6、 程序异常被隐藏掉了。如下图所示：



7、 没必要将所有的方法都设置为Public的，只将对外公布的方法设置成Public。

8、 当需要操作长的字符串的时候，使用StringBuilder不要使用string。

9、 不在代码中使用具体的路径和驱动器名。 要使用相对路径。



10、 报错的信息，应该具体描述，不要写为"应用程序出错"、 "发现一个错误" 、“无效数据”这样抽象的提示。应该尽量友好。

11、 报错过程中，就将错误的完整信息记录下来，以备维护人员查找问题原因。

12、 JS代码应格式化，以提高可读性。（有的JS没有自动格式化功能，比如没有装补丁的VS2008）

三、 数据库方面（例子都是oracle）

1、 数据库要分开，在程序中，不能用DBLink直接去别的库中读写数据。数据库之前要用中间表。



2、 善于使用索引。不要小看了索引的作用。看下面的例子。

例： 湖南的jt_j_spxx表, 有1586441行记录，有cbsid、spbh字段 1、 group by后面是一个字段 （1） 没有索引：select cbsid from jt_j_spxx t group by t.cbsid 6.5秒 （2） 加上cbsid索引：select cbsid from jt_j_spxx t group by t.cbsid 6.5秒 （3） 加上cbsid索引：select cbsid from jt_j_spxx t where t.cbsid is not null group by t.cbsid 0.65秒 （4） 加上cbsid、Spbh索引：select cbsid from jt_j_spxx t group by t.cbsid 6.5秒 （5） 加上cbsid、Spbh索引：select cbsid from jt_j_spxx t where t.cbsid is not null group by t.cbsid 0.67秒 （6） 加上cbsid、Spbh索引：select cbsid from jt_j_spxx t where t.spbh is not null group by t.cbsid 0.65秒 2、 Group by 后面有两个字段 （7） 没有索引：select cbsid from jt_j_spxx t group by t.cbsid 6.599秒 （8） 加上cbsid索引：select cbsid from jt_j_spxx t group by t.cbsid,t.spbh 6.427秒 （9） 加上cbsid索引： select cbsid from jt_j_spxx t where t.cbsid is not null group by t.cbsid,t.spbh 6.521秒 （10） 加上cbsid、Spbh索引： select cbsid from jt_j_spxx t group by t.cbsid,t.spbh 6.505秒 （11） 加上cbsid、Spbh索引： select cbsid from jt_j_spxx t where t.cbsid is not null group by t.cbsid,t.spbh 0.109秒 （12） 加上cbsid、Spbh索引： select cbsid from jt_j_spxx t where t.spbh is not null group by t.cbsid,t.spbh 0.125秒

3、 时间字段不能定义成字符型、数值型的，就定义为日期型的。

4、 存储过程必须要有异常处理部分，将异常信息插入日志表，以备查找原因。

5、 建表不写注释问题。鬼知道字段各种值代表什么（如：1、启用 0、停用）（）

6、 建表时，不建立外键、主键问题。

(1) 有的表没有设置主键，一个项目中没有主键，导致一个储值卡被绑定多次，造成经济损失。

(2) 因为 发货单表和发货单明细表没有设置外键，导致造成很多“孤儿单”，有明细没有主单，造成财务数据混乱。

7、 存储过程中，用DBLINK从同步数据，尽量少同步数据，因为I/O操作非常占用资源和时间。

（1） 没有用的字段就不要同步过来。

（2） 没有用的数据就不要同步过来，用where筛选掉所有没用的数据。

8、 存储过程中，如遇到比较复杂的查询，可以采用临时表，分拆成几步来完成。如：group by gysid,spxxid，可以先group by gysid 放入临时表,后再对临时表group by spxxid。

9、 存储过程中存放临时数据的表，应该建立成临时表，不能用普通表，临时表更快。

（1） 临时表在操作上比永久表要更快。因为临时表不需要往编目表中插入条目，临时表的使用也不需要访问编目表，因此也没有编目表的争用。

（2） 仅有创建临时表的app才可以存取临时表，在处理临时表时没有锁。因为临时表的数据只对当前Session有效，每个Session都有自己的临时数据，并且不能访问其他Session的临时表中的数据。因此，临时表不需要DML锁。

（3） 如果指定Not Logged选项，处理临时表时不记日志。所以如果有仅在数据库的一个会话中使用的大量的临时数据，这些数据存入临时表能大大提高性能。

10、 尽量用union all 不用union ,因为 union 会进行排序后，去除重复行。

四、 其他问题

1、 断开VSS就修改程序，很容易造成程序版本混乱。

2、 编写完成后，不进行单元测试，或者只跑一遍正确路径的测试，就提交。

3、 三层架构中，跨层引用问题