I summarized it on the axis of "code that is easy to maintain"
I will write the explanation assuming Java and javascript code, but it is a technique that can be used in all languages
It's my personal idea, so it would be great if you could pick up only the ones you like.
This time, I will talk about various things on the axis of "flag".
This time, I will talk about whether it is a "value that should be considered at 0/1" or a "value that should be considered at 1/2". In other words, it can be said that it is "a value that should be possessed by a boolean" or "a value that should be possessed by an enum, char, or a non-zero value". In the following story, we will unify the numbers 0/1 and 1/2.
Imagine for a moment.
From now on, you will create a function to manage a certain task (ToDo). For each of these tasks, what variables should be defined to indicate the completion status (“completed” or “incomplete”)? Also, what variables should be defined to represent the urgency of each task (“urgent” or “normal”)? Assume that these two variables always have only these two values.
python
//Completion flag
boolean completeFlag;
//Emergency flag
boolean emergencyFlag;
Well, it looks like this. Then, what if the specifications change here and you want to have three levels of urgency: "high", "normal", and "low"? Do you want to start the implementation with this variable name?
A flag is said to be a "variable that holds information that can be expressed in one bit" in the first place. The name "~ flag" inevitably has a prejudice of two choices. This prejudice can lead to implementation mistakes when you are in a hurry or in a hurry. Avoid names that can be easily misunderstood. If there is such a specification change (if changing the variable name does not have a big impact on the project), I think that the name should be changed to this machine. For example, "emergency Lebel" or "emergency Type"?
By the way, if you have three or more choices like this, you can understand that the name ~ flag is not used. But what about the two choices of 1 or 2? I think this is a disagreement.
In my personal sense, I don't think you should use the name flag or boolean type for 1 or 2 choices. I would like to continue in the next section.
By the way, in Section 1, we explained the "completion flag" and "emergency flag" as examples. So everyone has a problem. What is the name of "gender"? What kind of logical formulas and numerical values do you expect for each?
Well, this is often called "gender" or "sex" or something like that. There should be few occasions to name it maleFlag or femaleFlag.
So, if you name it gender, do you want the value to be 0 or 1? Do you want 1 or 2?
Personally, I think it's "1 or 2".
So why is 0 or 1 bad? (Isn't I accepting it physiologically?)
I thought about the difference between the 0/1 variable and the 1/2 variable. I think the difference between these two points is the following two points in a broad sense.
・ Whether the two options are apposition ・ Is the value biased to either side (is there any assumption that it is biased?)
0 is something special in the system world. Speaking of Java int, the initial value is 0. The number 0 comes in without doing anything. In other words, 0 and 1 in 0/1 have a big difference between "doing nothing" and "doing something". In this way of thinking, the "completion flag" in the opening ToDo is exactly this way of thinking. The design is that 0 is set when a task occurs (= when nothing has been done yet), and 1 is set when it is completed.
However, men and women are of the same rank. It also exists (basically) in fifty-fifty minutes. Setting a man to 0 means flickering, such as "mostly men" or "everyone starts with a man". The reverse is also true. I think that is the difference between the "completion flag" and the "male and female".
In other words, a flag has a strong impression that it marks an unusual state or a place that has changed compared to the initial state, and each option is flat or has a completely different vector. For example, you shouldn't name it a flag, and I think it's better to have a non-zero value as a constant.
By the way, the way of thinking may change depending on the system. For example, let's say you have a service that targets married families and that 99% of users are married. In such a case, based on the idea that "usually married", married may be 0 and unmarried may be 1. I think it is necessary to change it flexibly depending on the characteristics of the system to be created.
By the way, the urgency that I have considered with 3 choices so far, but the specifications have changed again after the release. I want to manage more in 10 stages instead of 3 stages.
Everyone is in a hurry. "Well, I've expressed it as -1, 0, 1 (in enum, it's LOW, NORMAL, HIGH), but it's -5 to 5 (although it's 11 steps)? Do you want to use it in the sense of -3, 0, 3?
However, with this importance, you can fully imagine the prospect of increasing the number of stages. When dealing with variables that have more choices in the future, there is a method of designing with intervals instead of assigning consecutive numbers to constants.
For example, assign constants -100, 0, 100 when designing the first three stages. Then you can increase it like -10, -20, or you can increase it like -200, -300. (When using enum, if you set parameters like LEVEL_0, LEBEL_1, the same incident will occur.)
Of course, if you design with such a gap, it will be difficult to understand "how many types of options are available in total". Also, when you first see this number, you may get stuck with "Hmm?".
It's okay to apply a patch, but the act of updating the actual user's data is nerve-wracking. In order to avoid such things as much as possible, it would be better to consider what can be understood at the design stage according to the way of thinking and climate of each organization.
Finally, I've talked about numbers here, but in real-world code you'll often use booleans. I think that 1/2 also often uses enums.
Is boolean a good choice when considering two-choice variables? Or should I have something different? I hope it will be a good source of judgment.
Recommended Posts