Lohnt es sich, die Namensrichtlinien zu beachten?

Ich benenne meine Variablen mit den .Net-Konventionen:

• camelCase für Variablen und Felder (ich benutze _camelCase normalerweise für private Felder in einer Klasse)
• PascalCase für Methoden, Eigenschaften und Klassen

Der einzige Punkt, von dem ich abweichen kann, sind Konstanten und Enums, bei denen ich den Java-Stil SCREAMING_CAPS bevorzuge.

Die Codebasis meines Unternehmens ist mit dem pseudo-ungarischen Notationsstil von VB6 und VBScript übersät, wenn nicht vollständig ungarisch, d. H

• s oder str für Strings
• i oder int für Ints
• d für dezimal (oder manchmal doppelt)
• o oder obj für irgendeine Art Gegenstand

Ich zucke zusammen, wenn ich diesen Codestil sehe, der im Code eines anderen verwendet wird (auch im Greenfield-Code, nicht nur in der alten Cruft), und lehne es ab, diesen Stil selbst zu verwenden. Ich habe in der Vergangenheit die Standardisierung der .Net-Namenskonventionen eingeführt und sie wird einfach ignoriert - die Leute, die in ungarischer Schreibweise schreiben, tun dies weiterhin, diejenigen von uns, die mich nicht mögen, verwenden weiterhin unseren eigenen Stil. Ich bin ein wenig Angst , dass , wenn wir tun standardisiert (die ich drängen halten für, aber niemand scheint anders zu Pflege), auf ungarische Notation sein würde und nicht der empfohlene Weg , und dann werde ich zu schreiben Code gezwungen werden , wie die .

Mache ich in dieser Hinsicht einen Berg aus einem Maulwurfshügel? Sollte es mich nicht interessieren, ob der Code mit redundanten Bezeichnern und nicht beschreibenden Namen übersät ist, und sollte ich weiterhin meinen eigenen Weg gehen und darauf drängen, dass dies zum Standard wird?

Das Einzige, worauf Sie achten sollten, ist, dass Sie in einem Team arbeiten, in dem es den Leuten nichts ausmacht, Dinge ein wenig aufzuräumen. Das ist sehr traurig.

Tu was du tust, benutze weiterhin den modernen Stil und lade die Leute ein (aber zwinge sie nicht), ihn auch anzunehmen. Es wird natürlich einige Zeit dauern. Nach einiger Zeit werden Sie sehen, ob es irgendwohin geht und was Sie als nächstes tun könnten.

PS: Vereinbaren Sie ein Treffen zu diesem Thema und laden Sie alle Beteiligten ein. Dann werden Sie ihre volle Aufmerksamkeit erhalten, das Problem benennen und Ihren Ansatz vorstellen. Es wird ihnen etwas zum Nachdenken geben. Vielleicht nehmen sie Sie von Ihren lokalen Versuchen nicht sehr ernst.

Ich denke, Sie müssen sich vielleicht fragen, ob die ungarische Schreibweise Ihre persönliche Leistung / Qualität beeinflusst oder ob sie Ihrem Ego eher schadet. Mit Ego meine ich, dass die Dinge im Allgemeinen gut funktionieren, aber Sie möchten niemals, dass jemand, den Sie von außen respektieren, den schändlich veralteten Code sieht. Obwohl ich der Meinung bin, dass diese Sorge ihren eigenen Wert hat, muss man sie gegen den Qualitäts- / Produktivitätsverlust abwägen, den jeder, der wechseln müsste, hinnehmen würde.

Dies ist eine Art technische Schuldenfrage, da Sie eindeutig richtig sind, dass dieser ungarische Stil in .Net keinen Sinn macht (mit Ausnahme der Schnittstellen mit "I", aber das ist für ein anderes Mal), dies könnte jedoch die Art sein Die technischen Schulden, mit denen Ihr Team leben kann, verschwinden auf natürliche Weise .

Das beste Argument gegen die ungarische Notation, neben modernen IDEs, die viele Methoden haben, um den Typ, die Sichtbarkeit und mehr von einer Variablen mit der Farbe zu zeigen, mit winzigen Symbolen und mit Tooltiptexten während des Staubsaugens, ist, es ernst zu nehmen.

• Ermutigen Sie mehr Distintcion (b) ool (f) loat (c) har (l) ong (s) hort (Konflikte mit String? No: (S) tring), (v) oid.
• Ermutigen Sie, die Sichtbarkeit zu verschlüsseln. Ich komme aus Javaland und hoffe, dass es auch für .net passt: (privates), (öffentliches), (geschütztes), (defektes) Ault sollte verwendet werden.
• .net hat final / const? Machen Sie es ein Präfix! Höre ich "volatile"?
• Warum brauchen int und long ein Präfix, andere Objekte jedoch nicht? Das ist nicht logisch. Erstellen Sie eine abbrev.tab. Dabei erhält jedes neue Objekt eine eindeutige Abkürzung.
• Variablen, die Null sein könnten und solche, die niemals Null sein sollten, können ebenfalls vorangestellt werden. Clevere Leute setzen den gesamten DbC in das Präfix einer Variablen.

Im Ernst: Beim Refactoring können Sie eine Variable von int in long, von String in char ändern. Sie sollten auch den Namen nicht ändern müssen.

