it-swarm-eu.dev

Schreiben Sie tatsächlich "sauberen Code"?

Ich habe einige Programmierer gesehen, die ihren Code immer wieder optimiert haben, damit er nicht nur "gut funktioniert", sondern auch "gut aussieht".

IMO, "sauberer Code" ist eigentlich ein Kompliment, das darauf hinweist, dass Ihr Code elegant, perfekt verständlich und wartbar ist. Und der Unterschied ergibt sich, wenn Sie zwischen einem ästhetisch ansprechenden Code und einem stressigen Code wählen müssen.

Also, wie viele von Ihnen schreiben tatsächlich "sauberen Code"? Ist es eine gute Praxis? Was sind die anderen Vor- oder Nachteile davon?

57
ykombinator

Ich würde argumentieren, dass viele von uns keinen sauberen Code schreiben . Und im Allgemeinen das ist nicht unsere Aufgabe. Unsere Aufgabe als Softwareentwickler ist es, ein Produkt zu liefern, das pünktlich funktioniert.

Ich erinnere mich an Joel Spolskys Blog-Beitrag: The Duct Tape Programmer .

Er zitiert aus Coders at Work :

Versenden Sie am Ende des Tages das verdammte Ding! Es ist großartig, Ihren Code neu zu schreiben und ihn sauberer zu machen. Beim dritten Mal wird er tatsächlich hübsch. Aber das ist nicht der Punkt - Sie sind nicht hier, um Code zu schreiben. Sie sind hier, um Produkte zu versenden. - Jamie Zawinsky

Ich erinnere mich auch an Robert Martins Blog-Antwort :

Damit. Seien Sie clever. Sei sauber. Sei einfach. Schiff! Halten Sie eine kleine Rolle Klebeband bereit und haben Sie keine Angst, es zu verwenden. - Onkel Bob

Wenn der Code, den ein Entwickler schreibt, sauber ist UND funktioniert (ist lieferbar), ist es gut für alle. Aber wenn ein Entwickler versucht, sauberen und lesbaren Code auf Kosten der zeitnahen Bereitstellung zu erstellen, ist das schlecht. Lassen Sie es funktionieren, verwenden Sie Klebeband und versenden Sie es. Sie können es später umgestalten und es super schön und effizient machen.

Ja, es ist eine gute Praxis, sauberen Code zu schreiben, aber niemals auf Kosten der Lieferfähigkeit. Der Vorteil der pünktlichen Lieferung eines Klebebandprodukts überwiegt bei weitem den Nutzen von sauberem Code, der nie fertiggestellt und geliefert wurde.

Ein guter Teil des Codes, auf den ich gestoßen bin, ist nicht sauber. Einige sind geradezu hässlich. Aber sie wurden alle freigegeben und in der Produktion verwendet. Einige mögen sagen, dass es unprofessionell ist, unordentlichen Code zu schreiben. Ich stimme dir nicht zu. Die professionelle Sache ist, Code zu liefern, der funktioniert, egal ob sauber oder chaotisch. Der Entwickler muss das Beste tun, was er kann, unabhängig von der vor der Lieferung zugewiesenen Zeit. Dann gehen Sie zurück, um aufzuräumen - das ist professionell. Hoffentlich ist der gelieferte Code kein reines Klebeband und "sauber genug".

54
spong

Sie müssen sicherstellen, dass Ihr Code gut lesbar, sauber und wartbar ist. Das ist es, was alle Programmierer müssen tun.

Aber du sprichst von over styling (wie dieser Begriff besser als Mädchencode ), der nichts als dem Ego seines Autors dient.

Ich habe in der Vergangenheit viele Entwickler gesehen, die so stolz auf ihre Kreation waren (wie in den Toiletten;)), dass sie stundenlang ihren Code bereinigten und polierten. Einige von ihnen waren so akribisch, dass sie dafür sorgten, dass die richtigen Leerzeichen zwischen den Mitgliedern eingehalten wurden.

Es ist zu viel.

Ich finde diese Art von Verhalten kontraproduktiv. In einem professionellen Kontext müssen Sie professionell sein . Sie können Ihre Zufriedenheit erreichen, indem Sie sauberen, gut lesbaren und wartbaren Code schreiben und mit zufriedenen Benutzern oder Kollegen sprechen.

39
user2567

Ich würde der akzeptierten Antwort auf diese Frage nicht zustimmen.

Ihre Verantwortung liegt natürlich beim Versand, aber normalerweise haben Sie auch die Verantwortung, etwas zu versenden, das von Ihnen und zukünftigen Entwicklern so kostengünstig wie möglich gewartet werden kann.

