it-swarm-eu.dev

Stellen Sie Variablennamen eine Abkürzung für die Variablentypen voran? (Ungarische Notation)

In meinem aktuellen Job gibt es keine Kodierungsrichtlinien. Jeder codiert so ziemlich so, wie er will. Was in Ordnung ist, da das Unternehmen klein ist.

Ein neuer Typ schlug jedoch kürzlich vor, immer die ungarische Notation zu verwenden. Bis jetzt haben einige von uns eine ungarische Notation verwendet, andere nicht. Sie wissen, es ist ein Ingenieurbüro, daher spielen Codierungsstile keine Rolle, solange die Algorithmen solide sind.

Persönlich halte ich diese kleinen Typabkürzungen für überflüssig. Ein gut durchdachter Name liefert normalerweise die gleiche Nachricht. (Außerdem muss der größte Teil unseres Codes auf einigen verrückten DSPs ausgeführt werden, bei denen ein Konzept wie bool oder float sowieso nicht existiert.).

Wie stehen Sie zur ungarischen Notation? Benutzt du es? Warum?

37
bastibe

Wenn die meisten Leute "Ungarische Notation" sagen, sprechen sie tatsächlich von " Systems Hungarian ".

Systems Hungarian ist völlig nutzlos und sollte vermieden werden. Es ist nicht erforderlich, den Typ der Variablen in ihrem Namen zu codieren. Systems Hungarian ist jedoch tatsächlich ein Missverständnis des ursprünglichen , "echten" Ungarisch: Apps Ungarisch.

In Apps Hungarian codieren Sie nicht den "Typ" im Variablennamen, sondern die "Art" der Variablen. Also nicht nWidth, sondern pxWidth oder emWidth (für "Breite in Pixel" bzw. "Breite in ems"). Nicht strName, sondern sName oder usName (für "sicherer Name" bzw. "unsicherer Name" - nützlich, wenn Eingaben von Benutzern akzeptiert werden: unsichere Zeichenfolgen).

Persönlich kümmere ich mich normalerweise auch nicht darum. Es sei denn, ich mache etwas, das explizit die "Art" eines Werts konvertiert (zum Beispiel habe ich in der Vergangenheit die Präfixe "px" und "em" verwendet, weil dadurch Fehler wie pxArea = emWidth * emHeight Offensichtlich werden). .

Siehe auch Joels Artikel " Falschen Code falsch aussehen lassen ".

77
Dean Harding

pronounYou verbShould adverbNever verbUse adjectiveHungarian nounNotation, prepositionIt verbMakes collectivenounEverything adverbSo compareativeBloody adjectiveHard infinitiveTo verbRead.

31
smirkingman

Zuerst:

Sie wissen, es ist ein Ingenieurbüro, daher spielen Codierungsstile keine Rolle, solange die Algorithmen solide sind.

Codierungsstile spielen unabhängig vom Unternehmen eine Rolle. Ja, die Algorithmen haben müssen solide sein, aber der Code muss kann von jedem gewartet werden, nicht nur vom ursprünglichen Entwickler. Ein Codierungsstandard, der Stilelemente enthält, trägt dazu bei, dies zu erreichen. Ich sage nicht, dass der gesamte Code im Stil identisch sein sollte - das wäre kontraproduktiv, aber es sollte ein gewisses Maß an Konsistenz geben.

Nun zur ungarischen Notation:

Während es seine Verwendung hatte, ist es mit einem modernen IDE, das das Verhalten des IntelliSense-Typs unterstützt) nicht erforderlich, den Typ der Variablen in seinen Namen aufzunehmen. Diese Informationen stehen Ihnen auf andere Weise zur Verfügung. Schlimmer noch Dies kann das Lesen des Codes erschweren, wenn Sie den Typ der Variablen in Zukunft ändern müssen.

26
ChrisF

Benutze es nicht. Es ist redundant und erschwert das Lesen von Code.

21
codeape

Ein Großteil der Debatte über die (systemische) ungarische Notation hängt vom Arbeitsbereich ab. Früher war ich sehr fest auf der Seite von "no way!", Aber nachdem ich einige Jahre in einem Unternehmen gearbeitet habe, in dem es für die Embedded-Entwicklung verwendet wird, sehe ich einige Vorteile in bestimmten Anwendungen und es ist definitiv auf mich gewachsen .

Systeme Ungarisch

Soweit ich weiß, wird Systems Hungarian im Embedded-Bereich häufig verwendet. In PC-Anwendungen wird sich der Compiler mit vielen Problemen befassen, die mit den Unterschieden zwischen (z. B.) Zeichenfolgen, Ganzzahlen und Gleitkommawerten verbunden sind. Auf einer tief eingebetteten Plattform sind Sie häufiger besorgt über die Unterschiede zwischen 8-Bit-Ganzzahlen ohne Vorzeichen, 16-Bit-Ganzzahlen mit Vorzeichen usw. Der Compiler (oder sogar Flusen mit erzwungenen MISRA-Regeln) greift diese nicht immer auf. In diesem Fall mit Variablennamen wie u8ReadIndex, s16ADCValue kann hilfreich sein.

