聊聊如何处理程序中的“分支条件”更加合理
2010-02-22 11:20:09 来源:WEB开发网核心提示: 在编写代码的过程中,我们编写的类往往会有需要支持多条分支条件的情况,聊聊如何处理程序中的“分支条件”更加合理,一般情况下,我们可能会通过设定一些参数变量的方式,与其将这些工作量放到后期,还不如消灭在开发阶段,来对这些分支条件进行区分,那么就引出了一个问题
在编写代码的过程中,我们编写的类往往会有需要支持多条分支条件的情况,一般情况下,我们可能会通过设定一些参数变量的方式,来对这些分支条件进行区分,那么就引出了一个问题,我们是采取尽量少的变量来代表多种条件分支好呢,还是先根据条件性质进行区分,然后用不同变量分别代表好呢?
本人也经常遇到这样的情况,这两种方式,当然各有利弊,前者可以体现简约精神,而后者更加注重分类,前者的弊端也很明显,就是会增加其他开发人员阅读我们代码的代价,相反,这正是后者的优势!
说到这里,这个问题就变成是按照自己的编码习惯,还是侧重于团队的协作?个人建议还是采取后者,因为良好的代码质量的一个很重要的前提就是能够做到“易读易改”,可见,在团队协作的过程中,是有必要有一套属于团队的规范的,这样虽然在初期可能会感觉有些别扭,但是其威力将体现在将不同模块进行融合,以及在后续处理项目支持时得到体现。所谓磨刀不误砍柴工,或许就是这个道理吧。
与此同时,还有一种情况,就是我们一般会在页面上添加一些隐藏的标签,用于存放一些从后台得出的数据,用于客户端脚本的使用,或者用于请求提交等情况,类似地,同样会出现一些条件分支的情况,如果我们要处理的页面量比较多,条件分支也不只两种的话,我们是有必要将所有页面进行统一处理,添加所有的条件分支标签,还是根据实际页面需要的分支条件进行添加?
统一处理的优势,会使开发效率比较高,但同时可能会隐藏一些潜在的bug,而按需分配的方式呢,则不会出现隐藏的bug问题,因为一旦有问题,此页面就会出现错误提示,当然,这就需要我们在开发页面的时候更加的小心!
可能大家发现了,很多的时候,我们遇到的都是这样的情况,即有几件事情需要处理,往往只是处理顺序的不同,其实很少有能大幅减少这些事情的情况,仅仅是处理的先后顺序,但给我们带来的结果将会大大的不同!接着说上面的问题,个人建议采用后者进行开发,因为如果采取统一的方式,不但增加很多的冗余代码,也不利于其他开发人员的开发和维护,与其将这些工作量放到后期,还不如消灭在开发阶段,这样的代价是最小的。
本人也经常遇到这样的情况,这两种方式,当然各有利弊,前者可以体现简约精神,而后者更加注重分类,前者的弊端也很明显,就是会增加其他开发人员阅读我们代码的代价,相反,这正是后者的优势!
说到这里,这个问题就变成是按照自己的编码习惯,还是侧重于团队的协作?个人建议还是采取后者,因为良好的代码质量的一个很重要的前提就是能够做到“易读易改”,可见,在团队协作的过程中,是有必要有一套属于团队的规范的,这样虽然在初期可能会感觉有些别扭,但是其威力将体现在将不同模块进行融合,以及在后续处理项目支持时得到体现。所谓磨刀不误砍柴工,或许就是这个道理吧。
与此同时,还有一种情况,就是我们一般会在页面上添加一些隐藏的标签,用于存放一些从后台得出的数据,用于客户端脚本的使用,或者用于请求提交等情况,类似地,同样会出现一些条件分支的情况,如果我们要处理的页面量比较多,条件分支也不只两种的话,我们是有必要将所有页面进行统一处理,添加所有的条件分支标签,还是根据实际页面需要的分支条件进行添加?
统一处理的优势,会使开发效率比较高,但同时可能会隐藏一些潜在的bug,而按需分配的方式呢,则不会出现隐藏的bug问题,因为一旦有问题,此页面就会出现错误提示,当然,这就需要我们在开发页面的时候更加的小心!
可能大家发现了,很多的时候,我们遇到的都是这样的情况,即有几件事情需要处理,往往只是处理顺序的不同,其实很少有能大幅减少这些事情的情况,仅仅是处理的先后顺序,但给我们带来的结果将会大大的不同!接着说上面的问题,个人建议采用后者进行开发,因为如果采取统一的方式,不但增加很多的冗余代码,也不利于其他开发人员的开发和维护,与其将这些工作量放到后期,还不如消灭在开发阶段,这样的代价是最小的。
赞助商链接