I see a convention that Bool type variable names and function names should be names that can be expected to be true. For example, use is + noun phrases, adjectives (or adjectives only), past participles, and so on. Here, we consider applying this convention by giving an example in which true is difficult to assume. By the way, I think it's a matter of taste as to whether or not to add is.
public void Main()
{
bool findFlg = true;
bool blnFind = true;
bool finded = true;
bool result = false;
bool notFound = false;
//The meaning of the flag cannot be read from the NG variable name.
if (findFlg == true)
{
}
//The meaning of the flag cannot be read from the NG variable name.
if (blnFind == true)
{
}
//△ The past participle is found. I understand the meaning.
if (finded)
{
}
//The meaning of the flag cannot be read from the NG variable name.
if (!result)
{
}
//Because NG denial is set to true, it is a double negation.
if (!notFound)
{
}
int resultType = 1;
bool success;
//NG useless if statement
if (resultType == 1)
{
success = true;
}
else
{
success = false;
}
bool beAbleToDo = true;
//△ It does not violate the rules, but it is too long. Can is fine.
if (beAbleToDo)
{
}
}
public void Main()
{
bool found = true;
//By using the past participle, you can find it to be true.
if (found)
{
}
//The magic number should be a constant, but leave it as it is in the sample.
int resultType = 1;
//The meaning can be understood even if it remains success, but it is made an adjective.
bool successful;
successful = (resultType == 1);
//It's simpler to use can instead of be able to.
bool canDo = true;
if (canDo)
{
}
}
There are many people who name ... Check for the check processing function that returns a bool value. Please be aware that this is a Bool-type violation of the rules. As an example, input check is performed, and if the value is invalid, the sample code that exits the process is given.
void Main(string inputValue)
{
//It's hard to read when it's time to return NG true. Also, it is NG to compare with false.
if (InputCheck(inputValue) == false)
{
return;
}
//△ It is OK because it is not a double negation, but there is a possibility that else or double negation will occur in the future.
if (IsInvalid(inputValue))
{
}
//OK There is no subject, but it turns out that it is a value validation check
if (!IsValid(inputValue))
{
return;
}
//OK There is a subject and it turns out that it is a value validation
if (!IsValueValid(inputValue))
{
return;
}
}
The name InputCheck => InputCheck can be understood as an idea, but it cannot explain the return value of bool type. Please note that the naming convention is the same whether it is a bool type variable or a function. By the way, IsInvalid sets the invalid value to true, and it looks fine on the sample code. It is not recommended to add else or negate it as it will reduce readability.
According to the convention, bool type variable names can be coded and read with almost no hassle. On the other hand, the sample code marked with △ is trying to comply with the rules, and the meaning is understood, so it may be OK in the code review.
Also note that function names that return a bool type follow the same naming convention as variables. Especially ... Check will appear no matter how many times you point it out, so be careful not to write it.
I have received opinions from the field that the rules are simple but difficult. Perhaps for programmers who haven't escaped from the VB6 era, the code written in NG is easy to read and can't be changed anymore.
Previous article (easy null check)
Next article (too many function arguments)
Recommended Posts