Warum wird in einigen Programmiersprachen immer noch zwischen Groß- und Kleinschreibung unterschieden?

Ich sehe keine Verwendung für die Groß- und Kleinschreibung in einer Programmiersprache, abgesehen von der Verschleierung von Code.

Warum dies in einer Programmiersprache implementieren?

Aktualisieren:

Es sieht so aus, als hätte jemand, den Sie kennen, eine Erklärung dazu abgegeben .

Während das Falten von Groß- und Kleinschreibung in Englisch ziemlich trivial ist, ist es in einigen anderen Sprachen viel weniger. Wenn ein deutscher Programmierer ßin einem Variablennamen verwendet, was werden Sie als Äquivalent in Großbuchstaben betrachten? Nur zu Ihrer Information, "ß" wird immer nur in Kleinbuchstaben verwendet. OTOH, "ss" ist gleichwertig. Würden Sie einen Compiler für verpflichtet halten, diese zuzuordnen ? Wenn Sie in Unicode einsteigen, treten noch interessantere Probleme auf, z. B. Zeichen mit vorgefertigten diakritischen Zeichen im Vergleich zu separaten kombinierten diakritischen Zeichen. Dann kommen Sie zu einigen arabischen Schriften mit drei verschiedenen Formen von vielen Buchstaben anstatt nur zwei.

In der dunklen Zeit waren die meisten Programmiersprachen fast zwangsläufig unabhängig von Groß- und Kleinschreibung. Zum Beispiel begann Pascal mit Control Data-Großrechnern, die nur sechs Bits pro Zeichen verwendeten (insgesamt 64 Codes). Die meisten dieser Maschinen verwendeten den Zeichensatz "CDC Scientific", der nur Großbuchstaben enthielt. Sie konnten zu anderen Zeichensätzen wechseln, aber die meisten hatten entweder Groß- oder Kleinbuchstaben, aber nicht beide - verwendeten jedoch für beide dieselben Codes. Dasselbe galt für die alten Baudot-Codes, die in den Anfängen von COBOL, FORTRAN, BASIC usw. als Standard galten. Als leistungsfähigere Hardware weit verbreitet war, war ihre Unterscheidung zwischen Groß- und Kleinschreibung so tief verwurzelt, dass es unmöglich war, sie zu ändern .

Im Laufe der Zeit wurde die wahre Schwierigkeit der Unterscheidung zwischen Groß- und Kleinschreibung immer offensichtlicher, und die Sprachentwickler haben größtenteils entschieden ("erkannt" wäre wahrscheinlich ein genauerer Begriff), dass, wenn die Leute wirklich Unterscheidung zwischen Groß- und Kleinschreibung wollen, dies besser mit Hilfswerkzeugen gehandhabt wird als in der Sprache selbst.

Zumindest IMO, sollte der Compiler die Eingabe genau so nehmen, wie sie dargestellt wurde, und nicht entscheiden, dass "Sie dies geschrieben haben, aber ich gehe davon aus, dass Sie wirklich etwas anderes gemeint haben." Wenn Sie möchten, dass Übersetzungen durchgeführt werden, sollten Sie diese lieber separat ausführen. Die Tools sind dafür ausgelegt.

Warum sollte jemand Fallunempfindlichkeit WOLLEN? In welchem ​​Szenario ist es sinnvoll, auf eine einzelne Variable wie VARIABLEan einer Stelle, Variablean einer anderen und variablean einer dritten zu verweisen ? Die Unempfindlichkeit gegenüber Groß- und Kleinschreibung ist ärgerlich. Ich würde viel lieber einen Compilerfehler bekommen, wenn ich versehentlich tippe, VAriableanstatt Variablesolche Fall-Tippfehler in meinen Code einfließen zu lassen.

Zusammenfassend lässt sich sagen, dass in vielen Programmiersprachen die Groß- und Kleinschreibung nicht nur aus historischen / trägen Gründen, sondern auch, weil die Unempfindlichkeit gegenüber Groß- und Kleinschreibung eine schlechte Idee ist.

