Wie sieht der Code eines guten Programmierers aus? [geschlossen]

Ich bin ein Hobby-Programmierer (angefangen mit VBA, um Excel schneller zu machen) und habe mit VB.NET / C # .NET gearbeitet und versuche, ADO.NET zu lernen.

Eine Facette der Programmierung, die mich immer frustriert hat, ist, wie "gut" aussieht. Ich bin kein Profi, habe also wenig zu vergleichen. Was macht einen besseren Programmierer aus? Ist es:

• Sie haben ein besseres Verständnis aller Objekte / Klassen / Methoden in einer bestimmten Sprache?
• Ihre Programme sind effizienter?
• Das Design ihrer Programme ist viel besser in Bezug auf bessere Dokumentation, gute Wahl der Namen für Funktionen usw.?

Anders ausgedrückt, wenn ich mir den Code eines professionellen Programmierers ansehen würde, was würde ich als erstes an ihrem Code im Vergleich zu meinem bemerken? Zum Beispiel lese ich Bücher wie 'Professional ASP.NET' von Wrox Press. Sind die Codebeispiele in diesem Buch "Weltklasse"? Ist das der Höhepunkt? Würde sich ein Top-Programmierer diesen Code ansehen und denken, dass er ein guter Code ist?

Die folgende Liste ist nicht vollständig, aber dies sind die Dinge, an die ich bei der Prüfung Ihrer Frage gedacht habe.

• Guter Code ist gut organisiert. Daten und Operationen in Klassen passen zusammen. Es gibt keine fremden Abhängigkeiten zwischen Klassen. Es sieht nicht aus wie "Spaghetti".

• Gute Codekommentare erklären, warum Dinge getan werden, nicht was getan wird. Der Code selbst erklärt, was getan wird. Der Bedarf an Kommentaren sollte minimal sein.

• Guter Code verwendet aussagekräftige Namenskonventionen für alle Objekte außer den vorübergehendsten. Der Name von etwas gibt Auskunft darüber, wann und wie das Objekt verwendet wird.

• Guter Code ist gut getestet. Tests dienen als ausführbare Spezifikation des Codes und als Beispiele für seine Verwendung.

• Guter Code ist nicht "klug". Es macht Dinge auf einfache, offensichtliche Weise.

• Guter Code wird in kleinen, leicht lesbaren Recheneinheiten entwickelt. Diese Einheiten werden im gesamten Code wiederverwendet.

Ich habe es noch nicht gelesen, aber das Buch, das ich zu diesem Thema lesen möchte, ist Clean Code von Robert C. Martin.

Das erste, was Sie bemerken würden, ist, dass ihr Code einem konsistenten Codierungsstil folgt . Sie schreiben ihre Strukturblöcke immer gleich, rücken religiös ein und kommentieren gegebenenfalls.

Das zweite, was Sie bemerken würden, ist, dass ihr Code in kleine Methoden / Funktionen unterteilt ist, die höchstens ein paar Dutzend Zeilen umfassen. Sie verwenden auch selbstbeschreibende Methodennamen und im Allgemeinen ist ihr Code sehr gut lesbar.

Das dritte, was Sie bemerken würden, nachdem Sie ein wenig mit dem Code herumgespielt haben, ist, dass die Logik leicht zu befolgen, leicht zu ändern und daher leicht zu warten ist.

Danach benötigen Sie einige Kenntnisse und Erfahrungen in Software-Design-Techniken, um die spezifischen Entscheidungen zu verstehen, die sie beim Erstellen ihrer Codearchitektur getroffen haben.

In Bezug auf Bücher habe ich nicht viele Bücher gesehen, in denen der Code als "Weltklasse" angesehen werden könnte. In Büchern versuchen sie hauptsächlich, einfache Beispiele zu präsentieren, die für die Lösung sehr einfacher Probleme relevant sein könnten, aber komplexere Situationen nicht widerspiegeln.

Zitat von Fowler, Zusammenfassung der Lesbarkeit:

Jeder Dummkopf kann Code schreiben, den ein Computer verstehen kann.
Gute Programmierer schreiben Code, den Menschen verstehen können.

'nough sagte.

Persönlich muss ich "The Zen of Python" von Tim Peters zitieren . Es sagt Python-Programmierern, wie ihr Code aussehen soll, aber ich finde, dass er im Grunde für den gesamten Code gilt.

Schön ist besser als hässlich.
Explizit ist besser als implizit.
Einfach ist besser als komplex.
Komplex ist besser als kompliziert.
Wohnung ist besser als verschachtelt.
Spärlich ist besser als dicht.
Lesbarkeit zählt.
Sonderfälle sind nicht speziell genug, um gegen die Regeln zu verstoßen.
Obwohl Praktikabilität die Reinheit übertrifft.
Fehler sollten niemals stillschweigend vergehen.
Sofern nicht ausdrücklich zum Schweigen gebracht.
Verweigern Sie angesichts von Zweideutigkeiten die Versuchung zu raten.
Es sollte einen - und vorzugsweise nur einen - offensichtlichen Weg geben, dies zu tun.
Obwohl dieser Weg zunächst vielleicht nicht offensichtlich ist, es sei denn, Sie sind Niederländer.
Jetzt ist besser als nie.
Obwohl nie oft besser ist alsgerade jetzt.
Wenn die Implementierung schwer zu erklären ist, ist es eine schlechte Idee.
Wenn die Implementierung leicht zu erklären ist, kann dies eine gute Idee sein.
Namespaces sind eine großartige Idee - lasst uns mehr davon machen!

Code ist Poesie.

Wenn Sie von diesem logischen Punkt ausgehen, können Sie viele der gewünschten Codequalitäten ableiten. Beachten Sie vor allem, dass Code weit mehr gelesen als geschrieben wird, und schreiben Sie daher Code für den Leser. Schreiben, umbenennen, bearbeiten und umgestalten für den Leser.

Eine Folge der Folgerung:

Der Leser wird Sie zum Zeitpunkt n ab dem Datum der Codeerstellung sein. Die Auszahlung des Schreibens von Code für den Leser ist eine monoton ansteigende Funktion von n. Ein Leser, der Ihren Code zum ersten Mal betrachtet, wird durch n == unendlich angezeigt.

Mit anderen Worten, je größer die Zeitspanne zwischen dem Schreiben des Codes und dem erneuten Aufrufen des Codes ist, desto mehr werden Sie Ihre Bemühungen, für den Leser zu schreiben, zu schätzen wissen. Jeder, dem Sie Ihren Code übergeben, profitiert von Code, der mit dem Leser als wichtigste Überlegung geschrieben wurde.

Eine zweite Folge:

Code, der ohne Rücksicht auf den Leser geschrieben wurde, kann unnötig schwer zu verstehen oder zu verwenden sein. Wenn die Überlegung für den Leser einen bestimmten Schwellenwert unterschreitet, leitet der Leser weniger Wert aus dem Code ab als der Wert, der durch das Umschreiben des Codes gewonnen wird. In diesem Fall wird der vorherige Code weggeworfen und tragischerweise wird beim Umschreiben viel Arbeit wiederholt.

Eine dritte Folge:

Es ist bekannt, dass sich Folgerung zwei in einem Teufelskreis von schlecht dokumentiertem Code mehrmals wiederholt, gefolgt von erzwungenen Umschreibungen.

Ich programmiere seit 28 Jahren und finde es schwierig, diese Frage zu beantworten. Für mich ist guter Code ein Komplettpaket. Der Code ist sauber geschrieben und enthält aussagekräftige Variablen- und Methodennamen. Es hat gut platzierte Kommentare, die die Absicht des Codes kommentieren und nicht nur den Code wieder auffliegen lassen, den Sie bereits lesen können. Der Code macht das, was er soll, auf effiziente Weise, ohne Ressourcen zu verschwenden. Es muss auch mit Blick auf die Wartbarkeit geschrieben werden.

