Stellen Sie Variablennamen eine Abkürzung der Variablentypen voran? (Ungarische Notation) [geschlossen]

37

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

Ein neuer Typ schlug jedoch vor kurzem vor, immer die ungarische Notation zu verwenden. Bisher verwendeten einige von uns eine Art ungarische Notation, andere nicht. Wissen Sie, es ist ein Ingenieurbüro, also spielen Codierungsstile keine Rolle, solange die Algorithmen solide sind.

Persönlich bin ich der Meinung, dass diese kleinen Abkürzungen überflüssig sind. Ein gut durchdachter Name liefert normalerweise die gleiche Nachricht. (Außerdem muss der Großteil unseres Codes auf einigen verrückten DSPs laufen, auf denen ein Konzept sowieso existiert booloder floatnicht existiert).

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

Bastibe
quelle
Siehe auch: programmers.stackexchange.com/questions/14789/…
Kramii Reinstate Monica
7
Welche Programmiersprache verwenden Sie?
Larry Coleman
3
Eigentlich ist es nicht in Ordnung - Sie sollten einen Kodierungsstandard haben (formal oder anderweitig), meiner Meinung nach ist es niemals in Ordnung ... aber andere mögen anderer Meinung sein .
Murph
@ Larry: Wir benutzen meistens C und C ++, mit ein bisschen Assembler und Lua hier und da.
Bastibe
11
@Paperflyer, Kodierungsstandards / -regeln sind nicht für die Kunden, sondern für das Entwicklungsteam. Ich bin der festen Überzeugung, dass Sie Codierungsstandards festlegen und befolgen sollten, es sei denn, Sie glauben, dass dieselben Entwickler für immer (unrealistisch) im Team sein werden. Es führt zu wartungsfreundlicheren Systemen, bringt neue Mitarbeiter schneller auf den neuesten Stand und sorgt für mehr Konsistenz. Abgesehen davon stimme ich zu, dass sich die ungarische Notation als überflüssig erwiesen hat und eher ein Relikt der Vergangenheit ist. Gut durchdachte Namen sind wichtiger, insbesondere bei den heute viel leistungsfähigeren IDEs.
Mark Freedman

Antworten:

77

Wenn die meisten Leute "Ungarische Notation" sagen, sprechen sie eigentlich von " Ungarischen Systemen ".

Ungarische Systeme sind völlig nutzlos und sollten vermieden werden. Es ist nicht erforderlich, den Typ der Variablen im Namen zu verschlüsseln . Systems Hungarian ist jedoch ein Missverständnis des ursprünglichen , "echten" Ungarischen: Apps Hungarian.

In Apps Hungarian codieren Sie nicht den "Typ" im Variablennamen, sondern den "Typ" der Variablen. Also nicht nWidth, sondern pxWidthoder emWidth(für "width in pixels" bzw. "width in ems"). Nicht strNameaber sNameoder 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 Wertes umwandelt (zum Beispiel habe ich in der Vergangenheit das Präfix "px" und "em" verwendet, weil es Fehler wie pxArea = emWidth * emHeightoffensichtlich macht).

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

Dean Harding
quelle
2
Lesen Sie Simonyis Artikel zu diesem Thema: Er ist der ursprüngliche Promulgator des Ungarischen, und seine Version ist diejenige, die nützlich ist. msdn.microsoft.com/en-us/library/aa260976(v=vs.60).aspx
Michael Kohne
1
Es sollte eine Möglichkeit geben, Einheiten in einen benutzerdefinierten Typ aufzunehmen, wenn Sie ihn wirklich benötigen (dasselbe gilt für sichere / unsichere Zeichenfolgen). Ich sehe jedoch, dass Sie dabei auf Leistungsprobleme stoßen könnten (Sie möchten beispielsweise keinen Float in eine Klasse einschließen). In F # wird die Maßeinheit eingeführt, die im Grunde genommen zu diesem Zweck zusätzliche Typinformationen zu Doubles hinzufügt.
Scott Whitlock
1
In Code, der sich mit Benutzereingaben befasst, finde ich es nützlich, Benutzerdaten das Präfix rawierawUsername
zzzzBov vom
1
@Scott eine andere Option wäre ein stark typisiertes typedef
jk.
1
@JBR: Hast du die Antwort tatsächlich gelesen? In „Apps Ungar“, das sist nicht für stringoder etwas, aber für „sicher“ (oder ich habe auch „sichere Zeichenfolge“ zu hören).
31

pronounYou verbShould adverbNever verbUse adjectiveHungarian nounNotation, prepositionIt verbMakes collectivenounEvery AdverbSo comparativeBloody AdjectiveHard infinitiveTo verbRead.