Apps Ungarisch

Apps Ungarisch hat bestimmte Vorteile, wenn es um PC-/Webanwendungen geht, z. B. einen visuellen Unterschied zwischen "unsicheren" und "sicheren" Zeichenfolgen (dh von Zeichen, die von einem Benutzer eingegeben wurden, und solchen, die von internen Ressourcen oder was auch immer maskiert oder gelesen wurden) ). Der Compiler kennt diese Unterscheidung nicht.

Was ist der Punkt?

Bei der Verwendung von (Systemen oder Apps) Ungarisch geht es darum, falscher Code sieht falsch aus.

Wenn Sie eine unsichere Zeichenfolge direkt in eine sichere Zeichenfolge kopieren, ohne dass sie entweicht, sieht es falsch aus, wenn Sie Apps Hungarian verwenden.

Wenn Sie eine vorzeichenbehaftete Ganzzahl mit einer vorzeichenlosen Ganzzahl multiplizieren, wird der Compiler die vorzeichenbehaftete Ganzzahl (häufig stillschweigend) zu einer (möglicherweise enormen) vorzeichenlosen Ganzzahl heraufstufen, was möglicherweise zu einem Fehler führt: Systems Hungarian lässt dies falsch aussehen.

In beiden Situationen führt die ungarische Notation (Apps/Systeme) dazu, dass formale Codeüberprüfungen schneller durchgeführt werden, da weniger auf den Typ der Variablen zurückgegriffen wird.

Insgesamt

Insgesamt ist meiner Meinung nach das Wichtigste, dass Sie einen Codierungsstandard haben. Ob dies ungarische Systeme, ungarische Apps oder keines von beiden verwendet, hängt von der persönlichen oder Gruppenpräferenz ab, ähnlich wie bei der Auswahl der Einrückungstypen usw. Es gibt jedoch eindeutige Vorteile für das gesamte Entwicklungsteam, das mit derselben Präferenz arbeitet.

13
DrAl

Der Zweck der ungarischen Notation besteht darin, Informationen in den Bezeichner zu codieren, die im Typsystem sonst nicht codiert werden können. Meine eigene Meinung ist, dass wenn diese Informationen wichtig genug sind, um codiert zu werden, sie wichtig genug sind, um im Typsystem codiert zu werden, wo sie ordnungsgemäß überprüft werden können. Und wenn die Informationen nicht wichtig sind, warum zum Teufel möchten Sie dann Ihren Quellcode damit überladen?

Oder, um es kurz zu machen: Typinformationen gehören in das Typsystem. (Hinweis: Es muss kein statisches Typsystem sein. Solange es die Typfehler abfängt, ist es mir egal wenn es sie fängt.)

In einigen anderen Antworten wurden Maßeinheiten als akzeptable Verwendung der ungarischen Notation genannt. (Ich bin ein bisschen überrascht, dass noch niemand den NASA Mars Climate Orbiter erwähnt hat, da dies in Diskussionen über die ungarische Notation immer wieder auftaucht).

Hier ist ein einfaches Beispiel in F #:

[<Measure>] type m
[<Measure>] type ft

let someLength      = 48.15<m>
let someOtherLength = 16.2342<ft>

someLength + someOtherLength
// someLength + someOtherLength
// -------------^^^^^^^^^^^^^^^
// error FS0001: The unit of measure 'ft' does not match the unit of measure 'm'.

Schau, Ma, keine Ungarn!

Wenn ich die ungarische Notation anstelle von Typen verwenden würde, würde mir das kein bisschen helfen:

let mSomeLength       = 48.15
let ftSomeOtherLength = 16.2342

mSomeLength + ftSomeOtherLength
// > val it : float = 64.3842

Der Compiler ließ es direkt durch. Ich verlasse mich jetzt auf einen Menschen , um zu erkennen, was im Wesentlichen ein Typfehler ist. Ist das nicht was für eine Typprüfung?

Noch besser mit der Programmiersprache Frink :

someLength      = 48.15m
someOtherLength = 16.2342ft

someLength + someOtherLength
// 53.09818416 m (length)

// Wanna know the answer in a good old fashioned American unit?
someLength + someOtherLength -> yd
// 58.06888031496062992

// Are you an astrophysicist?
someLength + someOtherLength -> parsec
// 1.7207949554318336148e-15

// ... or a fundmentalist Christian who refuses to use units invented 
// less than 2000 years ago?
someLength + someOtherLength -> biblicalcubits
// 95.893563822870765006