Das Fazit ist jedoch, dass es für verschiedene Menschen unterschiedliche Bedeutungen hat. Was ich als guten Code bezeichnen könnte, könnte jemand anderes hassen. Guter Code hat einige gemeinsame Merkmale, die ich oben identifiziert habe.

Das Beste, was Sie tun können, ist, sich dem Code auszusetzen. Schauen Sie sich den Code anderer Leute an. Open Source-Projekte sind dafür eine gute Quelle. Sie finden guten und schlechten Code. Je mehr Sie sich das ansehen, desto besser erkennen Sie, was Sie als guten und schlechten Code bezeichnen.

Letztendlich wirst du dein eigener Richter sein. Wenn Sie Stile und Techniken finden, die Sie gerne übernehmen, werden Sie im Laufe der Zeit Ihren eigenen Stil entwickeln, der sich im Laufe der Zeit ändern wird. Es gibt hier keine Person, die einen Zauberstab schwingen und sagen kann, was gut ist und dass alles andere schlecht ist.

Lesen Sie das Buch Code Complete. Dies erklärt viele Ideen zur Strukturierung von Code und die Gründe dafür. Das Lesen sollte Ihre Zeit kurzschließen, um die Erfahrung zu sammeln, die erforderlich ist, um zwischen Gut und Böse zu unterscheiden.

http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1229267173&sr=8-1

Nachdem ich selbst seit fast 10 Jahren programmiere und mit anderen zusammengearbeitet habe, kann ich das ohne Vorurteile sagen es keinen Unterschied zwischen einem guten Programmierer und einem durchschnittlichen Programmierercode gibt

Alle Programmierer auf kompetentem Niveau:

• Richtig kommentieren
• Effizient strukturieren
• Sauber dokumentieren

Ich habe einmal gehört, wie ein Mitarbeiter sagte: " Ich war immer sehr logisch und rational. Ich denke, deshalb entwickle ich mich gerne "

Das ist meiner Meinung nach der Verstand eines durchschnittlichen Programmierers. Einer, der die Welt in Bezug auf Regeln und Logik sieht und diese Regeln letztendlich beim Entwerfen und Schreiben eines Programms befolgt.

Der erfahrene Programmierer versteht die Regeln, aber auch deren Kontext. Dies führt letztendlich dazu, dass sie neue Ideen und Implementierungen entwickeln, die das Kennzeichen eines erfahrenen Programmierers sind. Programmieren ist letztendlich eine Kunstform.

Kurz gesagt, der Code eines guten Programmierers kann gelesen und verstanden werden.

Meiner Meinung nach a der Code guten Programmierers sprachunabhängig . Gut geschriebener Code kann unabhängig von der verwendeten Programmiersprache in kurzer Zeit mit minimalem Aufwand gelesen und verstanden werden. Unabhängig davon, ob der Code in Java, Python, C ++ oder Haskell vorliegt, ist gut geschriebener Code für Personen verständlich, die nicht einmal in dieser bestimmten Sprache programmieren.

Einige Merkmale von Code, die leicht zu lesen sind, sind gut benannte Methoden, das Fehlen von "Tricks" und die verschlungene "Optimierung", Klassen sind gut gestaltet, um nur einige zu nennen. Wie andere bereits erwähnt haben, ist der Codierungsstil konsistent, prägnant und unkompliziert .

Neulich habe ich mir beispielsweise den Code für TinyMCE angesehen , um eine der Fragen zum Stapelüberlauf zu beantworten. Es ist in JavaScript geschrieben, einer Sprache, die ich kaum benutzt habe. Aufgrund des Codierungsstils und der enthaltenen Kommentare sowie der Strukturierung des Codes selbst war dies jedoch ziemlich verständlich, und ich konnte in wenigen Minuten durch den Code navigieren.

Ein Buch, das mir beim Lesen des Codes eines guten Programmierers die Augen geöffnet hat, ist Beautiful Code . Es enthält viele Artikel von Autoren verschiedener Programmierprojekte in verschiedenen Programmiersprachen. Als ich es las, konnte ich jedoch verstehen, was der Autor in seinen Code schrieb, obwohl ich noch nie in dieser bestimmten Sprache programmiert habe.

