Ist es besser, eine Funktion aufzurufen, die zu diesem Zeitpunkt keine Auswirkung hat, WENN dies die Code-Klarheit verbessert?

60

Ich habe drei Ansichten in meinem Programm (iOS-App). Es ist immer nur einer von ihnen gleichzeitig aktiv, daher habe ich die Sichtbarkeit für zwei von ihnen deaktiviert und die Sichtbarkeit geändert, während der Benutzer die Tasten drückt. Die Ansichten werden als sichtbar initialisiert, sodass ich die Sichtbarkeit im Code ausschalte, bevor die Hauptansicht angezeigt wird.

ich kann

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

für zwei der Ansichten, aber jetzt ist die dritte (die zu Beginn der App sichtbar sein sollte) nicht angesprochen. Ich habe eine

[view3 setAlpha:1.0f];

nach den ersten beiden, weil ich denke, es hält klar, dass es tatsächlich drei Ansichten gibt, nicht zwei, wie man vielleicht denkt, wenn man den Code sieht. Wie machen andere Programmierer das? Ist es reine Präferenz oder gibt es einige Konventionen?

Wenn der Anruf sehr schwer ist, ist es natürlich besser, ihn nicht anzurufen, wenn dies nicht erforderlich ist, aber ich habe mich über kleine Dinge wie mein Beispiel gewundert.

coding-style clean-code

— Kevin
quelle

134

Sie haben eine Invariante:

Es ist immer nur eine Ansicht (von 3) aktiv (und sichtbar).

Dann schlage ich vor, dass Sie eine Funktion bereitstellen, um die Aktivität und Sichtbarkeit ALLER Ansichten auf einmal zu ändern:

[setActiveView viewID:2]

Diese Funktion wird:

Überprüfen Sie, ob die Ansicht bereits aktiv ist, um unnötige Arbeit zu vermeiden
Stellen Sie die Ansicht als aktiv und sichtbar ein
Setze die anderen 2 Ansichten als inaktiv und unsichtbar

Es hat mehrere Vorteile über einen rohen Anruf an setVisibility:

freundlich: unnötiges Aufrufen verursacht kein Leistungsproblem
defensiv: sein einzelner Parameter ist viel schwieriger zu verpfuschen, wohingegen setVisibilityes schwieriger ist, sich daran zu erinnern, dass der Wertebereich ist 0.0f - 1.0fund dass nur einer eingestellt werden muss1.0f
belastbar: der nächste kann nicht versehentlich eine der ansichten vergessen
anpassbar: Zum Hinzufügen / Entfernen einer Ansicht muss nicht der gesamte Anwendungscode überprüft werden, um herauszufinden, wo sich die Schalter befinden. Eine einzelne Funktion (diese) muss aktualisiert werden

Idealerweise sollte keine andere Funktion in der Lage sein, diese Einstellung zu ändern, um die Invariante zu erzwingen ...

— Matthieu M.
quelle

Toller Vorschlag. Ich mache das mit meinem aktuellen Beispiel. Aber was ist, wenn ein solches Design nicht möglich / gewünscht ist? Oder entscheiden Sie vor Ort, wie Sie am besten damit umgehen?

— Kevin

4

@ Kevin: Es kommt wirklich darauf an. Manchmal können Sie das Problem lösen, indem Sie eine Sammlung durchlaufen, manchmal jedoch nicht. Das Hauptprinzip besteht jedoch darin, Doppelungen zu vermeiden und die Aufbewahrung von Invarianten zu vereinfachen. Je mehr "manuelle" Aktionen gespeichert werden müssen, damit die Dinge richtig funktionieren, desto geringer ist die Wahrscheinlichkeit, dass die Dinge richtig funktionieren. Ich hasse es, hier vage zu sein, aber es gibt so viele verschiedene Situationen, dass ich befürchte, eine "generische" Regel würde Sie nur in die Irre führen.

— Matthieu M.

23

"Machen Sie es einfach, Invarianten zu erhalten" ist eine allgemeine Regel, an die Sie sich erinnern sollten.

— Gusdor

1

@Tonny: Ich weiß nicht, ob es richtig ist, die Verwendung einer globalen Variablen zu fördern, aber wenn Sie genau wissen, welche zuvor aktiv war, müssen Sie nur zwei Ansichten aktualisieren. Eine andere Lösung besteht darin, dass sich jede Ansicht an ihre Sichtbarkeit erinnert und setVisibilitynichts unternimmt, wenn die Sichtbarkeit bereits die angeforderte ist, wodurch die Verantwortung nach unten verlagert wird.

