Je vois une convention selon laquelle les noms de variables de type Bool et les noms de fonctions doivent être des noms dont on peut s'attendre à ce qu'ils soient vrais. Par exemple, utilisez is + nomenclature, adjectifs (ou adjectifs uniquement), anciens participants, etc. Ici, nous envisagerons d'appliquer cette convention en donnant un exemple dans lequel true est difficile à supposer. Soit dit en passant, je pense que c'est une question de goût d'ajouter ou non.
public void Main()
{
bool findFlg = true;
bool blnFind = true;
bool finded = true;
bool result = false;
bool notFound = false;
//La signification de l'indicateur ne peut pas être lue à partir du nom de la variable NG.
if (findFlg == true)
{
}
//La signification de l'indicateur ne peut pas être lue à partir du nom de la variable NG.
if (blnFind == true)
{
}
//△ La partie passée est trouvée. Je comprends le sens.
if (finded)
{
}
//La signification de l'indicateur ne peut pas être lue à partir du nom de la variable NG.
if (!result)
{
}
//Puisque le refus NG est défini sur true, il s'agit d'un double refus.
if (!notFound)
{
}
int resultType = 1;
bool success;
//NG inutile si déclaration
if (resultType == 1)
{
success = true;
}
else
{
success = false;
}
bool beAbleToDo = true;
//△ Cela ne viole pas les règles, mais c'est trop long. Can, c'est bien.
if (beAbleToDo)
{
}
}
public void Main()
{
bool found = true;
//En utilisant la partie passée, vous pouvez trouver que c'est vrai.
if (found)
{
}
//Le nombre magique doit être constant, mais laissez-le tel quel dans l'échantillon.
int resultType = 1;
//Le sens peut être compris même s'il reste un succès, mais il est transformé en acronyme.
bool successful;
successful = (resultType == 1);
//C'est plus simple à utiliser au lieu de pouvoir le faire.
bool canDo = true;
if (canDo)
{
}
}
De nombreuses personnes nomment la fonction de traitement des chèques qui renvoie la valeur booléenne comme ... Vérifier. Veuillez noter qu'il s'agit d'une violation de type booléen des règles. À titre d'exemple, une vérification d'entrée est effectuée et si la valeur n'est pas valide, l'exemple de code qui quitte le processus est donné.
void Main(string inputValue)
{
//Il est difficile de lire quand il est temps de renvoyer NG true. En outre, il est NG de comparer avec faux.
if (InputCheck(inputValue) == false)
{
return;
}
//△ C'est OK car ce n'est pas un double déni, mais il y a une possibilité qu'un autre ou un double déni se produise à l'avenir.
if (IsInvalid(inputValue))
{
}
//OK Il n'y a pas de sujet, mais il s'avère qu'il s'agit d'un contrôle de validité de valeur
if (!IsValid(inputValue))
{
return;
}
//OK Il y a un sujet et il s'avère que c'est un contrôle de validité de valeur
if (!IsValueValid(inputValue))
{
return;
}
}
Le nom InputCheck => InputCheck peut être compris comme une idée, mais il ne peut pas expliquer la valeur de retour de type booléen. Veuillez noter que la convention de dénomination est la même qu'il s'agisse d'une variable de type booléen ou d'une fonction. À propos, IsInvalid définit la valeur non valide sur true, et cela semble correct sur l'exemple de code. Nous ne recommandons pas d'en ajouter ou de le refuser car cela réduirait la lisibilité.
Selon la convention, les noms de variables de type booléen peuvent être codés et lus sans tracas. D'autre part, l'exemple de code marqué avec △ tente de se conformer aux règles et la signification est comprise, donc cela peut être OK dans la révision du code.
Notez également que les noms de fonction qui renvoient des types booléens suivent les mêmes conventions de dénomination que les variables. Surtout ... Le chèque apparaîtra peu importe le nombre de fois que vous le signalerez, alors faites attention à ne pas l'écrire.
J'ai reçu l'avis que les règles sont simples mais difficiles. Peut-être pour les programmeurs qui n'ont pas échappé à l'ère VB6, le code écrit en NG est facile à lire et ne peut plus être changé.
Article précédent (vérification facile des null)
Article suivant (trop d'arguments de fonction)
Recommended Posts