Vielleicht sollten wir bedenken, dass es beim Programmieren auch um Kommunikation geht, nicht nur mit dem Computer, sondern auch mit Menschen . Der Code eines guten Programmierers ist also fast wie ein gut geschriebenes Buch, das dem Leser die Ideen vermitteln kann, die er vermitteln möchte .

• Leicht zu lesen
• einfach zu schreiben
• leicht zu pflegen

alles andere ist filigran

Guter Code sollte leicht verständlich sein.
Es sollte gut kommentiert werden.
Schwierige Teile sollten noch besser kommentiert werden.

Guter Code ist lesbar. Sie haben keine Probleme zu verstehen, was der Code beim ersten Durchlesen des von einem guten professionellen Programmierer geschriebenen Codes tut.

Anstatt die großartigen Vorschläge aller anderen zu wiederholen, schlage ich stattdessen vor, dass Sie das Buch lesen Code Complete von Steve McConnell

Im Wesentlichen handelt es sich um ein Buch voller bewährter Programmiermethoden für Funktionalität und Stil.

[Rein subjektive Antwort]
Guter Code ist für mich eine Kunstform, genau wie ein Gemälde. Ich könnte noch weiter gehen und sagen, dass es sich tatsächlich um eine Zeichnung handelt, die Zeichen, Farben, "Form" oder "Struktur" des Codes enthält und die alles so lesbar / performant ist. Die Kombination aus Lesbarkeit, Struktur (dh Spalten, Einrückungen, sogar Variablennamen gleicher Länge!) Und Farbe (Klassennamen, Variablennamen, Kommentare usw.) ergibt das, was ich gerne als "schönes" Bild sehe, das es kann mache mich entweder sehr stolz oder sehr verabscheuungswürdig gegenüber meinem eigenen Code.

(Wie gesagt, sehr subjektive Antwort. Entschuldigung für mein Englisch.)

Ich stimme der Empfehlung von Bob Martins "Clean Code" zu.

"Beautiful Code" wurde vor ein paar Jahren hoch gelobt.

Jedes von McConnells Büchern ist lesenswert.

Vielleicht wäre auch "The Pragmatic Programmer" hilfreich.

%.

Ich wollte nur meine 2 Cent hinzufügen ... Kommentare in Ihrem Code - und Ihr Code selbst im Allgemeinen - sollten sagen, was Ihr Code tut, jetzt wie er es tut. Sobald Sie das Konzept des 'Client'-Codes haben, bei dem es sich um Code handelt, der anderen Code aufruft (das einfachste Beispiel ist Code, der eine Methode aufruft), sollten Sie sich immer darum kümmern, Ihren Code aus der Sicht des "Clients" verständlich zu machen. Wenn Ihr Code wächst, werden Sie sehen, dass dies ... ähm, gut ist.

Bei vielen anderen Dingen über guten Code geht es um die mentalen Sprünge, die Sie machen werden (definitiv, wenn Sie darauf achten) ... 99% von ihnen haben jetzt etwas mehr Arbeit zu tun, um Ihnen eine Menge zu ersparen später arbeiten und Wiederverwendbarkeit. Und auch, wenn ich die Dinge richtig mache: Ich möchte fast immer in die andere Richtung laufen, anstatt reguläre Ausdrücke zu verwenden, aber jedes Mal, wenn ich mich darauf einlasse, sehe ich, warum alle sie in jeder einzelnen Sprache verwendet, in der ich arbeite (sie sind abstrus, aber Arbeit und könnte wahrscheinlich nicht besser sein).

In Bezug auf das Anschauen von Büchern würde ich meiner Erfahrung nach definitiv nicht sagen . Schauen Sie sich APIs und Frameworks sowie Codekonventionen und den Code anderer an und verwenden Sie Ihre eigenen Instinkte. Versuchen Sie zu verstehen, warum Dinge so sind, wie sie sind, und welche Auswirkungen die Dinge haben. Das, was Code in Büchern fast nie tut, ist das Ungeplante zu planen, worum es bei der Fehlerprüfung geht. Dies zahlt sich nur aus, wenn Ihnen jemand eine E-Mail sendet und sagt: "Ich habe Fehler 321" anstelle von "Hey, die App ist kaputt, yo."

