web-dev-qa-db-fra.com

Est-il préférable d'appeler une fonction qui n'a pas d'effet à ce stade, SI cela améliore la clarté du code?

J'ai trois vues dans mon programme (application iOS). Un seul d'entre eux est toujours actif en même temps, j'ai donc désactivé la visibilité pour deux d'entre eux et je change de visibilité lorsque l'utilisateur appuie sur les boutons. Les vues sont initialisées comme visibles, j'ai donc désactivé la visibilité dans le code avant que la vue principale ne s'affiche.

Je peux faire

[view1 setAlpha:0.0f];
[view2 setAlpha:0.0f];

pour deux des vues, mais maintenant la troisième (celle qui devrait être visible au début de l'application) n'est pas traitée. Je mets un

[view3 setAlpha:1.0f];

après les deux premiers, parce que je pense qu'il est clair qu'il y a en fait trois points de vue, pas deux comme on pourrait le penser en voyant le code. Comment les autres programmeurs font-ils cela? Est-ce purement une préférence ou existe-t-il des conventions?

Si l'appel est très lourd, il est évidemment préférable de ne pas l'appeler lorsque ce n'est pas nécessaire, mais je me posais des questions sur de petites choses comme mon exemple.

coding-styleclean-code
60
Kevin

Vous avez un invariant:

Une seule vue (sur 3) est toujours active (et visible).

Ensuite, je vous suggère de fournir une fonction pour changer l'activité et la visibilité de TOUTES les vues à la fois:

[setActiveView viewID:2]

Cette fonction:

  • vérifier si la vue est déjà active, en évitant les travaux inutiles
  • définir la vue comme active et visible
  • définir les 2 autres vues comme inactives et invisibles

Il présente plusieurs avantages à propos d'un appel brut à setVisibility:

  • convivial: l'appeler inutilement ne crée pas de problème de performances
  • défensif: son paramètre unique est beaucoup plus difficile à bâcler, tandis que pour setVisibility, il est plus difficile de se rappeler que la plage de valeurs est 0.0f - 1.0f et qu'un seul doit être défini sur 1.0f
  • résilient: le prochain gars ne peut pas accidentellement oublier l'une des vues
  • adaptable: ajouter/supprimer une vue ne nécessite pas de scruter tout le code de l'application pour trouver où se trouvent les commutateurs, une seule fonction (celle-ci) doit être mise à jour

Idéalement, pour aider à faire respecter l'invariant, aucune autre fonction ne devrait être capable de gâcher ce paramètre ...

134
Matthieu M.

Autre idée: si votre objectif est d'empêcher les bugs de se produire parce que les gens oublient qu'il y a trois vues et font quelque chose avec seulement deux d'entre eux qu'ils devraient vraiment faire avec chacun d'eux, alors créez une fonction qui le rend impossible oublier:

setViewVisibilities(0.0f, 0.0f, 1.0f)

Maintenant, vous avez quelque chose de beaucoup plus puissant - le temps de compilation garantit que vous n'avez pas oublié. Si vous oubliez un paramètre, le compilateur vous crie dessus. C'est beaucoup plus utile que les commentaires ou le code inutile, car cela crée un protocole nommé strict qui applique la propriété qui vous intéresse.

Pour le cas où view3 n'a pas besoin que sa visibilité soit modifiée, vous pouvez ajouter un comportement en passant une valeur spéciale comme -1.0 ou nil ou quelque chose dans ce sens signifie "ne changez pas du tout la visibilité de la vue". Cela permet de contourner inutilement le problème de la définition des visibilités.

12
Jack

Je pense qu'il serait préférable d'ajouter un commentaire expliquant que l'appel est inutile (et pourquoi).

(peut-être, le fait qu'un appel ne soit pas nécessaire, ou que vous ayez besoin d'un commentaire à ce sujet, pourrait être une odeur de code)

8
Basile Starynkevitch

Dans ce cas particulier, @Mattieu M. a la bonne solution.

Dans le cas plus général, où il n'y a pas de transformation similaire, vous devez vous demander: Y a-t-il tout chance qu'un futur programmeur pourrait gâcher cela?

La réponse est généralement oui. Ce qui signifie que oui, vous devez ajouter l'appel. Peut-être qu'une future version du framework commencera avec toutes les vues OFF au lieu de ON.

4
Stig Hemmer