Ich habe Zeit als schlechter Wartungsprogrammierer oder Berater vor Ort verbracht, der ein riesiges undokumentiertes System verstehen und debuggen muss, und ich kann Ihnen sagen, dass schlechte Designs und unordentlicher verwirrender Code zu Stunden oder sogar Tagen verschwendeter Mühe führen können. Ich kann mir viele Situationen vorstellen, in denen ein zusätzlicher Aufwand von N Stunden durch den ursprünglichen Entwickler zu einer Zeitersparnis von 5 N in Bezug auf meine Zeit hätte führen können.

Ich weiß, dass diesbezüglich eine Statistik im Umlauf ist, aber meiner Erfahrung nach wird jede geschriebene Codezeile während der Erweiterung und Wartung 5 bis 20 Mal gelesen.

Also würde ich sagen Code bis auf einen Zentimeter seines Lebens bereinigen. Es braucht Zeit, aber es ist wahrscheinlich eine Nettokostenersparnis über die Laufzeit des Projekts.

24

Würde einer von uns ein Auto kaufen, wenn er weiß, dass unter der Motorhaube alles chaotisch und schwer zu beheben, zu warten oder zu reparieren ist und mehr Ressourcen für den Betrieb erforderlich sind, als es sollte?

Warum sollte es für eine Software anders sein?

Nur weil die Endbenutzer nicht unter die Haube schauen können, heißt das nicht, dass sie es nie erfahren werden. Früher oder später wird es auftauchen.

Beantwortung der Frage "Schreiben Sie tatsächlich 'sauberen Code'?" -- Oh ja.!

21
Sifar

Wenn mit "sauberem Code" gemeint ist, tue ich alles, um sicherzustellen, dass der Code so klar wie möglich ist?

Mist ja.

Je sauberer und klarer der Code ist, desto einfacher ist die Wartung und Sie sparen auf lange Sicht Zeit. Betrachten Sie sauberen Code nicht als Eitelkeit. Betrachten Sie es als eine Investition , um zukünftigen Aufwand und Zeit zu sparen.

18
GrandmasterB

Ehrlich gesagt kommt es darauf an. Ich mag es, wie jeder die Parteilinie darüber ausspricht, dass "alles andere als sauberer, gut dokumentierter Code eine reine Farce ist!", Aber ich arbeite in einem Unternehmen mit lächerlichen Bereitstellungszyklen und ohne Versehen: Ich gebe mein Bestes, aber ich schreibe es Bei viel Code ist es äußerst schwierig, den sauberen, perfekten Code zu schreiben, den alle anderen behaupten , die sie schreiben.

Ich versuche, Code zu schreiben, der leicht von jemandem gepflegt werden kann, der ungefähr meine Fähigkeiten besitzt. Ich kommentiere die kniffligen Teile, benenne die freundlichen Namen der Programme, Variablen und Klassen, stelle sie bereit und gehe weiter. Ich habe keine Zeit, etwas anderes zu tun.

Manchmal fühle ich mich ein bisschen schuldig, aber nicht sehr. Sie sollten einige der Schrecken sehen, mit denen ich täglich zu tun habe. Jahrzehntelanger benutzerdefinierter Code in obskuren Sprachen ohne Dokumentation. Einer meiner Mitarbeiter entwickelt ausschließlich in Visual Basic 6.0 und stellt überall kryptisch benannte Binärdateien bereit. Die Frau, die ich ersetzt habe, programmierte ausschließlich in RPG .

Es ist nur extrem schwer für mich zu glauben, dass jeder nur sauberen Code generiert, so viel schrecklicher Mist, wie ich in meinen Jahren als Programmierer gesehen habe.

15
Satanicpuppy

Ich glaube nicht, dass mir der Begriff "Mädchencode" gefällt, aber sauberer Code = wartbarer Code. Alles andere ist unprofessionell.

In der Regel betrachte ich den nächsten Entwickler, der sich mit meinem Durcheinander befassen muss.

Die meiste Zeit bin ich es ... einige Monate später ... wenn ich mich nicht mehr daran erinnere, wie es funktioniert ... und ich noch weniger Zeit habe, etwas zu ändern.

7
Heath Lilley

Ich versuche, "sauberen Code" im Sinne von Bob Martin zu schreiben (z. B. OO Design). Das Schreiben von sauberem Code hat einen großen Wert. Es ist viel wartbarer.

Dann lasse ich ReSharper es für mich zu "hübschem Code" machen (z. B. Ausrichtung, Zeilenumbrüche usw.). Es gibt gut Wert beim Schreiben von hübschem Code. Aber es gibt sinkende Renditen. Einige Verschönerungen machen es aufgrund der einfachen Lesbarkeit etwas wartbarer.

