聊聊如何处理程序中的“分支条件”更加合理

   在编写代码的过程中，我们编写的类往往会有需要支持多条分支条件的情况，一般情况下，我们可能会通过设定一些参数变量的方式，来对这些分支条件进行区分，那么就引出了一个问题，我们是采取尽量少的变量来代表多种条件分支好呢，还是先根据条件性质进行区分，然后用不同变量分别代表好呢？



    本人也经常遇到这样的情况，这两种方式，当然各有利弊，前者可以体现简约精神，而后者更加注重分类，前者的弊端也很明显，就是会增加其他开发人员阅读我们代码的代价，相反，这正是后者的优势！



    说到这里，这个问题就变成是按照自己的编码习惯，还是侧重于团队的协作？个人建议还是采取后者，因为良好的代码质量的一个很重要的前提就是能够做到“易读易改”，可见，在团队协作的过程中，是有必要有一套属于团队的规范的，这样虽然在初期可能会感觉有些别扭，但是其威力将体现在将不同模块进行融合，以及在后续处理项目支持时得到体现。所谓磨刀不误砍柴工，或许就是这个道理吧。



    与此同时，还有一种情况，就是我们一般会在页面上添加一些隐藏的标签，用于存放一些从后台得出的数据，用于客户端脚本的使用，或者用于请求提交等情况，类似地，同样会出现一些条件分支的情况，如果我们要处理的页面量比较多，条件分支也不只两种的话，我们是有必要将所有页面进行统一处理，添加所有的条件分支标签，还是根据实际页面需要的分支条件进行添加？



    统一处理的优势，会使开发效率比较高，但同时可能会隐藏一些潜在的bug，而按需分配的方式呢，则不会出现隐藏的bug问题，因为一旦有问题，此页面就会出现错误提示，当然，这就需要我们在开发页面的时候更加的小心！



    可能大家发现了，很多的时候，我们遇到的都是这样的情况，即有几件事情需要处理，往往只是处理顺序的不同，其实很少有能大幅减少这些事情的情况，仅仅是处理的先后顺序，但给我们带来的结果将会大大的不同！接着说上面的问题，个人建议采用后者进行开发，因为如果采取统一的方式，不但增加很多的冗余代码，也不利于其他开发人员的开发和维护，与其将这些工作量放到后期，还不如消灭在开发阶段，这样的代价是最小的。