In IDEs werden die Namen häufig in einem Kästchen an der Seite sortiert. sortiert nach Namen, wo es leicht zu finden ist. Wenn die meisten Variablen mit o oder i beginnen, ist es für die Augen störend, zum signifikanten Teil des Namens zu gelangen.

Die zusätzlichen Zeichen stören die Semantik der Variablen. Eine Ganzzahl 'sane' erhält 'i_sane', was eher wie 'insane' aussieht.

Die ungarische Notation war hilfreich in Sprachen, denen ein Typensystem fehlt. Sie brauchen es nicht, wenn der Compiler bestimmte Typen erzwingt. Wenn Sie Ihr Klagelied über die ungarische Notation mit einem einfühlsamen "Ja, für die älteren Programmierer war es in der Vergangenheit sinnvoll, es zu verwenden!" Schmücken, könnten diese älteren Programmierer vergeblich sein und es vorziehen, nicht als alt identifiziert zu werden.

Aber Sie müssen vorsichtig sein, damit die Technik funktioniert. Vielleicht kannst du deine Stimme senken, wenn du von "älteren Programmierern" sprichst, um sie fühlen zu lassen, wie vorsichtig du mit ihnen bist, wie sehr sie der Pflege bedürfen. Damit eine dritte Person im Raum erkennt, dass Sie versuchen, etwas zu verbergen, was natürlich seine Neugier weckt.

Kaufen Sie eine Kopie der Framework Design Guidlines und legen Sie sie auf dem Schreibtisch Ihres Managers (oder der Person, die den Codierungsstil kontrolliert) ab. Stellen Sie sicher, dass Sie einen Post-It-Note einfügen, der auffällig auf die Einleitung verweist, in der die Bedeutung der Konsistenz hervorgehoben wird. Um weiter nach Hause zu fahren, besorgen Sie sich eine Kopie von Clean Code und setzen Sie dort ein Lesezeichen im Abschnitt über Kodierungskonventionen.

In mancher Hinsicht ist dies ein subjektives Problem, und es ist eine dieser Programmierminutendebatten (Rechtschreibung?), Die ich für eine Weile unterhalte und dann vermeide. Während ich denke, dass die ungarische Notation eine Sünde ist, die verbannt werden sollte, halte ich Konsistenz für wichtiger.

In diesem Sinne werde ich mein Bestes tun, um ein Team davon zu überzeugen, domänenorientierte Variablennamen anstelle typbasierter Namenskonventionen zu verwenden. Wenn es jedoch zu schwierig wird, werde ich mich zurückziehen, um einen Standard für die Benennung zu akzeptieren, den jeder einhalten muss eine gemeinsame Code-Basis.

Ich bin nicht für einen generisch vorgeschriebenen Standard, den eine Standardgruppe auferlegt, sondern dafür, dass Softwareteams ihren eigenen Standard entwickeln und, was noch wichtiger ist, daran festhalten.

Das Umbenennen von Variablen mit dem Resharper geht so schnell, dass ich unüberlegte Namenskonventionen so schnell rückgängig machen kann, dass ich die alten, falsch bezeichneten Konventionen nicht mehr stehen lassen muss.

Wenn Sie keine Refactoring-Tools haben, stimme ich den anderen Kommentatoren zu, die vorgeschlagen haben, die bestehende Konvention der Codebasis so weit wie möglich zu befolgen, auch wenn sie falsch war. (Bis zu einem gewissen Punkt gibt es Konventionen für die Benennung von Variablen, die sich in Fehlergeneratoren verwandeln, wenn Sie dies zulassen.)

Die meisten Ihrer Bedenken sind berechtigt und würden das Leben eines neuen Entwicklers und wahrscheinlich Ihren Verstand erleichtern. Die eine Konvention, die Sie alle übernehmen sollten, sind beschreibende Namen. Sie sollten in der Lage sein, einen Konsens darüber zu erzielen, ohne die Stile drastisch zu ändern, je nachdem, wie schlecht sie sind. Warten Sie für alles andere, bis Sie die Verantwortung tragen, oder ersetzen Sie aktuelle Mitglieder durch neue Entwickler, die so denken und fühlen, wie Sie es tun.

Meine Abweichungen:

• _PublicPropertyBacker
• _private_property_backer
• _privateMember
• CONSTANT_MEMBER
• privateFunktion
• param_
• privater Knopf okBU; //etc. 3 Zeichen begrenzen
• struct SOMESTRUCT // für Pinvoke-Strukturen

Generische Coderegionen und Dateilayout:

• Mitglieder
  • (privat | intern | geschützt | öffentlich) X [statisch] X [const / readonly]
• Eigenschaften
  • (privat | intern | geschützt | öffentlich) X [statisch] X [schreibgeschützt]
• Konstruktoren
  • (privat | intern | geschützt | öffentlich) X [statisch]
• Befehle // alles mit void return oder status return
  • (öffentlich | geschützt | intern | privat) X [statisch]
• Event-Handler / privat /
  • (Control | Remote | Service | Other) Ereignisse
• Funktionen // den Zustand abfragen, sollten keine Nebenwirkungen haben
  • (öffentlich | geschützt | intern | privat) X [statisch]