Wenn Sie der Meinung sind, dass es notwendig ist, große Codeblöcke ordentlich aneinander zu reihen, um sie lesbar zu machen, dann ist das Problem Ihr verdammt großer Codeblock! Es ist zu groß. Ich sehe viele Beispiele von Menschen, die sich große Mühe geben, einen sehr schlecht gestalteten Code zu verschönern.

Wenn ich ReSharper nicht hätte, hätte ich immer noch sauberen Code, aber er wäre nicht ganz so hübsch.

Ich denke nicht, dass ich mehr als ~ 5% meiner Codierungszeit für das Verschönern aufwenden sollte. Das heißt, je leistungsfähiger mein Redakteur ist und je kompetenter ich damit bin, desto schöner kann ich sein.

5
dss539

Es scheint, dass niemand den Punkt anspricht, was im besten Interesse Ihres Unternehmens ist?

Oft, wenn nicht immer, sind Programmierer nur Angestellte, und obwohl die Managemententscheidungen uns möglicherweise frustrieren, verfügen wir oft nicht über alle Daten, die sie haben.

Nehmen wir zum Beispiel an, das Unternehmen hat eine Klausel, wonach Sie nicht bezahlt werden, wenn die Software nicht rechtzeitig fertig ist (es ist uns nur passiert, obwohl ich denke, dass wir die Zahlung doch erhalten haben). Ja, sauberer Code ist wichtig, aber wichtiger ist, dass der Code bis zum Zahlungstag funktioniert!

Ein weiteres Beispiel: Das Unternehmen befindet sich in einer schlechten finanziellen Lage und muss etwas Geld sammeln. Ratet mal, wer Wert auf Qualität legt? Sie können es später reparieren, wenn Sie müssen, versenden Sie es einfach!

Ein Argument könnte sein: "Warum sollte ich ausverkauften und beschissenen Code schreiben?". Warum sollte Ihr Unternehmen Ihnen jeden Monat einen Nice-Scheck zahlen? Entscheidungen, mein Freund. Wenn Sie nach Idealismus suchen, versuchen Sie die Free Software Foundation ; Ich höre, dass sie ziemlich coole Sachen machen (ich meine diese und respektiere FSF und OSS).

Auf der anderen Seite sollten Sie, wenn Sie an einem Projekt arbeiten, bei dem ein explosionsartiger Anstieg der Nutzung erwartet wird (obwohl solche Projektionen fast nie genau sind), eine solide Grundlage mit der besten erforderlichen Codequalität schaffen, da dies mit ziemlicher Sicherheit der Fall ist seien die höheren Kosten für das Projekt.

Programmierer lieben "sauberen" Code, was auch immer das bedeutet. Wir können uns nicht einmal darauf einigen, was sauber ist, aber wir lieben es. Manchmal ist es jedoch nicht so wichtig wie Benutzerfreundlichkeit und Korrektheit. Dies mag synonym erscheinen, ist es aber nicht - wenn Sie Code gesehen haben, der von einem echten Perl-Hacker in 4 Stunden mit der Absicht geschrieben wurde, zweimal verwendet und weggeworfen zu werden, würden Sie anerkennen, dass er nicht sauber ist, aber funktioniert.

Manchmal, abgesehen vom Ego, sollten wir es einfach zum Laufen bringen. Beachten Sie, dass ich nicht empfehle, aus Gewohnheit schlechten Code zu schreiben. Ich weise nur darauf hin, dass es notwendig sein könnte. Perfektion braucht Zeit, die Ihr Unternehmen möglicherweise nicht hat. Wenn es Ihrem Arbeitgeber nichts ausmacht, Software zu erstellen, aber wenn Sie müssen, schreiben Sie einfach Arbeitscode. egal die "Sauberkeit". Es ist einfach keine "Einheitsgröße" -Antwort - Sie sollten Prioritäten setzen.

4
K.Steff

Zu viel von irgendetwas ist niemals gut.

Ein wichtiger Punkt bei "unreinem" Code ist jedoch, dass er leicht zu " zerbrochene Fenster " führen kann. Wenn der Code sehr schlecht formatiert ist, fühlen sich viele Leute, die neu in der Codebasis sind, möglicherweise weniger geneigt, gute Arbeit mit Wartung und Weiterentwicklung zu leisten, was zu einer Abwärtsspirale führt, die sich möglicherweise auf den Betriebszustand der Software auswirkt.