Zusammenfassend: Ich mag die ungarische Notation nicht. Sie sollten es niemals benutzen.

Trotzdem halte ich die Verwendung der ungarischen Notation für eine gute Idee. Warte was?

Ja! In diesem speziellen Fall haben Sie Folgendes erwähnt:

Darüber hinaus muss der größte Teil unseres Codes auf einigen verrückten DSPs ausgeführt werden, bei denen ein Konzept wie bool oder float sowieso nicht existiert

Aber das ist genau der einzig sinnvolle Anwendungsfall für ungarische Notation!


PS: Ich empfehle von ganzem Herzen, Frink anzuschauen. Das Handbuch enthält einige der großartigsten Furz-Witze aller Zeiten. Es ist auch eine ziemlich coole Sprache :-)

9
Jörg W Mittag

MIST NEIN!

Verwenden Sie keine ungarische oder eine andere Notation. Als Programmierer sollten wir für unsere Variablennamen keine "Notation" verwenden.

Was wir tun sollten, ist benenne unsere Variablen gut:

  • Vermeiden Sie zu allgemeine Namen. Nennen Sie es nicht z, wenn es sich um eine Klassenvariable handelt, die ein benanntes Objekt darstellt, z. B. eine Telefonrechnung. Nennen Sie es phoneBill oder PhoneBill.
  • Vermeiden Sie zu spezifische Namen. Wenn etwas ohne zusätzliche Informationen klar ist, schließen Sie es nicht ein. Wenn es sich nur um eine Zeichenfolgenindexvariable zum Durchlaufen der Zeichen einer Zeichenfolge handelt und Sie sie nur einmal in der Funktion MyFunc verwenden, warum um alles in der Welt würden Sie sie jemals MyFuncTempStringCharacterIndex nennen? Das ist ein trauriger Witz. Nennen Sie es Pos oder sogar i, wenn Sie möchten. Im Kontext wird der nächste Programmierer leicht verstehen, was es bedeutet.

  • Berücksichtigen Sie bei der Festlegung, wie allgemein oder spezifisch ein Name sein sollte, die Domäne, in der er sich befindet, und den Kontext anderer möglicher Bedeutungen. In dem engen Fall, in dem es zwei leicht zu verwechselnde Elemente ähnlichen Typs gibt, die auf die gleiche Weise verwendet werden, ist es in Ordnung, ein Präfix oder Suffix zu erstellen, um diesen Unterschied zu kennzeichnen. Halte es so kurz wie möglich.

Wie andere Antwortende gesagt haben, ist es dieser enge Fall, der "Apps Hungarian" gestartet hat, um zwischen Messungen relativ zum Fenster rwTabPosition und relativ zum Dokument rdTabPosition zu unterscheiden. Fügen Sie in einer Anwendung, die alles in Bezug auf das Dokument erledigt, keine zusätzliche Cruft hinzu! Warum nicht Jörg W Mittag's Idee verwenden, um daraus einen neuen Typ zu machen? Dann kann man unmöglich die Dinge durcheinander bringen.

In fast allen Bereichen verringert das Hinzufügen von Dingen mit minimaler Bedeutungsdichte die allgemeine Aussagekraft und das Verständnis. Hier ist ein Beispiel von Ben Franklin . Und noch ein Beispiel: Auf Englisch ist es möglich, unsere Worte mit ihrem Wortteil zu dekorieren. Es sind mehr Informationen, nicht wahr? Falls Anfänger in Englisch verwirrt sind, könnte es ihnen wirklich hilfreich sein, oder? Lesen Sie dies und sagen Sie mir, wie nützlich dies Ihrer Meinung nach für das langfristige Verständnis und die effiziente Weitergabe von Informationen ist:

vrbDo advnot vrbuse nouHungarian nounotation cnjor adjany adjother nounotation. prepAs nouprogrammers, prowe vrbshould nicht verbe nouusing "Nomenotation" prpfor proour adjvariable Nomenamen.

Durch Hinzufügen Informationen machte ich das zu einem völligen Schmerz beim Lesen.

Vergessen Sie also die Notation. Vergessen Sie spezielle Präfixe, die Sie immer hinzufügen. Meiner Meinung nach sollte die einzige wirkliche Richtlinie hier sein:

Behalten Sie Variablennamen als kurz wie möglich, als sinnvoll wie erforderlich und immer eindeutig bei.

6
ErikE

In einer objektorientierten Sprache macht es keinen Sinn - alles ist ein Typ, der beim Versuch, es zu verwenden, offensichtlich wird.

6
billy.bob

