[JAVA] Écrire du code facile à maintenir (partie 4)

1. De quoi parler cette fois

2. Collection de techniques

2. Ne nommez pas de variables qui ne sont pas 0 ou 1 (= vrai ou faux) "~ flag"

Imaginez un instant.

Désormais, vous allez créer une fonction pour gérer une certaine tâche (ToDo). Pour chacune de ces tâches, quelles variables devraient être définies pour indiquer l'état d'achèvement («terminé» ou «incomplet»)? De plus, quel type de variables faut-il définir pour représenter l'urgence de chaque tâche («urgente» et «normale»)? On suppose que ces deux variables n'ont toujours que ces deux valeurs.

python


//Drapeau d'achèvement
boolean completeFlag;
//Drapeau d'urgence
boolean emergencyFlag;

Eh bien, ça ressemble à ça. Ensuite, que se passe-t-il si les spécifications changent ici et que vous souhaitez avoir trois niveaux d'urgence: «élevé», «normal» et «faible»? Voulez-vous démarrer l'implémentation avec ce nom de variable?

Les drapeaux sont dits "variables qui contiennent des informations qui peuvent être exprimées en un bit". Le nom «~ flag» a forcément un préjugé de deux choix. Ce préjugé peut conduire à des erreurs de mise en œuvre lorsque vous êtes pressé ou pressé. Évitez les noms qui peuvent être facilement mal compris. S'il y a un tel changement de spécification (si changer le nom de la variable n'a pas un grand impact sur le projet), je pense que le nom devrait être changé pour cette machine. Par exemple, «urgence Lebel» ou «type d'urgence»?

Au fait, si vous avez trois choix ou plus comme celui-ci, vous pouvez comprendre que le nom ~ drapeau n'est pas utilisé. Mais qu'en est-il de 1 ou 2 choix? Je pense que c'est un désaccord.

Dans mon sens personnel, je ne pense pas que vous devriez utiliser l'indicateur de nom ou le type booléen pour 1 ou 2 choix. Je voudrais continuer dans la section suivante.

2.2.0 Différences de réflexion entre 0 ou 1 variable et 1 ou 2 variables

Maintenant, dans la section 1, nous avons expliqué le "drapeau d'achèvement" et le "drapeau d'urgence" comme exemples. Tout le monde a donc un problème. Quel est le nom du «genre»? Quel type d'expressions logiques et de valeurs numériques attendez-vous pour chacun?

Eh bien, cela est souvent appelé «sexe» ou «sexe». Il devrait y avoir peu d'occasions de le nommer maleFlag ou femaleFlag.

Donc, si vous le nommez gender, voulez-vous que la valeur soit 0 ou 1? Voulez-vous 1 ou 2?

Personnellement, je pense que c'est "1 ou 2".

Alors pourquoi 0 ou 1 n'est-il pas bon? (Est-ce que je ne l'accepte pas physiologiquement?)

J'ai réfléchi à la différence entre l'idée de cette variable 0/1 et la variable 1/2. Je pense que la différence entre ces deux points réside dans les deux points suivants au sens large.