grinsender Mann
quelle
6
Ich musste lächeln ... pedantry, aber "to" ist eine Präposition, kein Infinitiv. "lesen" ist ein Infinitiv.
DrAl
@dral natürlich war es im humorvollen register, nicht der grammatikfreak: D
smirkingman
1
Das war großartig, hat mich zum Lachen gebracht. :)
Corv1nus
26

Zuerst:

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

Codierungsstile spielen unabhängig vom Unternehmen eine Rolle. Ja, die Algorithmen müssen solide sein, aber der Code muss von jedem verwaltet werden können, nicht nur vom ursprünglichen Entwickler. Ein Codierungsstandard, der Stilelemente enthält, trägt dazu bei. 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:

Bei einer modernen IDE, die IntelliSense-Typverhalten unterstützt, ist es nicht erforderlich, den Variablentyp in den Namen aufzunehmen. Diese Informationen stehen Ihnen auf andere Weise zur Verfügung. Im schlimmsten Fall kann das Lesen des Codes erschwert werden, wenn Sie den Variablentyp in Zukunft ändern müssen.

ChrisF
quelle
21

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

codeape
quelle
8
Es ist schlimmer als "überflüssig". In einigen komplexen Situationen ist es schwierig, das Richtige zu finden. Insbesondere benötigt jede in Ihrer App definierte Klasse eine Abkürzung. Nachdem Sie etwa 20 Klassen definiert haben, haben Sie keine Ein-Buchstaben-Abkürzungen mehr. Was jetzt? Eine Mischung aus einem Buchstaben und zwei Buchstaben? Was ist mit komplexen Verweisen auf ein Element einer Datenstruktur? Zeiger auf Array von Zuordnungen von Listen zu Zuordnungen von Ganzzahlen zu Zeichenfolgen? Wie wäre eine Abkürzung dafür hilfreich?
S.Lott
13

Ein Großteil der Debatte über die (System-) ungarische Notation hängt vom Arbeitsbereich ab. Früher war ich sehr 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, kann ich einige Vorteile davon in bestimmten Anwendungen erkennen und es ist definitiv auf mich gewachsen .

Systems Ungarisch

Soweit ich weiß, wird Systems Hungarian häufig im Embedded-Bereich eingesetzt. In PC-Anwendungen wird sich der Compiler mit vielen Problemen befassen, die mit den Unterschieden zwischen (z. B.) Zeichenfolgen, Ganzzahlen und Gleitkommawerten zusammenhängen. 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 Lint mit erzwungenen MISRA-Regeln) nimmt diese nicht immer zur Kenntnis. In diesem Fall mit variablen Namen wie u8ReadIndex, s16ADCValuekann hilfreich sein.

Apps Ungarisch

Apps Hungarian bietet eindeutige Vorteile in Bezug auf PC- / Webanwendungen, z. B. einen visuellen Unterschied zwischen "unsicheren" und "sicheren" Zeichenfolgen (dh von einem Benutzer eingegebene Zeichenfolgen und solche, die aus internen Ressourcen oder anderen Quellen entkommen oder gelesen wurden) ). Dem Compiler ist diese Unterscheidung nicht bekannt.

Was ist der Punkt?

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

Wenn Sie eine unsichere Zeichenfolge direkt in eine sichere Zeichenfolge kopieren, ohne dass ein Escapezeichen auftritt, sieht dies bei Verwendung von Apps Hungarian falsch aus.

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

In beiden Fällen führt die ungarische Schreibweise (Apps / Systems) dazu, dass formale Codeüberprüfungen schneller durchgeführt werden, da weniger auf den Variablentyp zurückgegriffen wird.

Insgesamt

Insgesamt ist meiner Meinung nach das Wichtigste, dass Sie einen Kodierungsstandard haben. Ob das System Ungarisch, Apps Ungarisch oder keines davon verwendet, hängt von der persönlichen oder Gruppenpräferenz ab, ähnlich wie die Auswahl der Einrückungstypen usw. Das gesamte Entwicklungsteam, das mit derselben Präferenz arbeitet, hat jedoch bestimmte Vorteile.

DrAl
quelle
Sie sollten klarstellen, über welche Sprachen Sie sprechen. Da Sie mit Embedded-Entwicklung arbeiten, gehe ich davon aus, dass Sie C verwenden? Ungarisch ist in C sinnvoll, aber nicht in moderneren Sprachen.
JacquesB
9

Der Zweck der ungarischen Notation besteht darin, Informationen in die Kennung zu kodieren, die sonst im Typensystem nicht kodiert werden können. Meiner Meinung nach ist es wichtig genug, diese Informationen im Typensystem zu codieren, 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 vollstopfen?