— Matthieu M.

1

@MatthieuM. Ich habe in Eile geschrieben, aber das habe ich auch gemeint. Wenn Sie den vorherigen Status kennen, müssen Sie höchstens 2 Ansichten aktualisieren. Wie man sich an diesen Zustand erinnert, ist eine andere Sache ;-). Verschieben der Verantwortung nach unten: Wenn die Ansichtsklasse dies nicht vorsieht, müssen Sie die Klasse in ein anderes Objekt einbinden, um diese Eigenschaft hinzuzufügen. Das ist eine saubere Lösung, aber vielleicht ein bisschen übertrieben.

— Tonny

12

Alternative Idee: Wenn Ihr Ziel darin besteht, das Auftreten von Fehlern zu verhindern, weil die Leute vergessen, dass es drei Ansichten gibt, und mit nur zwei davon etwas zu tun haben, das sie wirklich mit allen machen sollten, dann machen Sie eine Funktion, die es unmöglich macht, zu vergessen:

setViewVisibilities(0.0f, 0.0f, 1.0f)

Jetzt haben Sie etwas weitaus Stärkeres - Kompilierungszeitgarantien, die Sie nicht vergessen haben . Wenn Sie einen Parameter vergessen, werden Sie vom Compiler angeschrien. Dies ist weitaus nützlicher als Kommentare oder unnötiger Code, da ein streng benanntes Protokoll erstellt wird, das die von Ihnen gewünschte Eigenschaft erzwingt.

Für den Fall, view3dass die Sichtbarkeit nicht geändert werden muss, können Sie ein Verhalten hinzufügen, bei dem die Übergabe eines bestimmten Werts wie -1.0oder niloder etwas in diese Richtung bedeutet, dass die Sichtbarkeit der Ansicht überhaupt nicht geändert wird. Dies umgeht das Problem des unnötigen Einstellens von Sichtbarkeiten.

— Jack
quelle

9

Wenn OP mehr als 10 Ansichten hat, kann ein Parameter pro Ansicht nicht mehr verwaltet werden. Ihr Hinweis zu Kompilierungsfehlern ist korrekt, aber dies ist leider eine sehr unhaltbare Lösung.

— Chris Cirefice

3

@ChrisCirefice: Wenn die Anzahl der Ansichten zunimmt, können Sie eine Art "ViewState" -Objekt / -Klasse erstellen, die diese Invariante erzwingt. Verwenden Sie das dann zum Umschalten usw. Bei so vielen Ansichten ist eine Art Managerobjekt wahrscheinlich trotzdem sinnvoll.

— sleske

8

Ich würde glauben, dass es am besten ist, einen Kommentar hinzuzufügen, der erklärt, dass der Anruf nicht benötigt wird (und warum).

^{(Vielleicht ist die Tatsache, dass ein Anruf nicht benötigt wird oder dass Sie einen Kommentar dazu benötigen, ein Codegeruch.)}

— Basile Starynkevitch
quelle

1

@Niall Wenn möglich, wäre eine Behauptung sogar besser als ein Kommentar.

— 200_success

9

Kommentare sind nicht die Lösung für nicht verwaltbaren und nicht lesbaren Code

— dj18

2

@ Kevin oder Sie könnten Code schreiben, der ohne Kommentare perfekt lesbar ist.

— Jan

1

@ Jan Kommentare sind mehr als nur zu erklären, was Code macht .......

— Kevin

2

@ Kevin Ich würde sagen, Kommentare sollten niemals existieren, um zu erklären, was Code tut, sondern um zu erklären, warum er es tut. Und in solchen Situationen bringt ein Refaktor die Absicht oft zum Ausdruck, ohne dass ein Kommentar erforderlich ist (was nach Jan's Argument klingt).

— RJFalconer

4

In diesem speziellen Fall hat @Mattieu M. die richtige Lösung.

Im allgemeineren Fall, in dem es keine ähnliche Transformation gibt, müssen Sie sich fragen: Gibt es eine Chance, dass ein zukünftiger Programmierer dies vermasselt?

Die Antwort lautet normalerweise ja. Das heißt, ja, Sie sollten den Anruf hinzufügen. Möglicherweise beginnt eine zukünftige Version des Frameworks mit allen Sichten auf OFF anstatt auf ON.

— Stig Hemmer
quelle