・ Si les deux options sont équivalentes ・ La valeur est-elle biaisée d'un côté ou de l'autre (y a-t-il une hypothèse qu'elle est biaisée?)

Dans le monde des systèmes, 0 est quelque chose de spécial. En parlant de Java int, la valeur initiale est 0. Le numéro 0 entre sans rien faire. En d'autres termes, 0 et 1 sur 0/1 ont une grande différence entre «ne rien faire» et «faire quelque chose». Dans cette façon de penser, le «drapeau d'achèvement» dans la tâche d'ouverture est exactement cette façon de penser. La conception est telle que 0 est défini lorsqu'une tâche se produit (= lorsque rien n'a encore été fait), et 1 est défini lorsqu'elle est terminée.

Cependant, les hommes et les femmes sont du même rang. Il existe aussi (essentiellement) en 50-50. Mettre un homme à 0 signifie un scintillement, comme "principalement des hommes" ou "tout le monde commence par un homme". L'inverse est également vrai. Je pense que c'est la différence entre le "drapeau d'achèvement" et le "mâle et femelle".

En d'autres termes, le drapeau a une forte impression qu'il marque un état inhabituel ou un lieu qui a changé par rapport à l'état initial, et chaque option est plate ou a un vecteur complètement différent. Par exemple, vous ne devriez pas le nommer un indicateur, et je pense qu'il est préférable d'avoir une valeur non nulle comme constante.

À propos, la façon de penser peut changer en fonction du système. Par exemple, disons que vous avez un service qui cible les familles mariées et que 99% des utilisateurs sont mariés. Dans un tel cas, sur la base de l'idée que «généralement marié», marié peut être 0 et célibataire peut être 1. Je pense qu'il est nécessaire de le modifier de manière flexible en fonction des caractéristiques du système à créer.

2.3 Considérons comment allouer chaque constante lors de la création d'une variable qui met une valeur numérique autre que 0 ou 1 comme "type" et "state".

Au fait, l'urgence que j'ai envisagée avec 3 choix jusqu'à présent, mais les spécifications ont encore changé après la sortie. Je veux en gérer plus en 10 étapes au lieu de 3 étapes.

Tout le monde est pressé. "Eh bien, je l'ai exprimé comme -1, 0, 1 (enum, c'est BAS, NORMAL, HAUT), mais c'est -5 à 5 (bien que ce soit 11 étapes)? Voulez-vous l'utiliser dans le sens de -3, 0, 3?

Cependant, avec cette importance, vous pouvez pleinement imaginer la perspective d'augmenter le nombre d'étapes. Lorsqu'il s'agit de variables qui ont plus de choix à l'avenir, il existe une méthode de conception avec des intervalles au lieu d'affecter des nombres consécutifs à des constantes.

Par exemple, lors de la conception des trois premières étapes, attribuez des constantes de -100, 0, 100. Ensuite, vous pouvez l'augmenter comme -10, -20, ou vous pouvez l'augmenter comme -200, -300. (Lorsque vous utilisez enum, si vous définissez des paramètres tels que LEVEL_0 et LEBEL_1, le même incident se produira.)

Bien sûr, si vous concevez avec un tel écart, il sera difficile de comprendre "combien de types d'options sont disponibles au total". De plus, lorsque vous voyez ce numéro pour la première fois, vous risquez de rester bloqué avec "Hmm?".

Il est normal d'appliquer un correctif, mais la mise à jour des données de l'utilisateur réel est angoissante. Afin d'éviter autant que possible de telles choses, il serait préférable de considérer ce qui peut être compris au stade de la conception en fonction de la façon de penser et du climat de chaque organisation.

Enfin, j'ai parlé de nombres ici, mais dans le code du monde réel, vous utiliserez souvent borean. Je pense que 1/2 utilise également enum dans de nombreux cas.

Le booléen est-il bon lorsque l'on considère des variables à deux choix? Ou devrais-je avoir quelque chose de différent? J'espère que ce sera une bonne source de jugement.

Recommended Posts

Écrire du code facile à maintenir (partie 1)
Écrire du code facile à maintenir (partie 4)
Écrire du code facile à maintenir (partie 3)
Écrivons un code facile à maintenir (Partie 2) Nom
Écrire du code difficile à tester
Code difficile à déboguer et à analyser
Pensez à un code de test facile à comprendre grâce au test de Comparator
Facile à entretenir FizzBuzz
Comment écrire du bon code
Nouvelles fonctionnalités de Java 14 pouvant être utilisées pour écrire du code
[Java] Code difficile à remarquer mais terriblement lent
La fonction est très facile à utiliser
Comment rédiger un code facile à comprendre [Résumé 3]
Comment identifier le chemin sur lequel il est facile de se tromper
Comment écrire du code de test avec la certification de base
Règles de base à connaître pour écrire du code facile à lire
Pour implémenter, écrivez le test puis codez le processus
Utilisez stream pour vérifier que SimpleDateFormat est thread unsafe
Easy Null Check-Je veux vous donner une chance d'écrire du bon code. 6 [Exemple de refactoring C #]