Guter Code wird mit Blick auf die Zukunft geschrieben, sowohl aus Sicht des Programmierers als auch aus Sicht des Benutzers.

Dies wird in Fowlers Buch "Refactoring" ziemlich gut beantwortet. Es ist das Fehlen aller "Gerüche", die er im gesamten Buch beschreibt.

Ich habe 'Professional ASP.NET' noch nicht gesehen, aber ich wäre überrascht, wenn es besser als OK ist. In dieser Frage finden Sie einige Bücher mit wirklich gutem Code. (Es variiert natürlich, aber die akzeptierte Antwort dort ist schwer zu schlagen.)

Dies scheint (sollte) eine FAQ sein. Es gibt einen ACM-Artikel kürzlich über schönen Code. Es scheint viel Wert darauf zu legen, leicht zu lesen / zu verstehen. Ich würde dies mit "für Domain-Experten leicht lesbar / verständlich" qualifizieren. Wirklich gute Programmierer neigen dazu, die besten Algorithmen (anstelle von naiven, leicht verständlichen O (n ^ 2) -Algorithmen) für bestimmte Probleme zu verwenden, die schwer zu befolgen sein können, wenn Sie mit dem Algorithmus nicht vertraut sind, selbst wenn die guten Der Programmierer gibt einen Verweis auf den Algorithmus.

Niemand ist perfekt, einschließlich guter Programmierer, aber ihr Code strebt nach:

1. Korrektheit und Effizienz mit bewährten Algorithmen (anstelle von naiven und Ad-hoc-Hacks)
2. Klarheit (Absichtskommentar in Bezug auf nicht triviale Algorithmen)
3. Vollständigkeit der Grundlagen (Codierungskonvention, Versionierung, Dokumentation, Komponententests usw.)
4. Prägnanz (TROCKEN)
5. Robustheit (widerstandsfähig gegen willkürliche Eingaben und Unterbrechung von Änderungsanforderungen)

Ich stimme der Empfehlung für Onkel Bobs "Clean Code" zu. Aber vielleicht möchten Sie einen Blick auf http://www.amazon.com/Implementation-Patterns-Addison-Wesley-Signature-Kent/dp/0321413091 werfen, da ich denke, dass dies Ihre spezifische Frage etwas besser behandelt. Guter Code sollte von der Seite springen und Ihnen sagen, was er tut / wie er funktioniert.

Jeff Atwood hat einen schönen Artikel darüber geschrieben, wie Codierer Typisten sind. Erste Referenz: http://www.codinghorror.com/blog/archives/001188.html

Als Schreibkraft muss man in seiner Arbeit immer elegant sein, Struktur und richtige "Grammatik" sind sehr wichtig. Wenn Sie dies nun in eine "Programmier" -Typisierung umwandeln, erhalten Sie das gleiche Ergebnis.

Struktur

Bemerkungen

Regionen

Ich bin ein Software-Ingenieur, was bedeutet, dass ich während meiner Ausbildung auf viele verschiedene Sprachen gestoßen bin, aber meine Programmierung "fühlt" sich immer gleich an, wie mein Schreiben auf fekberg.wordpress.com, ich habe eine "spezielle" Art zu tippen.

Jetzt programmiere ich verschiedene Anwendungen und in verschiedenen Sprachen wie Java, C #, Assembler, C ++, C. Ich bin zu dem "Standard" des Schreibens gekommen, den ich mag.

Ich sehe alles als "Kästchen" oder Regionen und jede Region hat ihre erklärenden Kommentare. Eine Region könnte "Klasse Person" sein und innerhalb dieser Region habe ich einige Methoden für Eigenschaften, die ich "Zugriffsmethoden" oder dergleichen nennen kann, und jede Eigenschaft und Region hat ihre eigenen erklärenden Kommentare.

