it-swarm.dev

Soll ich Variablen wiederverwenden?

Soll ich Variablen wiederverwenden?

Ich weiß, dass viele Best Practices besagen, dass Sie dies später nicht tun sollten, wenn verschiedene Entwickler den Code debuggen und drei Variablen haben, die gleich aussehen. Der einzige Unterschied besteht darin, dass sie an verschiedenen Stellen im Code erstellt werden verwirrt. Unit-Tests sind ein gutes Beispiel dafür.

Ich do weiß jedoch, dass Best Practices die meiste Zeit dagegen sind. Zum Beispiel sagen sie, Methodenparameter nicht zu "überschreiben".

Best Practices sind sogar gegen das Nullstellen der vorherigen Variablen (in Java gibt es Sonar, das eine Warnung ausgibt, wenn Sie der Variablen null zuweisen, dass Sie dies nicht tun müssen) um den Garbage Collector aufzurufen seit Java 6. Sie können nicht immer steuern, welche Warnungen deaktiviert sind; meistens ist die Standardeinstellung aktiviert.)

60
IAdapter

Ihr Problem tritt nur auf, wenn Ihre Methoden lang sind und mehrere Aufgaben in einer Sequenz ausführen. Dies macht es schwieriger, den Code per se zu verstehen (und somit zu pflegen). Die Wiederverwendung von Variablen erhöht darüber hinaus das Risiko, den Code noch schwerer zu befolgen und fehleranfälliger zu machen.

Die beste Vorgehensweise von IMO besteht darin, ausreichend kurze Methoden zu verwenden, die nur eines bewirken und das gesamte Problem beseitigen.

130
Péter Török

Die variable Wiederverwendung in einer Methode ist ein starkes Zeichen dafür, dass Sie sie umgestalten/teilen sollten.

Meine Antwort wäre also, dass Sie sie nicht wiederverwenden sollten, denn wenn Sie dies tun, wäre es viel schwieriger, sie später umzugestalten.

49

Es hängt davon ab, ob.

Einige Variablen können genau zum Zweck der Speicherung einer bestimmten Art von Daten erstellt werden, die sich während der Ausführung einer Funktion ändern können. Hier kommen beispielsweise Rückkehrcodes in den Sinn:

void my_function() {
    HRESULT errorcode;
    errorcode = ::SomeWindowsApiFunction();
    if (FAILED(errorcode)) { /* handle error */ }
    errorcode = ::AnotherWindowsApiFunction();
    if (FAILED(errorcode)) { /* handle error */ }
}

Der Variablenname macht sehr deutlich, was diese Variable speichern soll. Ich denke, andere Anwendungsfälle wie dieser sind möglich, bei denen eine Variable konzeptionell ein Container ist, der logisch von verschiedenen Instanzen sehr ähnlicher Dinge im Verlauf einer Funktion verwendet wird.

Im Allgemeinen sollte dies jedoch nur unter Umständen erfolgen, unter denen es möglichen Lesern des Codes absolut klar ist. In keinem Fall, außer vielleicht einer extremen Optimierung ohne Berücksichtigung der Lesbarkeit des Codes, sollte eine Variable wiederverwendet werden, nur weil der Typ passt.

All dies ergibt sich im Wesentlichen aus bewährten Methoden für die Benennung von Variablen. Namen sollten für sich selbst sprechen. Wenn es schwierig ist, den genauen Zweck für alle Wiederverwendungen in einem Kurznamen anzugeben, ist es am besten, nur unterschiedliche Variablen zu verwenden.

19
Felix Dombek