Oder, um es kurz zu machen: Typinformationen gehören in das Typensystem. (Hinweis: Es muss kein statisches Typsystem sein. Solange die Typfehler abgefangen werden, ist es mir egal, wann sie abgefangen werden.)

In einigen anderen Antworten wurden Maßeinheiten als akzeptable Verwendungen der ungarischen Notation genannt. (Ich bin ein bisschen überrascht, dass noch niemand den NASA Mars Climate Orbiter erwähnt hat, da dies die ganze Zeit in Diskussionen über die ungarische Notation 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 hier 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 darauf, dass ein Mensch erkennt, was im Wesentlichen ein Tippfehler ist. Ist das nicht was ein Typ Checker ist?

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. Du solltest es niemals benutzen.

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

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

Darüber hinaus muss der Großteil unseres Codes auf einigen verrückten DSPs laufen, auf denen es sowieso kein Konzept wie bool oder float gibt

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


PS: Ich empfehle von ganzem Herzen, sich Frink anzuschauen. Das Handbuch enthält einige der tollsten Furz-Witze, die es je gab. Es ist auch eine ziemlich coole Sprache :-)

Jörg W. Mittag
quelle
Ich würde das 50 Mal abstimmen, wenn ich könnte.
Larry Coleman
1
Sehr interessantes Argument! Ich könnte das in meinem aktuellen Projekt versuchen. typedef meter float...
Bastibe
6

In einer objektorientierten Sprache ergibt das keinen Sinn - alles ist ein Typ, der offensichtlich wird, wenn versucht wird, ihn zu verwenden.

Billy Bob
quelle
6

Der einzige Ort , wo Systeme ungarischen waranted ist mit einem schwach typisierte Sprache wie C. Es ist doppelt wichtig , mit C , weil es keine explizite Objekt ist (es hat structs, aber alle Funktionen sind außerhalb der Struktur). Bei etwas Stärkerem wie C ++, Java und C # hilft das nicht und macht die Sache sogar noch schlimmer. Codeänderungen, und es ist viel einfacher, einen Typ zu ändern, als alle Stellen, an denen Sie einen Variablennamen verwenden. Es ist auch unnötige Arbeit, die dazu neigt, ignoriert zu werden.

Wenn Sie Maßeinheiten haben, kann es hilfreich sein, diese in einem Namen zu verschlüsseln. Letztendlich kann dies jedoch auch zu zusätzlichen Störungen führen. Zum Beispiel werden wir die Standardmaßeinheit für die verschiedenen Dinge deklarieren, mit denen wir in unserem Code arbeiten. Verwenden wir beispielsweise Gradienten oder Grad, Meter oder Fuß, Frames 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. Die Überbestimmung eines Kodierungsstandards ist kontraproduktiv. Es ist sehr wertvoll, dass Variablen- und Feldnamen genau angeben, was sie darstellen, und die meiste Zeit können Sie den Typ sicher aus dem Konzept ableiten.

Berin Loritsch
quelle
1
Tatsächlich verfügen gute IDEs (oder Plugins) normalerweise über ziemlich leistungsstarke Refactoring-Funktionen, mit denen sich Variablennamen problemlos ändern lassen.
Bastibe
4
Verstanden, aber das zusätzliche Rauschen in der Versionskontrolle für Namensänderungen hilft auch nichts. Sagen wir einfach, der Mehrwert rechtfertigt nicht den Wartungsaufwand.
Berin Loritsch
wird von der sprache abhängen und einige haben direkte unterstützung für stark typisierte uM oder stark typisierte typedefs
jk.
6

MIST NEIN!

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

Was wir tun sollten, ist unsere Variablen gut zu benennen :

  • Vermeiden Sie zu allgemeine Namen. Nennen Sie es nicht, zwenn es sich um eine Klassenvariable handelt, die ein benanntes Objekt darstellt, beispielsweise eine Telefonrechnung. Nennen Sie es phoneBilloder PhoneBill.
  • Vermeiden Sie zu spezifische Namen. Wenn etwas ohne zusätzliche Informationen klar ist, geben Sie es nicht an. Wenn es nur eine String-Indexvariable zum Durchlaufen der Zeichen eines Strings ist und Sie sie nur einmal in der Funktion MyFunc verwenden, warum um alles in der Welt würden Sie sie jemals aufrufen MyFuncTempStringCharacterIndex? Das ist ein trauriger Witz. Nennen Sie es Posoder auch, iwenn 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 soll, 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, gleichartige Elemente gibt, die auf die gleiche Weise verwendet werden, ist es in Ordnung, ein Präfix oder Suffix einzufügen, um diesen Unterschied zu kennzeichnen. Halte es so kurz wie möglich.