Daher ist die Aufrechterhaltung eines bestimmten Maßes an Sauberkeit im Code nicht nur für Ihre Mitentwickler von Vorteil. Verbringen Sie nicht zu viel Zeit damit (~ 5% wurden erwähnt). Erfahren Sie, wie Sie mit den Werkzeugen Ihres Handwerks manuelle Aufgaben automatisieren (in diesem Fall Code-Formatierung). Übernehmen Sie Verantwortung für das, was Sie tun, und tun Sie immer das, was Ihrer Meinung nach für Ihr Unternehmen/Ihre Kunden/Benutzer am vorteilhaftesten ist.

3
Per Noalt

Dies ist ein Zitat aus Clean Code von Bob Martin:

Um diesen Punkt nach Hause zu fahren, was wäre, wenn Sie Arzt wären und einen Patienten hätten, der verlangt, dass Sie das alberne Händewaschen zur Vorbereitung der Operation beenden, weil es zu lange dauert? Der Patient ist eindeutig der Chef; und doch sollte der Arzt die Einhaltung unbedingt ablehnen. Warum? Weil der Arzt mehr als der Patient über die Risiken von Krankheiten und Infektionen weiß. Es wäre unprofessionell (egal kriminell), wenn der Arzt dem Patienten nachkommt.

Ebenso ist es für Programmierer unprofessionell, sich dem Willen von Managern zu beugen, die die Risiken von Unordnung nicht verstehen.

3

Ich bin mir nicht sicher, ob "gut aussehen" und "elegant, perfekt verständlich und wartbar" gleichwertig sind.

Ich versuche Code zu schreiben, der "elegant, perfekt verständlich und wartbar" ist. Ich überarbeite meinen eigenen Code, um diesen Kriterien besser zu entsprechen.

Ich sehe keine Nachteile, außer den daraus resultierenden Zeitkosten.

Damit Code "gut aussieht", gibt es viele automatisierte Tools, die alles richtig einrücken und platzieren, wie Sie es wünschen.

3
back2dos

Ich mag es, wenn Code lesbar ist, aber das Wichtigste ist die Konsistenz. Für mich bedeutet dies Konsistenz mit Namenskonventionen nd Abstand zwischen Funktionen, Klammern in derselben Zeile oder der nächsten Zeile der if-Anweisung usw.

Natürlich gibt es Zeiten, in denen jemand etwas mit einem konsistenten Codestil programmiert und es mich immer noch wahnsinnig macht. Besonders Code, der nicht "atmet". Zum Beispiel:

void function1(){
    //whatever code
}
int fooBar(){
    //whatever else
}
Foo* someOtherFooBar(int value){
    if(value){
        //do something
    }
    return ...;
}

Nun ... Mit Objective-C-Methoden und mit vielen, vielen verschachtelten if-Anweisungen und Zeilen, die viel länger als 80 Zeichen sind, sieht es schlimmer aus. Aber es nervt mich immer noch :)

2
vedosity

Ich denke, "sauberer Code" sollte genauso sauber oder sauber sein wie früher, als Sie in Ihren Physik-, Ingenieur- und Mathematikprüfungen geschrieben haben. Wenn es zu chaotisch ist, versteht der Grader Ihre Arbeit nicht und markiert sie wahrscheinlich als falsch, selbst wenn sie richtig ist.

2
chiurox

Ich bin sehr bemüht, Code zu bereinigen. Ich denke, es hilft sehr, die Fehler hervorzuheben.

Ich bin nicht mit dem Konzept "Schiff das verdammte Ding jetzt" einverstanden, weil sauberer Code eine Investition in die Zukunft ist. Außerdem wird zu viel Software mit zu vielen Fehlern ausgeliefert. Die Behebung eines Fehlers ist meiner Meinung nach besser als die Implementierung einer neuen Funktion.

Auch wenn Sie sich Schätzungen der Programmiererproduktivität ansehen, denke ich nicht, dass ich sehr schlecht abschneide. Das Schreiben von sauberem Code ist eine Gewohnheit, und je mehr Erfahrung als Programmierer vorhanden ist, desto effizienter wird es. Wenn man es nie versucht, wird man offensichtlich nie Erfahrung damit bekommen.

Ein weiterer zu berücksichtigender Punkt ist, dass die meiste Entwicklerzeit für das Lesen von Code aufgewendet wird, sodass lesbarer Code die Lesezeit erheblich verkürzt. Das Verständnis von undokumentierten Algorithmen kann beispielsweise kostspielig sein und neue Fehler verursachen.

Eine Sache, die ich definitiv vermisse und die ich eines Tages haben möchte, ist ein automatischer Code-Formatierer, den ich an meinen Stil anpassen kann. Das würde mir wirklich Zeit sparen, insbesondere beim Lesen des Codes anderer Leute.

