Folgen Sie den Namenskonventionen des ursprünglichen Programmierers?

8

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.

    
wonderchook 12.11.2008, 14:34
quelle

20 Antworten

26

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.

    
kemiller2002 12.11.2008, 14:37
quelle
5
Ich stimme zu, dass der Code so bleibt, wie der Autor schrieb, es ist in Ordnung, solange dieser Code intern konsistent ist. Wenn der Code wegen Inkonsistenz schwer zu befolgen ist, haben Sie eine Verantwortung gegenüber dem zukünftiger Betreuer (wahrscheinlich Sie), um es klarer zu machen.

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.

    
Sam Hoice 12.11.2008 14:54
quelle
5

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.

    
Enno 12.11.2008 14:41
quelle
3

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:

  1. Aktualisieren Sie den Code, an dem Sie arbeiten, um der Richtlinie zu entsprechen, während Sie daran arbeiten.

  2. 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.

    
Aaron Maenpaa 12.11.2008 14:39
quelle
3

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.

    
Paul Tomblin 12.11.2008 14:40
quelle
2

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.

    
John Rudy 12.11.2008 14:40
quelle
2

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 ...

    
Timo Geusch 12.11.2008 14:40
quelle
2

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.

    
Scott Dorman 12.11.2008 14:42
quelle
2

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.

    
Greg D 12.11.2008 14:43
quelle
2

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:

  1. Um zu vermeiden, dass mehrere unterschiedliche Stile / Muster innerhalb eines einzelnen Moduls / einer einzigen Datei vorhanden sind (die dem Zweck von Standards widersprechen und die Wartbarkeit beeinträchtigen).
  2. Der Aufwand, den vorhandenen Code zu refaktorisieren, ist unnötig kostspieliger (zeitraubend und für die Einführung neuer Fehler förderlich).
Kon 12.11.2008 15:43
quelle
1

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!

    
John Chuckran 12.11.2008 14:40
quelle
1

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

    
Bluenuance 12.11.2008 14:40
quelle
1

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.

    
John Dunagan 12.11.2008 14:41
quelle
1

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.

    
baash05 12.11.2008 14:44
quelle
1

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.)

    
Leonardo Herrera 12.11.2008 14:45
quelle
1

Ich denke daran, einen Fehler als chirurgischen Eingriff zu beheben. Steigen Sie ein, stören Sie so wenig wie möglich, reparieren Sie es, gehen Sie hinaus und lassen Sie so wenig wie möglich von sich zurück.

    
Metro 12.11.2008 14:48
quelle
1

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.

    
Toon Krijthe 12.11.2008 14:57
quelle
1

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.

    
Jim C 12.11.2008 15:06
quelle
1

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.

    
Chris Conway 12.11.2008 15:14
quelle
0

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.

    
rmeador 12.11.2008 15:43
quelle