Wie andere Befragte bereits sagten, wurde in diesem engen Fall "Apps Hungarian" gestartet, um zwischen Messungen in Bezug auf das Fenster rwTabPositionund in Bezug auf das Dokument zu unterscheiden rdTabPosition. Fügen Sie in einer Anwendung, die alles in Bezug auf das Dokument ausführt, keine zusätzliche Kruft hinzu! Warum nicht die Idee von Jörg W. Mittag nutzen , einen neuen Typ daraus zu machen? Dann kann man unmöglich Dinge durcheinander bringen.

In fast allen Bereichen wird die allgemeine Aussagekraft und das Verständnis durch Hinzufügen von Inhalten mit minimaler Bedeutungsdichte beeinträchtigt. Hier ist ein Beispiel von Ben Franklin . Und noch ein Beispiel: Auf Englisch ist es möglich, unsere Worte mit ihrem Wortartteil zu verzieren. Es sind mehr Informationen, nicht wahr? Für den Fall, dass Anfänger verwirrt wurden, könnte dies für sie wirklich hilfreich sein, oder? Lesen Sie dies und sagen Sie mir, wie nützlich dies für das langfristige Verständnis und die effiziente Vermittlung von Informationen ist:

vrbDo advnot vrbuse nouHungarian nounotation cnjor adjany adjother nounotation. prepAs nouprogrammers, prowe vrbshouldnot verbe nouusing "nounotation" prpfor proour adjvariable nounames.

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

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

Halten Sie Variablennamen so kurz wie möglich, so aussagekräftig wie nötig und immer eindeutig .

ErikE
quelle
Das ist fast genau das, was unsere Standards sind. Der einzige Unterschied ist, dass wir Pascal Case bevorzugen, wenn wir Dinge so benennen, dass die Groß- und Kleinschreibung konsistent ist.
DForck42
5

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. isConnectedist immer lesbarer und verständlicher als boolConnected.

Mudassir
quelle
2
Ich stimme absolut zu! Dies ist, was sie "App Ungarisch" im Gegensatz zu "System Ungarisch" nennen.
Bastibe
@ Bastibe: Nein, das ist, was sie beschreibende Namen nennen. Apps Hungarian basiert auf Abkürzungen.
JacquesB
2

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 Deklaration suchen, indem Sie Folgendes tun:

  1. ctrl-home
  2. Strg-F
  3. Variablennamen
  4. eingeben

Es war also ziemlich wichtig. Aber irgendwo um das Jahr 2000 herum passierten ein paar Dinge:

  • Die Editoren wurden intelligent genug, um den Variablentyp als QuickInfo anzuzeigen
  • Die Redakteure hatten eine Verknüpfung "Gehe zu Deklaration" und eine schnelle Möglichkeit zum Zurückblättern
  • C ++ wurde weniger verwendet und die meisten anderen Sprachen haben weniger Variablentypen. In C # sind Sie sich beispielsweise ziemlich sicher , dass es lastNameeine gibt System.String, da es nur eine Zeichenfolgenklasse gibt.

Ich war einer der letzten, die sich von Ungarisch abwandten, und jetzt, wenn ich alten Quellcode lese, ärgert es mich tatsächlich.

Andomar
quelle
2

Ich hasse nur die ungarische Notation, ich bevorzuge die Verwendung von Unterstrichen, um Variablennamen abzugrenzen.

Außerdem, wenn Sie den Typ als ersten Buchstaben am Anfang Ihres Variablennamens setzen: float fvelocity; vect vDirection; string ** ppszWord;

Die Autovervollständigung sortiert sie alle, und Sie haben Probleme, das zu finden, was Sie wollen, und die Leute tendieren dazu, das zu verwenden, was sie für besser halten, und es ist keine Notation mehr.

Ich schreibe einfach gerne ThingsLikeThat, wenn ich die Variable sehr genau beschreiben möchte, weil sie Platz spart und weil es Großbuchstaben gibt, die die Lesbarkeit verbessern.

Normalerweise benenne ich meine Methoden und Klassen mit Großbuchstaben, Kleinbuchstaben für Variablennamen und einem Unterstrich für Variablennamen (ich finde den letzten nützlich).

Im Ernst, ich bevorzuge Leute, die sich 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 höchstens 90 Zeichen verwenden mehrzeilige Argumente für Funktionen oder long if:

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

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

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

ozz
quelle
2
Ich finde das (dass die IDE hilft) ein schlechtes Argument - wenn Sie codieren, werden Sie diesen Vorteil haben. Es gibt jedoch eine beliebige Anzahl von Fällen (Festschreiben, Überprüfen, Diff / Tadeln usw.), in denen Sie diese Unterstützung möglicherweise nicht zur Verfügung haben.
Murph
Du liegst falsch !!!!! ;) Klar, ich würde trotzdem kein Ungarisch benutzen!
ozz