Der einzige Ort, an dem ungarische Systeme gewarnt werden, ist eine schwach typisierte Sprache wie C. Bei C ist dies doppelt wichtig, da es kein explizites Objekt gibt (es hat Strukturen) , aber alle Funktionen sind außerhalb der Struktur). In etwas stärker typisiertem wie C++, Java und C # hilft es nicht und macht die Sache sogar noch schlimmer. Code ändert sich, und es ist viel einfacher, einen Typ zu ändern, als alle Stellen zu ändern, an denen Sie einen Variablennamen verwenden. Es ist auch unnötige Arbeit, die ignoriert wird.

Wenn Sie Maßeinheiten haben, kann es hilfreich sein, diese in einem Namen zu codieren - aber am Ende kann dies auch zusätzliches Rauschen sein. Zum Beispiel werden wir die Standardmaßeinheit für die verschiedenen Dinge deklarieren, mit denen wir in unserem Code arbeiten. Verwenden wir beispielsweise Farbverläufe oder Grad, Meter oder Fuß, Rahmen oder Millisekunden? Sobald der Standard für den Code festgelegt ist, konvertieren wir jedes Mal, wenn wir eine Maßeinheit einlesen, sofort in die Standardmaßeinheit für den Code.

Mein Rat: Beginnen Sie mit Ihren aktuellen Schwachstellen und wählen Sie einen angemessenen Standard für diesen Teil des Codes. Eine Überspezifikation eines Codierungsstandards ist kontraproduktiv. Es ist sehr wertvoll, Variablen- und Feldnamen zu haben, die genau angeben, was sie darstellen, und meistens können Sie den Typ sicher aus dem Konzept ableiten.

6
Berin Loritsch

Der Zweck eines Bezeichners ist wichtiger als sein Typ. Wenn Sie in Ihren Programmen beschreibende Namen für Bezeichner verwenden, müssen Sie keine ungarischen Notationen verwenden. isConnected ist immer besser lesbar und leicht zu verstehen als boolConnected.

5
Mudassir

Wir haben Ungarisch verwendet, als ich ein C++ - Programmierer war, und es war großartig. Sie können den Typ einer Variablen (z. B. BSTR, CString, LPCTSTR oder char *) anzeigen, ohne nach der Deklaration zu suchen. In jenen Tagen würden Sie nach der Erklärung suchen, indem Sie Folgendes tun:

  1. strg-Home
  2. strg-F
  3. variablennamen
  4. eingeben

Es war also ziemlich wichtig. Aber irgendwann um das Jahr 2000 passierten einige Dinge:

  • die Editoren wurden intelligent genug, um den Variablentyp als Tooltip anzuzeigen
  • die Redakteure hatten eine Verknüpfung "Zur Deklaration gehen" und eine schnelle Möglichkeit, zurück zu blättern
  • C++ wurde weniger verwendet und die meisten anderen Sprachen haben weniger Variablentypen. In C # sind Sie beispielsweise ziemlich sicher, dass lastName ein System.String Ist, da es nur eine Zeichenfolgenklasse gibt.

Ich war einer der letzten, die sich vom Ungarischen abwandten, und jetzt, wo ich alten Quellcode lese, nervt mich das tatsächlich.

2
Andomar

Ich hasse nur die ungarische Notation, ich bevorzuge die Verwendung von Unterstrichen gegenüber der Abgrenzung von Variablennamen.

Wenn Sie den Typ als Anfangsbuchstaben am Anfang Ihres Variablennamens wie folgt einfügen: float fvelocity; vect vDirection; Zeichenfolge ** ppszWord;

durch die automatische Vervollständigung werden sie alle sortiert, und Sie haben Probleme, das zu finden, was Sie möchten, und die Leute verwenden in der Regel das, was sie für besser halten, und es ist keine Notation mehr.

Ich schreibe einfach gerne ThingsLikeThat, wenn ich die Variable sehr genau beschreiben muss, weil sie Platz spart und die Tatsache, dass es Großbuchstaben gibt, sie lesbarer macht.

Was ich normalerweise mache, ist, meine Methoden und Klassen zu benennen, wobei der erste Buchstabe Großbuchstaben und Kleinbuchstaben für Variablennamen und ein Unterstrich für Variablennamen sind (ich finde diesen letzten nützlich).

Im Ernst, ich bevorzuge es, wenn sich die Leute um diese Regeln kümmern: Verwenden Sie Kommas, Arithmetik und geschweifte Klammern mit relevanten Leerzeichen:

void f(int a, char b);
int a = b + 4 / (3 + 4);

Nicht mehr als 80 Zeichen pro Zeile oder AT Die meisten 90 Zeichen, verwenden Sie mehrzeilige Argumente für Funktionen oder lange if:

if
(
    checkthat(a, b) == checkthis(b, d) &&
    checkthat(d, b) == checkthis(v, d)
)
2
jokoon

Stimmen Sie mit den meisten überein, es ist ein alter Stil.

Bei modernen IDEs zeigt Ihnen ein schneller Mauszeiger über eine Variable den Typ.

1
ozz