Wenn Sie ein Projekt von jemandem übernehmen, um einfache Aktualisierungen vorzunehmen, folgen Sie deren Namenskonvention? Ich habe gerade ein Projekt erhalten, bei dem der vorherige Programmierer überall die ungarische Notation verwendet hat. Unser Kernprodukt hat einen Benennungsstandard, aber wir haben im Laufe der Jahre viele Leute dazu gebracht, benutzerdefinierte Berichte zu erstellen und zu tun, was immer sie wollten.
Ich habe keine Zeit, alle Variablennamen zu ändern, die bereits im Code vorhanden sind.
Ich bin zur Lesbarkeit geneigt, nur um mit ihrer Namenskonvention fortzufahren.
Ja, das tue ich. Es macht es leichter, von den Leuten zu folgen, die es nach dir erben. Ich versuche, den Code etwas aufzuräumen, um ihn lesbarer zu machen, wenn er wirklich schwer zu verstehen ist.
Wenn Sie 40 Stunden damit verbringen, herauszufinden, was eine Funktion macht, weil sie schlecht benannte Variablen usw. verwendet, sollten Sie umgestalten / umbenennen, um Klarheit zu schaffen / Kommentar hinzufügen / alles tun, was für die Situation angemessen ist.
Wenn das einzige Problem darin besteht, dass der weitgehend konsistente Stil, den der Autor verwendet hat, sich vom Unternehmensstandard oder dem, was Sie gewohnt sind, unterscheidet, dann verschwende ich Ihre Zeit damit, alles umzubenennen. Außerdem können Sie eine Quelle an Fachwissen verlieren, wenn der ursprüngliche Autor noch für Fragen zur Verfügung steht, weil er den Code nicht mehr erkennt.
Wenn Sie nicht den gesamten vorhandenen Code zu Ihrem Standard ändern, dann würde ich sagen, dass Sie mit den ursprünglichen Konventionen bleiben sollten, solange Sie diese Dateien ändern. Das Mischen von zwei Arten von Code in derselben Datei zerstört jeden Vorteil, den ein konsistenter Code-Stil hätte, und der nächste Typ müsste sich ständig fragen: "Wer hat diese Funktion geschrieben, wie wird sie heißen - FooBar () oder fooBar ( )? "
Diese Art von Sache wird noch komplizierter, wenn Sie Bibliotheken von Drittanbietern importieren - Sie wollen sie nicht neu schreiben, aber ihr Code-Stil passt vielleicht nicht zu Ihnen. Am Ende haben Sie verschiedene Benennungskonventionen, und es ist am besten, klare Zeilen zwischen "unserem Code" und "ihrem Code" zu zeichnen.
Oft ist es eine Möglichkeit, neue Bugs mit geringem Mehrwert einzuführen, wenn man eine Codebase in Großformat ändert, nur um dem Style Guide zu entsprechen.
Dies bedeutet, dass Sie entweder:
Aktualisieren Sie den Code, an dem Sie arbeiten, um der Richtlinie zu entsprechen, während Sie daran arbeiten.
Verwenden Sie die Konventionen im Code, um zukünftige Wartungsmaßnahmen zu unterstützen.
Ich würde 2. empfehlen, aber die ungarische Notation lässt meine Augen bluten: p.
Wenn Sie Code pflegen, den andere geschrieben haben und den andere nach Ihnen pflegen, schulden Sie es allen Beteiligten, keine unnötigen Änderungen vorzunehmen. Wenn sie in das Quellcodeverwaltungssystem gehen, um zu sehen, was Sie geändert haben, sollten sie sehen, was notwendig war, um das Problem zu beheben, an dem Sie gearbeitet haben, und nicht eine Million Diffs, weil Sie eine Menge globaler Suchen durchgeführt und den Code ersetzt oder umformatiert haben Passen Sie Ihre bevorzugte Klammerkonvention an.
Natürlich, wenn der ursprüngliche Code wirklich saugt, sind alle Wetten aus.
Im Allgemeinen würde ich in diesem Szenario für Konvention und Lesbarkeit über Standards gehen. Niemand mag diese Antwort, aber es ist das Richtige, um den Code langfristig haltbar zu halten.
Wenn ein guter Programmierer Code liest, sollte er in der Lage sein, die Variablennamen zu analysieren und mehrere in seinem Kopf zu verfolgen - solange sie konsistent sind, zumindest innerhalb der Quelldatei. Aber wenn Sie diese Konsistenz brechen, wird es wahrscheinlich den Programmierer zwingen, den Code zu lesen, um etwas kognitive Dissonanz zu erleiden, die es dann ein bisschen schwieriger machen würde, im Auge zu behalten. Es ist kein Mörder - gute Programmierer werden es durchstehen, aber sie werden deinen Namen verfluchen und dich wahrscheinlich auf TheDailyWTF posten.
Ich würde sicherlich weiterhin die gleiche Benennungskonvention verwenden, da es den Code konsistent hält (auch wenn es durchweg hässlich ist) und lesbarer ist als das Mischen von Variablennamenskonventionen. Menschliche Gehirne scheinen ziemlich gut in der Mustererkennung zu sein und Sie wollen nicht wirklich das Gehirn mit einem Kurvenkugel werfen, indem Sie das Muster unentgeltlich brechen.
Das heißt, ich bin alles andere als ein paar der ungarischen Notation, aber wenn das ist, was Sie arbeiten müssen ...
Wenn die Datei oder das Projekt bereits mit einem konsistenten Stil geschrieben wurde, sollten Sie versuchen, diesem Stil zu folgen, auch wenn er Ihrem bestehenden Stil widerspricht. Eines der Hauptziele eines Codestils ist die Konsistenz. Wenn Sie also einen anderen Stil in Code einfügen, der bereits konsistent ist (in sich selbst), verlieren Sie diese Konsistenz.
Wenn der Code schlecht geschrieben ist und ein gewisses Maß an Säuberung erfordert, um ihn zu verstehen, dann wird das Bereinigen des Stils zu einer relevanteren Option, aber Sie sollten dies nur tun, wenn absolut notwendig (besonders wenn es keine Komponententests gibt) Sie haben die Möglichkeit, unerwartete Änderungen vorzunehmen.
Absolut, ja. Der eine Fall, in dem ich nicht glaube, dass es vorzuziehen ist, der Namenskonvention des ursprünglichen Programmierers zu folgen, ist, wenn der ursprüngliche Programmierer (oder nachfolgende Entwickler, die den Code seitdem modifiziert haben) keiner konsistenten Namenskonvention gefolgt ist.
Ja. Ich habe das in einem Standarddokument geschrieben. Ich habe bei meiner jetzigen Firma erstellt:
Der vorhandene Code ersetzt alle anderen Standards und Praktiken (unabhängig davon, ob es sich um branchenweite oder in diesem Dokument enthaltene Standards handelt). In den meisten Fällen sollten Sie Ihren Code aus zwei Gründen an den vorhandenen Code in den gleichen Dateien anpassen:
Persönlich, wenn ich ein Projekt übernehme, das ein anderes Variablenbenennungsschema hat, tendiere ich dazu, das gleiche Schema zu behalten, das vom vorherigen Programmierer verwendet wurde. Die einzige Sache, die ich anders mache, ist für irgendwelche neuen Variablen, die ich hinzufüge, ich setze einen Unterstrich vor dem Variablennamen. Auf diese Weise kann ich meine Variablen und meinen Code schnell sehen, ohne in die Quellhistorie zu gehen und Versionen zu vergleichen. Aber wenn es darum geht, einfach unlesbaren Code oder Kommentare zu erben, werde ich normalerweise durch sie hindurchgehen und sie so gut wie möglich aufräumen, ohne das Ganze neu schreiben zu müssen (es ist dazu gekommen). Organisation ist der Schlüssel zu erweiterbarem Code!
Wenn ich den Code lesen kann, versuche ich, die gleichen Konventionen zu treffen wenn es sowieso nicht lesbar ist, muss ich es umgestalten und damit (je nachdem, was es ist) erheblich verändern
Hängt davon ab. Wenn ich eine neue App erstelle und den Code aus einer Legacy-App mit der Benennung von Mistvariablen klaue, refiniere ich sie, sobald ich sie in meine App bekomme.
Ja .. Es gibt wenig, das frustrierender ist, als in eine Anwendung zu gehen, die zwei drastisch unterschiedliche Stile hat. Ein Projekt, an dem ich vorläufig gearbeitet habe, hatte zwei verschiedene Arten, Dateien zu manipulieren, zwei verschiedene Arten, Bildschirme zu implementieren, zwei verschiedene Fundamentierungsstrukturen. Der zweite Coder ging sogar so weit, dass er die neuen Funktionen zu einer DLL macht, die aus dem Hauptcode aufgerufen wird. Maintence war alptraumhaft und ich musste sowohl Paradigmen als auch Hoffnung lernen, als ich in einer Abteilung war und mit der richtigen arbeitete.
Wenn in Rom tun, wie die Römer tun.
(Außer für Namen von Indexvariablen, z. B. "iArrayIndex ++". Hören Sie damit auf, diese Idiotie zu dulden.)
Ich tue es, aber leider gab es mehrere Entwickler vor mir, die diese Regel nicht eingehalten haben, also habe ich mehrere Namenskonventionen zur Auswahl.
Aber manchmal haben wir die Zeit, die Dinge richtigzustellen, damit es am Ende schön und sauber wird.
Wenn der Code bereits einen einheitlichen Stil hat, einschließlich der Benennung, versuche ich ihm zu folgen. Wenn frühere Programmierer nicht konsistent waren, dann kann ich den Unternehmensstandard oder meine persönlichen Standards anwenden, wenn es keinen Unternehmensstandard gibt.
In jedem Fall versuche ich, die Änderungen zu markieren, indem ich sie mit Kommentaren einrichte. Ich weiß mit heutigen CVS-Systemen, dass dies oft nicht getan wird, aber ich bevorzuge es immer noch.
Leider ist die Antwort meistens ja. Meistens folgt der Code keinen guten Konventionen, so dass es schwierig ist, dem Präzedenzfall zu folgen. Aber für die Lesbarkeit ist es manchmal notwendig, mit dem Fluss zu gehen.
Allerdings , wenn es so klein ist, dass ich eine Menge des bestehenden Codes umnutzen kann, um besser "zu riechen", dann werde ich das tun. Oder, wenn dies Teil eines größeren Umschreibens ist, werde ich auch mit den aktuellen Codierungsstandards beginnen. Aber das ist normalerweise nicht der Fall.
Wenn es in der bestehenden App einen Standard gibt, denke ich, dass es am besten ist, ihm zu folgen. Wenn es keinen Standard gibt (Tabs und Leerzeichen gemischt, Klammern überall ... oh der Horror), tue ich das, was ich für das Beste halte, und führe den vorhandenen Code im Allgemeinen über ein Formatierungsprogramm (wie Vim) aus. Ich werde immer den Kapitalisierungsstil usw. des bestehenden Codes behalten, wenn es einen kohärenten Stil gibt.
Meine einzige Ausnahme von dieser Regel ist, dass ich die ungarische Schreibweise nicht verwenden werde, außer jemand hat eine Waffe an meinem Kopf. Ich werde mir nicht die Zeit nehmen, existierende Sachen umzubenennen, aber alles, was ich neu hinzufüge, wird keine ungarischen Warzen darauf haben.
Tags und Links variables naming-conventions hungarian-notation