Dies ist sehr wichtig. Ich sehe meinen Code immer als "Teil einer API" an, wenn das Erstellen einer API-Struktur und Eleganz SEHR wichtig ist.

Denk darüber nach. Lesen Sie auch meinen Artikel Communication issues when adapting outsourcing, in dem grob erklärt wird, wie fehlerhafter Code zu Konflikten führen kann. Geben Sie ein, wie Sie möchten: http://fekberg.wordpress.com/2008/12/14/communication-issues-when-adapting-outsourcing/

Guter Code ist leicht zu verstehen, leicht zu pflegen und leicht zu ergänzen. Im Idealfall ist es auch so effizient wie möglich, ohne andere Indikatoren zu beeinträchtigen.

Großartiger Code ist für mich einfach zu verstehen und dennoch raffiniert. Die Dinge, die dich dazu bringen, "Wow, natürlich, warum habe ich das nicht so gesehen?". Wirklich guter Code ist nicht schwer zu verstehen, er löst das Problem einfach auf einfache Weise (oder auf rekursive Weise, wenn dies noch einfacher ist).

Guter Code ist, wo Sie aus dem Namen wissen, was die Methode tut. Bei schlechtem Code müssen Sie herausfinden, was der Code tut, um den Namen zu verstehen.

Guter Code ist der Ort, an dem Sie, wenn Sie ihn lesen, in nicht viel mehr Zeit verstehen können, was er tut, als zum Lesen erforderlich ist. Schlechter Code ist der Punkt, an dem Sie ihn ewig betrachten und versuchen, herauszufinden, was er tut.

Guter Code hat Dinge, die so benannt sind, dass triviale Kommentare unnötig werden.

Guter Code ist in der Regel kurz.

Guter Code kann wiederverwendet werden, um das zu tun, was er irgendwo anders tut, da er sich nicht auf Dinge stützt, die wirklich nichts mit seinem Zweck zu tun haben.

Guter Code ist normalerweise eine Reihe einfacher Werkzeuge, um einfache Aufgaben zu erledigen (gut organisiert zusammengestellt, um anspruchsvollere Aufgaben zu erledigen). Schlechter Code ist in der Regel ein riesiges Mehrzweckwerkzeug, das leicht zu beschädigen und schwer zu verwenden ist.

Code spiegelt die Fähigkeiten und die Denkweise eines Programmierers wider. Gute Programmierer haben immer ein Auge auf die Zukunft - wie der Code funktioniert, wenn Anforderungen oder Umstände nicht genau so sind, wie sie heute sind. Wie skalabale wird es sein? Wie bequem wird es sein, wenn ich nicht derjenige bin, der diesen Code verwaltet? Wie wiederverwendbar der Code sein wird, damit jemand anderes, der ähnliche Dinge tut, den Code wiederverwenden und nicht erneut schreiben kann. Was ist, wenn jemand anderes versucht, den von mir geschriebenen Code zu verstehen?

Wenn ein Programmierer diese Einstellung hat, passen alle anderen Dinge gut zusammen.

Hinweis: Eine Codebasis wird von vielen Programmierern im Laufe der Zeit bearbeitet, und normalerweise gibt es für einen Programmierer keine spezifische Bezeichnung für die Codebasis. Ein guter Code spiegelt daher alle Standards und die Qualität der Belegschaft des Unternehmens wider.

(Ich benutze "er" unten, weil dies die Person ist, die ich sein möchte , manchmal mit Erfolg).

Ich glaube, dass der Kern der Philosophie eines guten Programmierers darin besteht, dass er immer denkt: "Ich programmiere für mich selbst in der Zukunft, wenn ich diese Aufgabe vergessen habe, warum ich daran gearbeitet habe, was die Risiken waren und wie dies Code sollte funktionieren. "

Als solches muss sein Code:

1. Arbeit (es spielt keine Rolle, wie schnell Code zur falschen Antwort gelangt. In der realen Welt gibt es keine teilweise Gutschrift).
2. Erklären Sie, woher er weiß, dass dieser Code funktioniert. Dies ist eine Kombination aus Dokumentation (Javadoc ist mein bevorzugtes Tool), Ausnahmebehandlung und Testcode. In einem sehr realen Sinne glaube ich, dass Testcode Zeile für Zeile wertvoller ist als Funktionscode, wenn er aus keinem anderen Grund als dem erklärt: "Dieser Code funktioniert, so sollte er verwendet werden, und deshalb sollte ich ihn bekommen." bezahlt."
3. Gepflegt werden. Toter Code ist ein Albtraum. Die Pflege von Legacy-Code ist mühsam, muss aber erledigt werden (und denken Sie daran, es ist "Legacy", sobald es Ihren Schreibtisch verlässt).

Andererseits glaube ich, dass der gute Programmierer niemals folgende Dinge tun sollte:

1. Besessen von Formatierung. Es gibt viele IDEs, Editoren und hübsche Drucker, die Code genau nach den Standards oder persönlichen Vorlieben formatieren können, die Sie für angemessen halten. Ich benutze Netbeans, richte die Formatoptionen einmal ein und drücke ab und zu Alt-Shift-F. Entscheiden Sie, wie der Code aussehen soll, richten Sie Ihre Umgebung ein und lassen Sie das Tool das Grunzen ausführen.
2. Besessenheit über Namenskonventionen auf Kosten der menschlichen Kommunikation. Wenn Sie aufgrund einer Namenskonvention Ihre Klassen "IElephantProviderSupportAbstractManagerSupport" anstelle von "Zookeeper" benennen, ändern Sie den Standard, bevor Sie es der nächsten Person schwerer machen.
3. Vergiss, dass er als Team mit echten Menschen arbeitet.
4. Vergessen Sie, dass die Hauptursache für Codierungsfehler gerade auf seiner Tastatur liegt. Wenn es einen Fehler oder einen Fehler gibt, sollte er zuerst auf sich selbst schauen.
5. Vergiss, dass das, was herumgeht, herumkommt. Jede Arbeit, die er jetzt tut, um seinen Code für zukünftige Leser zugänglicher zu machen, wird ihm mit ziemlicher Sicherheit direkt zugute kommen (denn wer wird der erste sein, der gebeten wird, sich seinen Code anzusehen? Er ist es).

1. Es klappt
2. Es hat Unit-Tests, die beweisen, dass es funktioniert

Der Rest ist Sahnehäubchen ...

• Der beste Code hat eine gewisse Eleganz, die Sie erkennen, sobald Sie ihn sehen.
• Es sieht handgefertigt aus, mit Sorgfalt und Liebe zum Detail. Es wird offensichtlich mit jemandem mit Geschick produziert und hat eine Kunst - man könnte sagen, es sieht eher skulptiert und poliert aus als rau und fertig.
• Es ist konsistent und leicht zu lesen.
• Es ist in kleine, sehr zusammenhängende Funktionen unterteilt, von denen jede eine Sache tut und es gut macht.
• Es ist minimal gekoppelt, was bedeutet, dass Abhängigkeiten gering sind und streng kontrolliert werden, normalerweise durch ...
• Funktionen und Klassen sind eher von Abstraktionen als von Implementierungen abhängig .

Ironischer die besser die Programmierer der weniger unentbehrlich er / sie wird , weil der erzeugte Code von jemandem besser wartbar ist (wie von Eran Galperin durch die allgemeine Zustimmung angegeben).

Meine Erfahrung zeigt, dass auch das Gegenteil der Fall ist. Der schlimmer der Programmierer die schwieriger zu halten sein / ihr Code ist, so unentbehrlicher er / sie wird, da keine andere Seele , die Rätsel erzeugt verstehen kann.

Ich habe ein gutes Beispiel:

Lesen Sie den GWT-Quellcode (Google Web Takedit). Sie werden sehen, dass jeder Dummkopf ihn versteht (einige englische Bücher sind schwerer zu lesen als dieser Code).