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?

60

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

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 adressée. Je mets un

[view3 setAlpha:1.0f];

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

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

coding-style clean-code

— Kevin
source

134

Vous avez un invariant:

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

Ensuite, je vous suggère de fournir une fonction permettant de basculer simultanément l’activité et la visibilité de TOUTES les vues:

[setActiveView viewID:2]

Cette fonction va:

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

Il présente de nombreux avantages par rapport à un appel brut à setVisibility:

convivial: l'appeler inutilement ne crée pas de problème de performance
defensive: son unique paramètre est beaucoup plus difficile à rater, alors que pour setVisibilityil est plus difficile de se rappeler que la plage de valeurs est 0.0f - 1.0fet que seule une doit être définie sur1.0f
résilient: le prochain gars ne peut pas oublier accidentellement l'un des points de vue
adaptable: l'ajout / la suppression d'une vue ne nécessite pas de scruter tout le code de l'application pour rechercher l'emplacement des commutateurs; une seule fonction (celle-ci) doit être mise à jour

Idéalement, pour aider à appliquer l'invariant, aucune autre fonction ne devrait pouvoir gâcher ce paramètre ...

— Matthieu M.
source

Grande suggestion. Je vais le faire avec mon exemple actuel. Mais qu'en est-il lorsqu'un tel projet n'est pas possible / souhaité? Ou décidez-vous sur place quel est le meilleur moyen de le gérer?

— Kevin

4

@ Kevin: Cela dépend vraiment. Parfois, vous pouvez résoudre le problème en effectuant une itération sur une collection, parfois non, mais le principe clé consiste à éviter les doublons et à faciliter la préservation des invariants. Plus vous avez à vous rappeler d’actions "manuelles" pour que les choses fonctionnent correctement, moins vous avez de chances que les choses fonctionnent correctement. Je n'aime pas être vague ici, mais il y a tellement de situations différentes que je crains qu'une règle "générique" ne vous induise en erreur.

— Matthieu M.

23

"Facilitez la préservation des invariants" est une règle générique à retenir.

— Gusdor

1

@ Tonny: Je ne sais pas si encourager l'utilisation d'une variable globale, c'est "bien faire les choses", mais si vous savez exactement ce qui était actif auparavant, il vous suffit de mettre à jour deux vues. Une autre solution consiste pour chaque vue à se rappeler sa visibilité et setVisibilityà ne rien faire si la visibilité est déjà celle demandée, ce qui diminue la responsabilité.

— Matthieu M.

1

@MatthieuM. J'ai écrit à la hâte, mais c'est ce que je voulais dire aussi. Si vous connaissez l'état précédent, il vous suffit de mettre à jour la vue 2 au maximum. Comment se souvenir de cet état est une autre affaire ;-). En ce qui concerne le transfert de la responsabilité vers le bas: si la classe de vue ne le prévoit pas, vous devrez envelopper la classe dans un autre objet pour ajouter cette propriété. C'est une solution propre, mais peut-être un peu exagérée.

— Tonny

12

Idée alternative: si votre objectif est d'empêcher l'apparition de bugs parce que les utilisateurs oublient trois vues et agissent avec deux vues seulement, ils doivent en faire une, puis créez une fonction qui rend impossible d'oublier:

setViewVisibilities(0.0f, 0.0f, 1.0f)

Maintenant, vous avez quelque chose de beaucoup plus puissant - Compiler le temps vous garantit que vous n’avez pas oublié . Si vous oubliez un paramètre, le compilateur vous hurle dessus. Ceci est bien plus utile que les commentaires ou le code inutile, car il crée un protocole nommé strict qui applique la propriété qui vous tient à cœur.

Pour le cas où view3n'a pas besoin de sa visibilité a changé, vous pouvez ajouter un comportement où passer une valeur spéciale comme -1.0ou nilou quelque chose le long de ces moyens lignes « ne changent pas la visibilité de vue du tout ». Cela contourne le problème de la définition de visibilités inutilement.

— Jack
source

9

Si OP obtient plus de 10 vues, un paramètre par vue deviendra impossible à gérer. Votre remarque sur les erreurs de compilation est correcte, mais il s’agit malheureusement d’une solution très difficile à maintenir.

— Chris Cirefice

3

@ChrisCirefice: Si le nombre de vues augmente, vous pouvez créer une sorte d'objet / classe "ViewState", qui applique cet invariant. Puis utilisez-le pour changer de position, etc. Avec autant de vues, un type d’objet gestionnaire a probablement un sens.

— Sleske

8

Je pense que l'ajout d'un commentaire expliquant que l'appel n'est pas nécessaire (et pourquoi) est préférable.

^{(peut-être que 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)}

— Basile Starynkevitch
source

1

@Niall Si possible, une assertion serait encore mieux qu'un commentaire.

— 200_success

9

Les commentaires ne sont pas la solution pour un code impossible à maintenir et illisible

— dj18

2

@ Kevin ou vous pourriez écrire du code parfaitement lisible sans commentaires.

— Jan

1

@Jan Les commentaires ne se limitent pas à expliquer le code utilisé .......

— Kevin,

2

@ Kevin Je dirais que les commentaires ne devraient jamais exister pour expliquer ce que fait le code, mais plutôt pour expliquer pourquoi il le fait. Et dans de telles situations, souvent un refactor fera passer l'intention sans avoir besoin de commentaire (ce qui ressemble au point de Jan).

— RJFalconer

4

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 poser la question suivante: y a-t-il une chance qu'un futur programmeur puisse gâcher cela?

La réponse est généralement oui. Ce qui signifie, oui, vous devriez ajouter l'appel. Peut-être qu'une version future du cadre commence avec toutes les vues désactivées au lieu de activées.

— Stig Hemmer
source