2016-05-27 14 views
0

Ich bin seit der Programmierung in bedingten Aussagen seit != oder !condition nicht ungleich. Vielleicht liegt es daran, dass mein Gehirn in der englischen Sprache vorkonditioniert ist, um mehrere Negationen zu überdenken. Aber ich frage mich, ob es eine gemeinsame Entwicklungsgemeinschaft gibt, die akzeptiert wird, wenn es darum geht, in bedingten Aussagen wahr zu bewerten? Oder vielmehr, so wie ich es manchmal sehe: Auswerten für nicht falsch.Common Code Convention für nicht gleich in bedingten statements

Vielleicht gibt es Ausnahmen, bei denen != nicht vollständig unvermeidbar sein kann?

Beispiel:

Dies könnte eine sehr einfache und trivial sein, ist aber diese

bevorzugt
string myStringVar = "dogs"; 


if (myStringVar != "dogs") //In my mind, "False this is not true" 
{ 
    //code 
} 
else if (myStringVar != cats) //In my mind, "True this is false" 
{ 
    //code 
} 

Oder ist dies bevorzugt

if (myStringVar == "dogs") 
{ 
    //"True" 
} 
else if (myStringVar == "cats") 
{ 
    //"False" 
} 

Dann gibt es

bool MyBoolMethod() 
{ 
    return false; 
} 


if (!MyBoolMethod()) // True this method does not return true 
{ 
    //code 
} 

Dies ist ein sehr triviales und vereinfachtes Beispiel, ich möchte nur wissen, wie man lesbaren, wartbaren Code schreibt. Hat jemand sonst eine etwas schwierige Zeit, solche Bedingungen zu lesen oder ist es nur ich?

+1

Ich lese '(myStringVar! =" Dogs ")' als 'myStringVar' ist nicht gleich' 'dogs''. Das heißt, dass diese Bedingung kein Problem sein sollte. –

+0

Und vielleicht ist das mein Problem; Manchmal stelle ich mir beim Debuggen oder Schreiben von Code vor, dass die Variable zugewiesen wird. In komplexeren Situationen scheint ich mit "nicht gleich" gegenüber "gleich" zu verwechseln. –

+0

Das erste if-else-if-Konstrukt oben ist definitiv schlecht. Diese Logik sollte nach Besonderheiten suchen. Die zwei Zweige der Logik dort könnten Szenarien erfassen, die in beide logischen Konstrukte fallen würden. Die Prüfung auf Gleichheit in diesem Fall wäre definitiv besser. Es hängt fast ausschließlich davon ab, was Sie tun möchten. Sie sollten auf jeden Fall doppelte Negation vermeiden, obwohl z. eine boolesche Variable mit dem Namen 'notFound' zu haben, die bei true beginnt und dann auf false setzt, wenn du die fragliche Sache findest. Es wäre besser, eine "gefundene" Variable zu haben, die falsch startet und dann auf wahr setzt, sobald sie gefunden ist. – ManoDestra

Antwort

1

"Keine der oben genannten."

Da Sie string s verwenden, ist die Annahme, dass myStringVar alles sein kann. Wenn ich sage:

string myStringVar = "Aardvark"; 

Dann wird Ihr erstes Beispiel, wird es den myStringVar != "dogs" Abschnitt des Codes ausgeführt werden; Im zweiten Beispiel wird keiner von beiden ausgeführt. Sie sind also keine gleichwertigen Code-Teile.

Der einzige Weg, sie würden äquivalent sein, wenn Sie Enums verwenden würden (in diesem Fall würde ich vorschlagen, eine case Anweisung zu verwenden).

In Ihrem dritten Beispiel würde es darauf ankommen, was MyBoolMethod() benannt wurde, und wie einfach es war, von einem zukünftigen Coder zu verstehen. Um ein Beispiel zu verwenden, ist

bool isDog() 
{ 
    return false; 
} 

ist einfach zu verstehen. Die Frage ist dann ist

if(!isDog()) ... 

deutlicher als