Der Hauptgrund, warum ich Variablen nicht wiederverwendete (insbesondere bei Komponententests), ist die Einführung eines unnötigen Codepfads, der schwer zu testen und zu debuggen ist. Ein guter Komponententest sollte unabhängig von anderen Tests sein. Wenn Sie eine Variable auf Klassen- (Instanz-) Ebene in einem Komponententestgerät wiederverwenden, müssen Sie vor jedem Test sicherstellen, dass der Status bestätigt wird. Ein guter Komponententest isoliert auch Fehler, sodass theoretisch jeder Testfall (jede Methode) nur 1 Verhalten für das zu testende System bestätigen sollte. Wenn Ihre Testmethoden so geschrieben sind, besteht selten die Notwendigkeit oder der Vorteil, eine Variable auf Methodenebene wiederzuverwenden. In Sprachen, die Schließungen und asynchrone Verarbeitung unterstützen, ist es wirklich schwierig zu überlegen, was zum Teufel los ist, wenn Sie Variablen in einer Methode wiederverwenden.

15
sbrenton

Sie sollten verschiedene Variablen verwenden. Wenn Sie befürchten, dass Ihr Kollege verwirrt wird, geben Sie ihm Namen, die seine Rollen klar abdecken.
Die Wiederverwendung von Variablen ist in Zukunft eine wahrscheinliche Quelle der Verwirrung. besser jetzt aufklären.
In einigen Fällen kann derselbe Variablenname wiederverwendet werden. Zum Beispiel i in einer einfachen Zählschleife. In diesen Fällen sollten Sie natürlich sicherstellen, dass sich die Variablen in ihrem eigenen Bereich befinden.

BEARBEITEN: Die Wiederverwendung von Variablen ist manchmal ein Zeichen dafür, dass das Single Responsibility Principle verletzt wird. Überprüfen Sie, ob die wiederverwendete Variable in derselben Rolle verwendet wird. Wenn dies der Fall ist, kann es möglicherweise überhaupt nicht wiederverwendet werden (obwohl es immer noch vorzuziehen ist, zwei verschiedene Variablen zu haben, um den Umfang dieser Variablen einzuschränken). Wenn es in verschiedenen Rollen verwendet wird, liegt eine SRP-Verletzung vor.

Es gibt eine Situation, in der Sie eine Variable ungeachtet der guten Ratschläge anderer Antworten wiederverwenden möchten: Wenn Ihr Compiler eine helfende Hand benötigt.

In einigen Fällen ist Ihr Compiler möglicherweise nicht klug genug, um zu erkennen, dass eine bestimmte vom Register zugewiesene Variable vom nächsten Teil des Codes nicht mehr verwendet wird. Daher wird dieses theoretisch freie Register für die nächsten Variablen nicht wiederverwendet, und der generierte Code ist möglicherweise nicht optimal.

Beachten Sie, dass ich keine aktuellen Mainstream-Compiler kenne, die diese Situation nicht richtig erfassen. Tun Sie dies also niemals, es sei denn, Sie wissen, dass Ihr Compiler suboptimalen Code generiert. Wenn Sie für spezielle eingebettete Systeme mit benutzerdefinierten Compilern kompilieren, tritt dieses Problem möglicherweise immer noch auf.

4

Ich würde NEIN sagen.

Denken Sie an dieses Szenario: Ihr Programm ist abgestürzt, und Sie müssen herausfinden, was passiert ist, indem Sie einen Core-Dump untersuchen. Können Sie den Unterschied erkennen? ;-);

2
fortran

Nein, Sie verbessern nicht den Code, den der Computer ausführt (... den Assembly-Code). Überlassen Sie die Wiederverwendung des vom Compiler für die Variable verwendeten Speichers dem Compiler. Sehr oft wird es ein Register sein, und die Wiederverwendung hat dir nichts gekauft. Konzentrieren Sie sich darauf, den Code leichter lesbar zu machen.

2
Rawbert

Es hängt davon ab, ob. In einer dynamischen Sprache, in der sich der Typ eher auf Werten als auf Variablen befindet, hätte ich ein gut benanntes Argument für eine Funktion, die beispielsweise eine Zeichenfolge war. Eine Änderung des Algorithmus bedeutete, dass er immer verwendet wurde, nachdem er als Ganzzahl interpretiert wurde, und dann als erster Entwurf das Äquivalent von

scrote = int (scrote)

Aber ich würde irgendwann versuchen, den an die Funktion gesendeten Typ zu ändern und die Änderung des Parametertyps zu notieren.