In Java wird die Groß- und Kleinschreibung NICHT verwendet, um mehr Optionen im Code bereitzustellen, sondern um eine sehr klare und konsistente semantische Bedeutung zu erhalten. KlassenLookLikeThis. objectsLookLikeThis. methodsLookLikeThis (). STATIC_VARIABLES_LOOK_LIKE_THIS. Classes.WithInnerClassesLookLikeThis. Es bietet KEINE größere Freiheit: Sie können einige Informationen in einer ansonsten übermäßig ausführlichen Sprache zusammenfassen.

Ich denke, dass in explizit statisch getippten Sprachen mit Unterstützung für mucho Compiler und IDE die Groß- und Kleinschreibung eine gute Möglichkeit ist, Informationen zu kommunizieren (z. B. Java). Bei Sprachen wie Ruby würde die Unterscheidung zwischen Groß- und Kleinschreibung wahrscheinlich noch mehr unerwartete Ergebnisse hervorrufen, obwohl ich offen für die Unterscheidung zwischen Groß- und Kleinschreibung sein würde.

Ich denke, dass die Unterscheidung zwischen Groß- und Kleinschreibung mit einem strengen System den Code nicht verschleiert, sondern ihn tatsächlich klarer macht. Betrachten Sie möglichen Java-Code:

      joe blah = new hUf();

das ist ziemlich klar, aber was ist mit:

      hUf.WTF();

In Java, wie es ist, würden Sie automatisch wissen, was dies ist. In Java, bei dem die Groß- und Kleinschreibung nicht beachtet wird, ist dies nicht eindeutig. Daher müssen Sie auf einen anderen Mechanismus zurückgreifen, um Klassen von Instanzen von Paketen von Methoden zu unterscheiden. Und DIESER Mechanismus würde dich wahrscheinlich dazu bringen, dich damit zu übergeben, wie hässlich es ist :)

Ich denke nicht, dass es "implementiert" wurde, sondern "erlaubt". Die Groß- und Kleinschreibung ist der Standardstatus für Zeichenfolgenvergleiche. Der Compiler-Ingenieur muss die Groß- und Kleinschreibung einer Sprache nicht berücksichtigen, da Sie zusätzlichen Code hinzufügen müssen, um Vergleiche ohne Berücksichtigung der Groß- und Kleinschreibung durchzuführen und die ursprünglichen Tokennamen für eine korrekte Fehler- und Warnmeldung beizubehalten.

Das ist mit ziemlicher Sicherheit der Grund, warum es in C landete. Sie wollten eine einfache Sprache entwickeln, für die sich ein Compiler auf Kosten der Benutzerfreundlichkeit leicht implementieren lässt. Warum ist es in modernen Sprachen? Weil es natürlich in C ist, muss es der richtige Weg sein, es zu tun! </ sarcasm mode>

Es vereinfacht nicht zuletzt das Parsen und ermöglicht Ihnen mehr Kombinationen für Variablen- / Klassennamen.

Bei der Syntaxanalyse ohne Berücksichtigung der Groß- und Kleinschreibung müssen Sie nur eindeutige Bezeichner verwenden, da "myClass" und "MyClass" dasselbe sind. Alternativ müssten Sie Ihrem Parser Komplexitätsebenen hinzufügen, um sicherzustellen, dass Sie anhand des Kontexts bestimmen können, welcher Bezeichner verwendet wird.

Betrachten Sie einen Fall wie diesen:

XmlWriter xmlWriter = new XmlWriter();
xmlWriter.Write("blah");

Angenommen, die XmlWriter-Klasse verfügt auch über eine statische Methode namens "Write". Rufen Sie es auf der Instanz oder in der Klasse auf, wenn hier keine Groß- / Kleinschreibung angewendet wird?

Ich mag Groß- und Kleinschreibung, wenn der Code dadurch selbstdokumentierender wird:

this is a CONSTANT
this is a ClassName
this is a methodName
this is a local variablename

Normalerweise programmiere ich in Python, aber in meinen C # -Tagen fand ich es sehr praktisch, Klasseninstanzen genauso zu benennen wie die Klasse, aber in Kleinbuchstaben (oder in Kamelbuchstaben) (wie andere gesagt haben):

Thing thing = new Thing();

Die Verwendung von Sprachen, bei denen die Groß- und Kleinschreibung nicht beachtet wird, erfordert eine andere Konvention, dh eine Art Siegel wie:

Thing oThing = new Thing()
Thing instanceOfThing = new Thing()

