对边界条件要形成条件反射么？

Question

通宵在折腾边界条件考虑不周带来的BUGs. 比如下面这段：
        rstThI.AddNew
        rstThI.Fields("tId") = m_index
        rstThI.Fields("strBId") = strBizIds
        rstThI.Fields("strAId") = ""
        rstThI.update通常它会工作得很好，可是如果在极个别的条件下strBizIds为空的时候，还添加一条新纪录的话，会给后续的代码的正常运行带来麻烦。因为有另一处要将 strBId 字段取出作为某个WHERE子句的条件，当 strBizIds 为空时，程序里所构造的WHERE语句就成为
WHERE ([strBId]=)，这就构成一个不合法的SQL语句。将上面的代码加个判断，才能避免上述问题，如下：
    If strBizIds <> "" Then
        rstThI.AddNew
        rstThI.Fields("tId") = m_index
        rstThI.Fields("strBId") = strBizIds
        rstThI.Fields("strAId") = ""
        rstThI.update
    End If这个说来没什么难的。可是我起初写代码的时候几乎完全没考虑这种特别犄角旮旯的情况，导致现在程序运行起来是危机四伏。我在想，下次改如何避免这种囧境？我在写程序的时候，心里想的是一套数据集，并没有去想那极端条件；可我觉得如果在写程序的时候，就把极端条件也全想上，那会让逻辑很容易乱掉的吧？我迫不及待地想把它写完，如果停下来去想那些犄角旮旯儿，写的过程中会很烦的吧？磕磕绊绊那种感觉？不过现在写完，再来一点点筛虫子，也很郁闷的说

Answer 1

边界条件这最需要测试的东西被你无视了
单元测试就是干这事的，接口明确了，单元测试自动跑起来了，想出bug都难。

Answer 2

通宵写程序，本来就容易“锈逗”，不如好好睡一觉，第二天再写。当写到第二行的时候脑子里要想一想m_index的可能值，写到第三行的时候想一想strBizIds的可能值，期望值是什么，可能会出现什么值，如果出现了超出期望值的值会出现什么情况，这时候怎么处理。这个技能需要多锻炼。

Answer 3

即便前面为空,后面也不该出现WHERE ([strBId]=)    ????????
是你条件没处理好吧

Answer 4

提醒的好。刚才看了看，那个SQL语句的构造很复杂，辗转很多个函数，拼接在一起，大概是下面这个语句导致上面的结果：
strTmp = ".bid =" & strBId其中的strBId在某个函数中直接通过访问某条记录的字段得到，如果这个字段未赋值，得到的效果就是：
WHERE ([strBId]=)    也许我应该写成这样更为科学：
strTmp = ".bid =" & NZ(strBId)

Answer 5

xixi 又可以灌水了啊？

Answer 6

感觉这不应该是西西问出来的问题，呵呵~~1：
数据库设计时，字段本身会带是否允许为Null的设定。
如果从逻辑上strBId不应该为Null，则在程序中也应该做相应的处理。2:
之前我们还在讨论纸和笔的事情，这也算是个应用场景之一。
每个字段值，都应该当作一个逻辑条件进行处理。
比如，
是否为空。
数值型字段前端传过来是否带进了字符。
定长字串接收到的字串是否超过了长度等等
这些可通过前端的控件（如textbox maxlength）进行一些设定，控件事件非空不准进入下一步等
其实到里写库这个级别，一般就不怎么判断了。平常我自己会这么写比如
if strBId="" Then
 MsgBox "本字段不能为空"
 focus某控件
 Exit Sub/Function
End IfIf ...
End If多个逻辑保护后，进入实际写库阶段这样判断和写库是分开的，逻辑比较清晰3:你的数据库字段命名规则不对，strBId 这种命名方法明显是VB变量式的命名方式了。