0
Paddy3118

Schauen Sie sich zunächst Ihre Entwicklungsumgebung an. Wenn Sie Probleme beim Debuggen haben, weil Sie fünf Variablen in verschiedenen Bereichen mit identischen Namen haben und der Debugger Ihnen nicht anzeigt, welche dieser Variablen Sie benötigen, verwenden Sie keine fünf Variablen mit demselben Namen. Es gibt zwei Möglichkeiten, dies zu erreichen: Verwenden Sie eine Variable oder fünf verschiedene Namen.

Ihr Debugger kann es auch schmerzhaft machen, eine Funktion mit vielen Variablen zu debuggen. Wenn eine Funktion mit 20 Variablen schwieriger zu debuggen ist als eine mit 16 Variablen, können Sie 5 Variablen durch eine ersetzen. ("Könnte berücksichtigen" ist nicht dasselbe wie "sollte immer").

Es ist Ok, eine Variable an mehreren Stellen verwenden zu lassen, solange die Variable immer den gleichen Zweck hat. Wenn beispielsweise zehn Funktionsaufrufe einen Fehlercode zurückgeben, der bei jedem Aufruf sofort behandelt wird, Verwenden Sie eine Variable und nicht 10. Verwenden Sie jedoch nicht dieselbe Variable für völlig andere Zwecke. Wenn Sie beispielsweise "Name" für einen Kundennamen und 10 Zeilen später dieselbe Variable für einen Firmennamen verwenden, ist dies schlecht und bringt Sie dazu Schlimmer noch: Verwenden Sie "customerName" für einen Kundennamen und 10 Zeilen später dieselbe Variable "customerName" für einen Firmennamen.

Wichtig ist, dass nichts eine eiserne Regel ist. Alles hat Vor- und Nachteile. Wenn "Best Practices" eine Sache nahe legen und Sie Gründe haben zu sagen, dass dies in Ihrer spezifischen Situation eine schlechte Idee ist, dann tun Sie es nicht.

0
gnasher729

Schauen Sie sich zunächst Ihre Entwicklungsumgebung an. Wenn Sie Probleme beim Debuggen haben, weil Sie fünf Variablen in verschiedenen Bereichen mit identischen Namen haben und der Debugger Ihnen nicht anzeigt, welche dieser Variablen Sie benötigen, verwenden Sie keine fünf Variablen mit demselben Namen. Es gibt zwei Möglichkeiten, dies zu erreichen: Verwenden Sie eine Variable oder fünf verschiedene Namen.

Ihr Debugger kann es auch schmerzhaft machen, eine Funktion mit vielen Variablen zu debuggen. Wenn eine Funktion mit 20 Variablen schwieriger zu debuggen ist als eine mit 16 Variablen, können Sie 5 Variablen durch eine ersetzen. ("Könnte berücksichtigen" ist nicht dasselbe wie "sollte immer").

Es ist Ok, eine Variable an mehreren Stellen verwenden zu lassen, solange die Variable immer den gleichen Zweck hat. Wenn beispielsweise zehn Funktionsaufrufe einen Fehlercode zurückgeben, der bei jedem Aufruf sofort behandelt wird, Verwenden Sie eine Variable und nicht 10. Es gibt ein Problem: Normalerweise teilt Ihnen der Compiler mit, wann Sie eine nicht initialisierte Variable verwenden. Hier jedoch, wenn Sie den Fehlercode nach Aufruf 6 lesen, die Variable jedoch nicht geändert wurde Nach Aufruf 5 erhalten Sie unbrauchbare Daten, ohne dass der Compiler Sie warnt. Da die Variable mit Daten initialisiert wurde, die jetzt unbrauchbar sind.

Wichtig ist, dass nichts eine eiserne Regel ist. Alles hat Vor- und Nachteile. Wenn "Best Practices" eine Sache nahe legen und Sie Gründe haben zu sagen, dass dies in Ihrer spezifischen Situation eine schlechte Idee ist, dann tun Sie es nicht.

0
gnasher729