Welches ist eine "schlechte Sache".

Ich finde es auch bequem, nach Groß- und Kleinschreibung zu suchen, um einen Verweis auf eine Klasse im Vergleich zu Verwendungen einer Variablen zu finden. Bei einer Sprache, bei der die Groß- und Kleinschreibung nicht berücksichtigt wird, ist dies weniger einfach. Gleiches gilt für Suchen & Ersetzen.

Wenn ich als Programmierer Wörter mit unterschiedlichen Groß- und Kleinschreibung sehe, fällt mir auf, dass es sich um unterschiedliche Dinge handelt. Ich habe selten Fehler, bei denen Groß- und Kleinschreibung falsch war, selbst in dynamischen Skriptsprachen, bei denen ein Compiler geholfen hätte.

Die Menschen achten auf die Form der Wörter, bevor sie sie tatsächlich lesen. Bei der Berücksichtigung der Groß- und Kleinschreibung bleibt die Form eines Symbols im gesamten Code gleich. Ich stimme auch den obigen Aussagen zu, dass unterschiedliche Konventionen unterschiedliche Arten von Symbolen bezeichnen. Groß- und Kleinschreibung und Unempfindlichkeit können missbraucht werden. Schlechte Programmierer werden immer schlechten Code generieren ... sie werden einen Weg finden.

Nehmen Sie die Sprache als Beispiel. Warum fangen wir Sätze und benannte Dinge mit Großbuchstaben an ... Liegt es auch an Unix?

Ich denke, für statisch typisierte Sprachen wie C # und Java bringt es eigentlich keinen Mehrwert. Da in den meisten Fällen eine IDE vorhanden ist, bei der die Inkongruenzen zwischen Groß- und Kleinschreibung automatisch korrigiert werden. Wenn ich also versehentlich "VAriable" eingebe, korrigiert meine IDE dies automatisch auf " Variable "für mich. Fügen Sie die MyClass myClass;Stilkonventionen hinzu und Sie können sehen, dass die Berücksichtigung der Groß- und Kleinschreibung nicht unbedingt eine schlechte Sache ist.

Bei dynamisch getippten Sprachen gibt es möglicherweise mehr Argumente, da es für eine IDE schwieriger ist, eine Autokorrektur zu erraten, aber bei dynamisch getippten Sprachen gibt es bereits viel mehr zu befürchten (in Bezug auf Tippfehler), dass die Verwendung einer konsistenten Gehäusekonvention nicht zu einer größeren Belastung führt.

Also ja, obwohl es keinen wirklichen Grund gibt, warum Sprachen nicht zwischen Groß- und Kleinschreibung unterscheiden können, gibt es auch keinen wirklichen Grund, warum sie es auch sein sollten .

In diesem Artikel von Scott Hanselman über "SignOn" vs "Signon" ging es um Zeichenfolgenvergleiche und nichts mit Programmiersprachen zu tun. Ich bin damit einverstanden, dass Zeichenfolgen, die Benutzer eingeben, immer ohne Rücksicht auf Groß- und Kleinschreibung verglichen werden sollten, aber ich denke, das ist ein anderes Spiel als Bezeichner in einer Programmiersprache.

Wenn in einer Sprache zwischen Groß- und Kleinschreibung unterschieden wird, nutze ich sie, um die herkömmliche Verwendung von Groß- und Kleinschreibung in Mathematik und Naturwissenschaften zu reproduzieren. Hier ist eine (keineswegs vollständige) Liste einiger Fallkonventionen:

• In der Wahrscheinlichkeitstheorie frepräsentiert Kleinbuchstaben normalerweise eine Wahrscheinlichkeitsdichtefunktion (pdf), während Großbuchstaben Fdie entsprechende kumulative Verteilungsfunktion (cdf) darstellen.
• Auch in der Wahrscheinlichkeitstheorie bezeichnen Großbuchstaben Zufallsvariablen Xund die entsprechenden Kleinbuchstaben ihre Realisierungen x, wie in $ Pr [X = x] \ leq 0.05 $.
• In der linearen Algebra werden Großbuchstaben im Allgemeinen verwendet, um auf Matrizen zu verweisen, während Kleinbuchstaben im Allgemeinen verwendet werden, um auf Zahlen zu verweisen, z. B. $ A = [a_ {ij}] $.
• Einheitensymbole werden in Kleinbuchstaben geschrieben (z. B. m für Meter), mit Ausnahme von Liter (L) und solchen Einheiten, die vom Namen einer Person abgeleitet sind (W für Watt, Pa für Pascal, N für Newton usw.).
• Symbole von Präfixen, die eine Million oder mehr bedeuten, werden mit einem Groß- oder Kleinbuchstaben (M für Mega (Millionen)) und weniger als eine Million (m für Milli (Tausendstel)) gekennzeichnet.

