Let's talk about how to handle the "branch condition" in the program more reasonably.

CompileCodeDuring the process, the classes we write usually need to support multiple branch conditions. In general, we may set some parameter variables, to distinguish these branch conditions, it raises a problem. Do we need to use as few variables as possible to represent multiple condition branches? Or do we need to distinguish them based on the condition nature first, what if we use different variables to represent them?

 

I often encounter this situation. These two methods have their own advantages and disadvantages. The former can reflect the spirit of simplicity, while the latter pays more attention to classification. The former has obvious drawbacks, it will increase the cost for other developers to read our code. On the contrary, this is the latter's advantage!

 

Speaking of this, is this problem based on your coding habits, or is it focused on team collaboration? The latter is recommended for individuals, because a very important premise of good code quality is to be able to achieve "easy to read and modify". It can be seen that in the process of team collaboration, it is necessary to have a set of team specifications. Although it may feel awkward in the initial stage, its power will be reflected in the integration of different modules, it is also reflected in the support of subsequent projects. This is the reason for the so-called cutting-edge without mistake.

 

At the same time, there is also a situation where we generally add some hidden labels on the page to store some data obtained from the background for the use of client scripts, it can also be used for request submission. Similarly, some condition branches may occur. If there are more pages to be processed and there are more than two condition branches, is it necessary for us to process all pages in a unified manner, add all the condition branch labels, or add according to the actual page's required branch conditions?

 

The advantages of unified processing will make the development more efficient, but may also hide some potential bugs. However, in the On-Demand allocation mode, there will be no hidden bugs, because once there is a problem, the error message is displayed on this page. Of course, we need to be more careful when developing the page!

 

We may have discovered that, in many cases, we have encountered such a situation, that is, there are several things that need to be handled, often just the processing order is different, in fact, there are very few situations that can greatly reduce these things. They are just the order of processing, but the results will be greatly different! Next, let's talk about the problem above. I personally suggest using the latter for development, because if we adopt a unified approach, we will not only add a lot of redundant code, but also be detrimental to the development and maintenance of other developers, instead of putting these workloads in the later stages, it is better to eliminate them in the development stage, with the minimum cost.