if(isNotDog()) ... 

ich argumentieren würde, dass die erste ist klarer als die zweite. Es gibt jedoch andere Situationen, in denen dies nicht der Fall ist.

+0

Ich stimme den Signaturen der Schreibmethode zu, die aussagekräftig sind. Dann ist der Rückgabewert an anderer Stelle im Code eindeutig. Ich denke, dass meine Beispiele im Vergleich zu Ihren Beispielen beweisen, dass die Codierungskonventionen, auf die ich mich wirklich konzentrieren muss, aussagekräftige Signaturen und Eigenschaftsnamen korrekt sind? –

+1

Ja. Es gibt einige sehr gute Bücher über den Programmierstil, und ich fand sie nützlich (obwohl der, an den ich denke, für Java ist, aber ich kann mich nicht an den Namen erinnern). Ich benutze die "Sechs-Monats-Regel": "Wenn ich in sechs Monaten meinen eigenen Code lese, werde ich es verstehen - oder werde ich fragen, was der Idiot geschrieben hat?" –

1

Gleichheit und Ungleichheit sind nur etwas, mit dem man sich vertraut machen und im Kontext wählen muss. Wenn das logische Problem erfordert, dass Sie versuchen, auf Gleichheit zu testen, verwenden Sie die Gleichheit, wenn Sie versuchen, die Ungleichung der Verwendung zu disqualifizieren.

Die Lesbarkeit und Wartbarkeit kann durch gutes Design verstärkt werden, wie Sie mit Ihrer Mybol-Methode begonnen haben.

Exmaple

public class Animal 
{ 
    public static Enum AnimalType 
    { 
     Dog, 
     Cat 
    } 

    private _animalType; 

    public Animal(Enum AnimalType type) 
    { 
     AnimalType = _animalType; 
    } 

    public bool isOfType(Enum AnimalType type) 
    { 
     return _animalType == type ? true : false; 
    } 

} 

public someothermethod() 
{ 
    //doing inclusion 
    If(MyAnmialObject.isOfType(Animal.AnimalType.Dog)) 
    { 
     //if type matches 
    } 

    //Doing exclusion 
    If(!MyAnmialObject.isOfType(Animal.AnimalType.Dog)) 
    { 
     //if type does not match 
    } 
} 

Sie haben noch zu Ungleichheit gewöhnen, aber sie wissen, dass es für isOfType ist die Überprüfung und der genannten Art.

+0

So viele Situationen, die ich mit "nicht gleich" konfrontiert habe, sind so, dass der Entwickler es vermeidet, eine "else-Anweisung" schreiben zu müssen. Wenn ich nur etwas machen wollte, wenn 'MyAnimalObject' nicht vom Typ' Animal.AnimalType.Dog' ist, denken Sie, dass der beste Weg, die Logik zu schreiben, darin besteht, eine nicht if-Anweisung zu schreiben, anstatt _if gleich dog, nichts zu tun. sonst führe meinen anderen Tiercode aus_? –

+1

Wenn du nur etwas mit der Bedingung machst, dass das Tier kein Hund ist, warum würdest du nicht einfach danach suchen? Suchen nach ist ein Hund, der dann die falsche Bedingung in einem else-Block behandelt, erstellt nur einen if-Block ohne Code. Wenn Sie immer das andere haben wollen, könnten Sie in den ternären Operator schauen. –

+0

Nun, vielleicht hätte ich bedingte Operatoren als Teil meiner Frage hinzugefügt. Du bringst einen guten Punkt, wenn du sagst: "Warum würdest du das nicht einfach überprüfen?". Ich habe anderen Entwicklercode bearbeitet, wo ich hinzufügen musste, was passieren würde, wenn es ein Hund wäre. Zu der Zeit, als der Code geschrieben wurde, mussten sie nur wissen, was zu tun war, wenn es nicht war. Also, ich denke, es ist lesbar und wartbar. Ich dachte eine Weile darüber nach und dachte, ich würde etwas Basses machen. –