Ich dachte nur, es liege an Unix und C - aber das ist eine Art Henne-Ei-Problem, das nur die Geezer richtig beantworten können.

Ich benutze die Begründung, die die Hühner in "Der Osterhase kommt in die Stadt" verwendet haben, als sie gefragt wurden, ob sie vor Eggs kamen. Weil es Hühner auf Noahs Arche gab, standen die Hühner an erster Stelle. Da GCC unter Unix ausgeführt wird, stand Unix an erster Stelle. Daher kümmert sich Unix so sehr um Groß- und Kleinschreibung, C und alle seine Varianten und Nachkommen sowie alles, was geschweifte Klammern auferlegt, um Groß- und Kleinschreibung.

Wahrscheinlich besteht auch ein Zusammenhang zwischen geschweiften Klammern und Groß- und Kleinschreibung.

Neben den bisher ausgezeichneten Antworten möchte ich darauf hinweisen, dass die Groß- und Kleinschreibung Ihnen auch zusätzliche "Namespaces" bietet. Zum Beispiel Perl einige speziellen Blöcke wie hat BEGINund ENDdass Lauf zu unterschiedlichen Zeiten als normaler Code (BEGIN zum Zeitpunkt der Kompilierung, END nach dem normalen Programm beendet hat), und jene , die als Großbuchstaben, die macht sie abheben, und bedeutet , dass das untere Gehäuse Varianten sind keine reservierten Wörter.

Man kann sogar noch weiter gehen und Namen in Großbuchstaben für die zukünftige Verwendung durch die Sprache reservieren und normalen Programmierern, die normalerweise NICHT IN IHREM CODE SCHREIEN, keinen Schaden zufügen.

"Groß- und Kleinschreibung beachten" ist für technische Personen immer besser, um Mehrdeutigkeiten zu verringern. Nehmen Sie den Dateinamen als Beispiel. Der Umgang mit Windows-Dateinamen ist problematischer als der mit Unix-Dateinamen, da bei Dateinamen unter Windows die Groß- und Kleinschreibung nicht berücksichtigt wird, während bei Dateinamen unter Unix die Groß- und Kleinschreibung beachtet wird.

Zurück zur Programmierung. Bei Klassennamen, Methodennamen und Variablennamen erzwingen die meisten Sprachen die Benennungsstilregel nicht. Manchmal können wir der Einfachheit halber einfach den Namen "case sensitive" verwenden, um ohne Konvertierung eine Bindung an eine andere Datenquelle herzustellen oder das Problem mit demselben Namen, jedoch in einer anderen Schreibweise, zu behandeln.

Ich bin überrascht von diesem Schimpfen. Jetzt, da niemand möchte, dass Sie m_in C # einen Unterstrich oder einen in einem Feldnamen verwenden, habe ich gerade die Groß- / Kleinschreibung verwendet. Wenn der Feldname mit dem Namen einer öffentlichen Eigenschaft identisch ist, ist der Name der öffentlichen Eigenschaft Pascal-Groß- / Kleinschreibung und das Hintergrundfeld ist Kamel, denke ich, "so sei es" - das scheint die Programmiergemeinschaft im Allgemeinen zu wollen. Es hat bisher keine Probleme verursacht.

Insbesondere einige Programmierer stammen aus den Anfängen von BASIC, wo ein Variablenname nur 2 Zeichen lang sein kann.

Und wenn es eine beliebige Anzahl von Zeichen sein kann, werden sie sehr glücklich. Und neben der Berücksichtigung der Groß- und Kleinschreibung - weil sie sich auch nicht darum kümmern möchten SomeName, versehentlich gleichgestellt zu werden SOMENAMEund aufgrund solcher Dinge einen Fehler zu verursachen.