Sauberes Codieren hat eine Verbindung zum Perfektionismus, der das Risiko birgt, niemals zu materialisieren, aber ich denke, dass dies hauptsächlich ein Problem ist, wenn Sie anfangen, weil Sie später investieren und Ihre eigenen eleganten Codeteile wiederverwenden, kombiniert mit Ihrer Erfahrung Wenn Sie älter werden, werden Sie sehr produktiv sein und viel weniger von Fehlern heimgesucht als die unordentlichen Programmierer.

Dies ist ein Stück Code, der meinen Codierungsstil demonstriert.

2
user20416

Vermeiden Sie einfach "Vanity Code". Es gibt viele Entwickler, die Dinge nur aus Eitelkeit (oder aufgrund einer Zwangsstörung) und sonst nichts tun. Mein Höschen wird wirklich mit diesen Leuten verdreht.

1
ElGringoGrande

Ich schreibe Code, der versucht, das gegebene Problem auf die effizienteste und theoretisch 'eleganteste' Weise zu lösen. Nur in diesem Sinne ist es sauber. Wenn es "hübsch" ist, wenn ich fertig bin, soll es so sein.

Was ich in meinen begrenzten Erfahrungen festgestellt habe, ist, dass, wenn sich Leute über "sauberen Code" beschweren, die Hässlichkeit normalerweise eher auf eine schreckliche Lösung als auf eine Codierungskonvention zurückzuführen ist.

1
Kurtis

Ich würde sagen, ich bemühe mich, saubereren Code zu schreiben, aber das kann sich aus Zeitgründen ändern oder wenn ich an etwas Schwierigem arbeite. Es neigt dazu, chaotisch zu werden, wenn man sich darauf konzentriert, dass es funktioniert. Dann gehe ich zurück und räume auf, während ich es überprüfe. Wenn Sie zum Code zurückkehren und zu viel Zeit damit verbringen müssen, Ihr Gedächtnis aufzufrischen, haben Sie es nicht genug kommentiert.

Sauberer Code ist gut, aber wie alles andere muss er nur sauber genug sein. Das Einrücken von 5 Zeilen Code 4 Leerzeichen und einer Zeile 5 Leerzeichen erhöht die Leseschwierigkeiten nicht.

1
JeffO

Ich denke, es hängt davon ab, was Sie tun. Wenn ich eine Proof-of-Concept-Anwendung schreibe, dann codiere ich meinen Arsch im Grunde genommen als Cowboy ab und schaue nicht zurück. Wenn ich an einer Anwendung arbeite, an der ich tatsächlich eine Weile arbeiten werde, stelle ich sicher, dass ich sie gut genug codiere und sie in einem Monat verständlich mache.

Ich denke, dass das Stylen Ihres Codes etwas zweifelhaft ist. Wie einige oben gesagt haben, besteht Ihre Aufgabe darin, ein Produkt zu erstellen, nicht formatierten Code, aber ich würde zumindest sagen, dass man sich an einen definierten Stil des Kommentierens und Codierens halten sollte. Ich würde es hassen, die Hälfte der Variablen Kamel und die andere Hälfte Ungarisch zu sehen.

Aber es kommt auch darauf an, was Sie unter "Clean-Code" verstehen.

1
user7007

Wenn Sie Ihren Code umgestalten, um ihn elegant zu gestalten, ist er leichter zu lesen und zu warten. Auch kleinere Dinge wie das Ausrichten Ihrer Variablenzuweisungen:

int foo    = 1;
int bar    = 2;
int foobar = 3;

ist leichter zu lesen als

int foo = 1;
int bar = 2;
int foobar = 3;

das heißt, es ist einfacher zu überfliegen, wenn Sie später debuggen.

Außerdem dürfen Sie in PHP beliebig viele zufällige Codeblöcke) logische Aufgaben gruppieren:

// do x
{
    // ...
}

// do y
{
    // ...
}

Dies fügt dem relevanten Code eine klare Definition hinzu.

Bearbeiten: Als zusätzlichen Bonus können Sie einem dieser logischen Codeblöcke einfach ein if (false) voranstellen, wenn Sie ihn vorübergehend überspringen möchten.

0
Craige

Ich gebe zu, das zu tun; und der Vorteil ärgert sich nicht jedes Mal, wenn ich es sehe. Ich denke, es ist auch einfacher zu lesen, und daher werden Fehler offensichtlicher. aber der wahre Grund ist, dass ich hässlichen Code nicht ausstehen kann.

0
user281377