Sind Flaggenvariablen ein absolutes Übel? [geschlossen]

Nein, Flags sind nicht schlecht oder ein Übel, das um jeden Preis überarbeitet werden muss.

Betrachten Sie Java Pattern.compile (String regex, int flags) anrufen. Dies ist eine traditionelle Bitmaske und es funktioniert. Werfen Sie einen Blick auf die -Konstanten in Java und überall dort, wo Sie eine Reihe von 2 ⁿ sehen, wissen Sie, dass dort Flags vorhanden sind.

In einer idealen überarbeiteten Welt würde man stattdessen ein EnumSet verwenden, bei dem die Konstanten stattdessen Werte in einer Aufzählung sind und wie in der Dokumentation angegeben:

Die räumliche und zeitliche Leistung dieser Klasse sollte gut genug sein, um als hochwertige, typsichere Alternative zu herkömmlichen int-basierten „Bit-Flags“ verwendet werden zu können.

In einer perfekten Welt wird dieser Pattern.compile-Aufruf zu Pattern.compile(String regex, EnumSet<PatternFlagEnum> flags).

Alle das heißt, es ist immer noch Flaggen.Es ist viel einfacher, mit Pattern.compile("foo", Pattern.CASE_INSENSTIVE | Pattern.MULTILINE) zu arbeiten, als mit Pattern.compile("foo", new PatternFlags().caseInsenstive().multiline()) oder einer anderen Art zu versuchen, das zu tun, was Flags wirklich sind und gut für.

Flags werden häufig bei der Arbeit mit Dingen auf Systemebene angezeigt. Wenn eine Schnittstelle zu etwas auf Betriebssystemebene besteht, hat man wahrscheinlich irgendwo ein Flag – sei es der Rückgabewert eines Prozesses oder die Berechtigungen einer Datei oder die Flags zum Öffnen eines Sockets. Der Versuch, diese Instanzen bei einer Hexenjagd gegen einen wahrgenommenen Codegeruch umzugestalten, führt wahrscheinlich zu einem schlechteren Code, als wenn man die Flagge akzeptiert und verstanden hat.

Das Problem tritt auf, wenn Leute Flaggen missbrauchen, die sie zusammen werfen und Erstellen eines Frankenflag-Sets aller Arten von nicht verwandten Flags oder Versuch, sie dort zu verwenden, wo sie überhaupt keine Flags sind.

Ich gehe davon aus, dass es sich um Flags innerhalb von Methodensignaturen handelt.

Die Verwendung eines einzelnen Flags ist schon schlimm genug.

Es bedeutet Ihren Kollegen nichts, wenn sie es sehen. Sie müssen sich den Quellcode der Methode ansehen, um festzustellen, was sie tut. Sie werden sich wahrscheinlich einige Monate später an derselben Position befinden, wenn Sie vergessen, worum es bei Ihrer Methode ging.

Das Übergeben eines Flags an die Methode bedeutet normalerweise, dass Ihre Methode für mehrere Dinge verantwortlich ist. Innerhalb der Methode führen Sie wahrscheinlich eine einfache Überprüfung der folgenden Zeilen durch:

if (flag) DoFlagSet(); else DoFlagNotSet(); 

Das ist eine schlechte Trennung von Bedenken und Sie können normalerweise einen Weg finden, um sie zu umgehen.

Normalerweise habe ich zwei separate Methoden:

public void DoFlagSet() { } public void DoFlagNotSet() { } 

Dies ist sinnvoller bei Methodennamen, die für das zu lösende Problem gelten.

Das Übergeben mehrerer Flags ist doppelt so schlecht. Wenn Sie wirklich mehrere Flags übergeben müssen, sollten Sie sie in eine Klasse einkapseln. Selbst dann werden Sie immer noch mit dem gleichen Problem konfrontiert sein, da Ihre Methode wahrscheinlich mehrere Dinge tut.

Flags und Die meisten Temperaturvariablen riechen stark. Höchstwahrscheinlich könnten sie überarbeitet und durch Abfragemethoden ersetzt werden.

Überarbeitet:

Flags und temporäre Variablen sollten beim Ausdrücken des Status in Abfragemethoden umgestaltet werden. Die Statuswerte (Boolesche Werte, Ints und andere Grundelemente) sollten als Teil der Implementierungsdetails fast immer ausgeblendet werden.

Flags, die für die Steuerung, das Routing und den allgemeinen Programmablauf verwendet werden, können auch das anzeigen Möglichkeit, Abschnitte der Kontrollstrukturen in separate Strategien oder Fabriken oder was auch immer situativ angemessen sein mag, umzugestalten, die weiterhin die Abfragemethoden verwenden.

Wenn wir über Flags sprechen, sollten wir wissen, dass sie im Laufe der Programmausführung geändert werden und dass sie das Verhalten des Programms basierend auf ihren Zuständen beeinflussen. Solange wir die Kontrolle über diese beiden Dinge haben, funktionieren sie hervorragend.

Flags können hervorragend funktionieren, wenn

• Sie sie in einem geeigneten Bereich definiert haben. Mit „angemessen“ meine ich, dass der Bereich keinen Code enthalten sollte, der sie nicht ändern muss / sollte. Oder zumindest ist der Code sicher (z. B. kann er nicht direkt von außen aufgerufen werden).
• Wenn Flags von außen verarbeitet werden müssen und viele Flags vorhanden sind, können wir den Flag-Handler als einzigen Weg codieren um Flags sicher zu ändern. Dieser Flag-Handler kann selbst Flags und Methoden zum Ändern dieser Flaps kapseln. Es kann dann als Singleton erstellt und dann für Klassen freigegeben werden, die Zugriff auf Flags benötigen.
• Und schließlich zur Wartbarkeit, wenn zu viele Flags vorhanden sind:
  • Sie müssen nicht sagen, dass sie sollten Befolgen Sie die sinnvolle Benennung.
  • Sollte mit gültigen Werten dokumentiert werden (möglicherweise mit Aufzählungen).
  • Sollte dokumentiert werden mit WELCHEM CODE ÄNDERT jeden von ihnen und auch mit WELCHEM ZUSTAND bei der Zuweisung eines bestimmten Werts zum Flag.
  • WELCHER CODE VERBRAUCHT sie und WAS VERHALTEN ergibt sich für einen bestimmten Wert

Wenn es verdammt viele Flags gibt, sollte gute Designarbeit vorausgehen, da Flags dann eine Schlüsselrolle im Programmverhalten spielen. Sie können Zustandsdiagramme zur Modellierung verwenden. Solche Diagramme dienen auch als Dokumentation und visuelle Anleitung, wenn Sie mit ihnen umgehen.

Solange diese Dinge vorhanden sind, wird dies meiner Meinung nach nicht zu Unordnung führen.

Ich ging von der Frage aus, dass die Qualitätssicherung Flag-Variablen (globale Variablen) und keine Bits eines Funktionsparameters bedeutet.

Es gibt Situationen wo Sie nicht viele andere Möglichkeiten haben. Zum Beispiel müssen Sie ohne Betriebssystem Interrupts auswerten.Wenn ein Interrupt sehr häufig auftritt und Sie keine Zeit haben, eine lange Auswertung im ISR durchzuführen, ist es nicht nur zulässig, sondern manchmal sogar eine bewährte Methode, nur einige globale Flags im ISR zu setzen (Sie sollten so wenig Zeit wie möglich aufwenden im ISR) und um diese Flags in Ihrer Hauptschleife auszuwerten.

Ich glaube nicht, dass alles ist ein absolutes Übel in der Programmierung.

Es gibt eine andere Situation, in der Flags in Ordnung sein könnten, welche wurden hier noch nicht erwähnt …

Betrachten Sie die Verwendung von Verschlüssen in diesem Javascript-Snippet:

exports.isPostDraft = function ( post, draftTag ) { var isDraft = false; if (post.tags) post.tags.forEach(function(tag){ if (tag === draftTag) isDraft = true; }); return isDraft; } 

Die übergebene innere Funktion für „Array.forEach“ kann nicht einfach „true zurückgeben“.

Daher müssen Sie den Status mit einem Flag außerhalb halten.