Soll man bestimmte Programmierkonstrukte (und andere) aus Wartungsgründen meiden?

Question

Ich arbeite an einem nicht-persönlichen Projekt, also kann ich sicher sagen, dass der Wartungsprogrammierer nicht ich bin, denn sonst müsste ich diese Frage nicht stellen.

Jetzt gibt es einige Konstrukte (Delegaten, Lambda - Ausdrücke), die ich in meinem Code versuchen möchte, um den Code nicht absichtlich schwerer lesbar zu machen, sondern weil sie sich für die Situation eignen (und weniger Code als naja) und sie auch zu üben, da ich neu in der Sprache bin.

Ich bin mir jedoch nicht sicher, ob der Wartungsprogrammierer jedes Konstrukt kennt, da viele von uns nicht aus aC# -Hintergrund stammen, und ich bin mir nicht sicher, ob er genauso begeistert von Programmieren ist wie ich Es ist wie ein normaler Job. Also meine Fragen sind:

• Sollten bestimmte Programmierkonstrukte vermieden werden maintainabilily zu verbessern?

• Wenn die Antwort auf die obige Frage ja ist, dann ist die Teilmenge der Konstrukte, die man vermeiden sollte?

• Liegt es in der Verantwortung des Wartungsprogrammierers, eine Sprache vollständig zu lernen?

Answer 1

Ich bin gegen kleinsten gemeinsamen Nenners Codierung. Wir sind Profis, ein Teil dessen, was von uns erwartet werden sollte, ist Dinge zu lernen, die wir nicht kennen.

Auf der anderen Seite bin ich auch gegen Ruhm-Codierung. Verwenden Sie die einfachsten Konstrukte, die den Job erledigen können - das Debuggen von Code ist doppelt so schwierig wie das Schreiben von Code, also schreiben Sie besser nur den Code halb so clever wie Sie können!

Answer 2

Ich denke, die allgemeine Faustregel ist, sicherzustellen, dass Ihr Code mit vielen Kommentaren lesbar ist, besonders an Orten, wo Sie etwas tun, was nicht direkt ist. Die Vermeidung bestimmter Konstrukte wie Delegaten und Lambda-Ausdrücken sollte nicht der richtige Weg sein. Wenn sie richtig und sinnvoll verwendet werden, können Sprachfunktionen wie diese die Komplexität Ihres Codes erheblich reduzieren und sie prägnanter und aussagekräftiger machen. Schließlich ist das die Schönheit von LINQ, oder? ;-)

Ich denke, du solltest dich darauf konzentrieren, deinen Teil des Jobs so gut wie möglich zu erledigen, egal ob die anderen Programmierer das nötige Wissen haben, um zu verstehen, dass dein Code nicht von dir kontrolliert wird. Wenn der Wartungsprogrammierer geht und jemand anderes hereinkommt, was dann? Sie sollten Ihren Code nicht an den Wartungsprogrammierer anpassen, sondern Ihren Code an das Problem anpassen, das Sie lösen sollen.

Answer 3

Ich denke, dass selbst wenn Sie an Ihrem eigenen Projekt schreiben, es sich lohnt, so weit wie möglich an gängigen/Standard-Idiomen in der von Ihnen verwendeten Sprache zu bleiben.

Ich bin selbst in diese Falle gelaufen - habe einen Code geschrieben, der etwas "Cleveres" gemacht hat, habe es nicht ausreichend dokumentiert und einen ernsten Bug eingeführt, als ich ein paar Monate später den Code änderte.

Meine Faustregel - benutze die "Kernsprache" so viel wie möglich, und wenn du davon abweichst, dokumentiere deine Vorgehensweise gründlich. Vermeiden Sie die Verwendung von syntaktischem Zucker, um Ihren Code zu verkürzen, es sei denn, es handelt sich um ein Standard-Idiom (z. B. Eigenschaften in C#).Lesbarkeit sollte die Schreibgeschwindigkeit jedes Mal übertreffen.

Wenn Sie erwarten, dass Wartungs-Programmierer Ihre Arbeit übernehmen, ist dies alles doppelt wahr. Sie können nicht erwarten, dass Wartung Programmierer in den meisten Organisationen mehrere Paradigmen beherrschen. Wenn Sie z.B. Beginnen Sie mit logischen/funktionalen Programmierkonstrukten wie Lambdas in Ihrem objektorientierten Code, dann ist es ein bisschen so, als ob Sie ein Kapitel in Deutsch in einem englischen Buch schreiben würden. Vielleicht möchten Sie, dass Ihre Leser mehrsprachige Enthusiasten sind, aber es ist sehr wahrscheinlich, dass sie es nicht sind.

Answer 4

Ich glaube vor allem Lambda-Ausdrücke machen den Code leichter zu lesen, wenn überhaupt. Anstatt mehrere for-each mit vielen Bedingungen - ein sauberes Lambda kann fast gelesen werden.

Aus meiner Erfahrung sind Dinge, die Code schwer lesbar machen, clevere generische Func-Argumente ... Diese nehmen oft nur zwei leicht lesbare Funktionen heraus und ersetzen sie durch eine generische, schwer lesbare.

So ist es in meinem Buch wichtiger, Methoden mit guten Namen zu haben, als bestimmte Konstrukte zu vermeiden. Aber mach dir keine Sorgen, dass sie sie nicht kennen - sie sollten sie trotzdem lernen.