Frage

Sprachverknüpfungen können oft verwendet werden, um Code präzise zu gestalten.

Zum Beispiel können ternäre und Null -Koalescing -Operatoren die Codemenge reduzieren, aber möglicherweise zum Nachteil der Lesbarkeit:

In C#:

Person newGuy = new Person();
if (boss == null) {
    newGuy.Boss = GetDefaultBoss();
} else {
    newGuy.Boss = boss;
}

ist funktionell äquivalent zu:

Person newGuy = new Person();
newGuy.Boss = boss ?? GetDefaultBoss();

Aber offensichtlich viel mehr ausführlicher.

Wo ziehen Sie die Linie, wenn es um die Selbstverständlichkeit gegen die Lesbarkeit geht?

War es hilfreich?

Lösung

Beide.

Ihr erstes Beispiel ist sicherlich ausführlicher und wohl expliziter ... aber es erfordert auch, dass ich fünf Zeilen anstelle eines scannen muss. Schlimmer noch, es wird seinen Zweck bezeichnet - einen Wert zuzuweisen newGuy.Boss.

Ihr zweites Beispiel kann mich eine Sekunde gekostet haben, wenn ich mit dem Null -Koalescing -Operator nicht vertraut bin, aber es kann keinen Zweifel an seinem Zweck geben, und wenn ich eine größere Routine suche, um nach der Quelle eines Wertes zu suchen, wird es Seien Sie viel einfacher für mich, diesen auszuwählen.

Vergleichen Sie dies nun:

if (boss == null) {
    newGuy.Boss = GetDefaultBoss();
    newGuy.IsTemp = true;
    newGuy.AddTask("orientation");
} else {
    newGuy.Boss = boss;
    newGuy.IsTemp = false;
}

...mit:

newGuy.Boss = boss ?? GetDefaultBoss();
newGuy.IsTemp = boss == null;
if ( boss == null ) newGuy.AddTask("orientation");

Das letztere Beispiel ist wieder viel kürzer, aber jetzt verdeckt es seinen Zweck, indem es durch denselben Test ausgelösten Aufgaben zu verdecken scheint. Hier fühle ich, dass die Ausführlichkeit des ersteren gerechtfertigt ist.

Andere Tipps

Während beide gute Ziele sind, werde ich immer auf der Seite sein mit Lesbarkeit wenn gezwungen, eine auszuwählen.

Ich würde argumentieren, dass Ihr Beispiel beide Lesbarkeit verbessert und Kürze. Bedenken Sie jedoch:

if( a > b )
{
    foo = bar
}
else
{
    if( c.isThing() ){
        foo = somethingElse;
    }
    else{
        foo = someFurtherThing.GetFoo();
    }
}

im Gegensatz zu

foo = a > b ? bar ?? whatever.something : c.isThing() ? somethingElse : someFurtherThing.GetFoo();

Letzteres ist prägnant, aber schwer durchzulesen. Ersteres ist ausführlich, aber der Logikfluss ist klar.

Letztendlich erfüllt die Kürze nur einen großen Zweck, außer der Fähigkeit, mehr auf den Bildschirm zu passen. Die Lesbarkeit erleichtert das Debuggen und sollte daher im Allgemeinen bevorzugt werden.

Ich würde in der allgemeinen Regel sagen, dass die Lesbarkeit aufgrund der Übersicht niemals die Lesbarkeit opfert, aber niemals die Lesbarkeit auf der Grundlage eines anderen Programmierers zu diesem Thema beurteilen.

SUKTIVE UND LESESSIVITÄT sind keine Gegensätze. Wie diese Antwort ist manchmal kürzer lester.

Ich würde sagen, ich bevorzuge die Lesbarkeit, aber das bedeutet manchmal, prägnanten Code zu verwenden. (Dh ternär für relativ einfache Bedingungen in einem größeren bedingten Block.)

Wenn es unnötig schwierig zu verstehen ist, tun Sie es im Grunde genommen nicht.

Die Lesbarkeit kommt an erster Stelle, wo sie mit Zuversicht in Konflikt steht, da Code häufiger geändert wird als ursprünglich geschrieben. Auf der anderen Seite:

  1. Syntaktischer Rauschen und Kesselplattencode verschleiern oft Absichten und schaden damit die Lesbarkeit. Manchmal ist der prägnantere Code auch lesbarer. Denken Sie beispielsweise an Lambda-Funktionen oder Delegierte/erstklassige Funktionen gegenüber Einzel-Methoden-Klassen, die eine einzelne Methodenschnittstelle implementieren.

  2. Die Lesbarkeit sollte bewertet werden, basierend darauf, wie einfach der Code für einen vernünftig erfahrenen Programmierer ist, der die Sprache und ihre einzigartigen/fortgeschrittenen Funktionen ziemlich gut kennt, nicht für einen kaum kompetenten Code -Affen, der nur den niedrigsten gemeinsamen Nenner kennt.

Ein Aspekt, den ich nicht glaube, wurde noch erwähnt: Was sind dein Tore?

Wenn Sie sich nur um die Arbeitsplatzsicherheit kümmern, gehen Sie über alles andere zuversichtlich und Kompaktheit. Überspringen Sie auch Ihren Code.

Wenn Sie Ihren Code leicht an jemand anderen geben möchten, während Sie an einem coolen neuen Projekt arbeiten, gehen Sie Lesbarkeit, Klarheit und viele solide Kommentare.

Hinweis: Im obigen Bereich geht es nicht um Sie persönlich, @damovisa; Es ist für alle, die zwischen den beiden Positionen wählen.

Es gibt eine Sache, die die ausführliche Version als Vorteil hat.

Es hat mehr Zeilen und die meisten Debugger sind linienorientiert! Es ist sehr schwierig, einen Bruchpunkt in der Mitte eines Ausdrucks zu setzen, aber es ist normalerweise trivial einfach, ihn in eine Blockanweisung zu setzen.

Mit anderen Worten, welches möchten Sie in Ihrem Editor sehen, wenn Sie möchten, dass Ihr Debugger einsetzt, wann boss == null ?

(Das heißt, ich mag den Operator?)

Die Lesbarkeit sollte an erster Stelle kommen, langfristig verbringen die meisten Menschen die meiste Zeit damit, vorhandenen Code zu ändern oder zu erweitern - die Lesbarkeit ist ein großer Teil der Wartbarkeit.

Die Übersichtlichkeit kann jedoch zur Lesbarkeit beitragen. In Ihrer Frage ist das zweite Snippet beispielsweise sowohl lesbar als auch prägnanter.

Lizenziert unter: CC-BY-SA mit Zuschreibung
scroll top