it-swarm-eu.dev

Proč v některých programovacích jazycích stále existuje velká a malá písmena?

Nevidím žádné použití pro citlivost na malá a velká písmena v programovacím jazyce, kromě zmateného kódu.

Proč to implementovat v programovacím jazyce?

Aktualizace:

Vypadá to, že někdo, koho znáte, k tomu vydal prohlášení .

44
DavRob60

Zatímco skládání případu je v angličtině docela triviální, v některých jiných jazycích je to mnohem méně. Pokud německý programátor používá ß v názvu proměnné, co budete považovat za ekvivalent velkých písmen? Jen FYI, "ß" se používá se vždy používá v malých písmenech. OTOH, "ss" je ekvivalent - považovali byste kompilátor za nutný, aby se s nimi vyrovnal? Když se dostanete do Unicode, získáte ještě zajímavější problémy, jako jsou postavy s předem složenými diakritickými znaménky versus samostatné kombinující diacriticals. Pak se dostanete k některým arabským skriptům, se třemi samostatnými formami mnoha písmen, místo pouhými dvěma.

V temném věku byla většina programovacích jazyků téměř necitlivá na malá a velká písmena. Například Pascal začal s mainframy Control Data, které používaly pouze šest bitů na znak (64 kódů, celkem). Většina takových strojů používala znakovou sadu „CDC Scientific“, která obsahovala pouze velká písmena. Dalo by se přejít na jiné znakové sady, ale většina měla buď velká nebo malá písmena, ale ne obě - ​​ale pro oba byly použity stejné kódy. Totéž platilo o starodávných kódech Baudot a takto považovaném standardu v počátečních dnech COBOLU, FORTRANU, ZÁKLADNÍHO atd. V době, kdy byl dostupnější hardwarový hardware, byl jejich citlivost na velikost písmen tak důkladně zakořeněná, že změna byla nemožná .

V průběhu času se skutečná obtížnost necitlivosti na velikost písmen stala zjevnější a návrháři jazyků se většinou rozhodli („realizováno“ by pravděpodobně byl přesnější termín), že když/pokud lidé skutečně chtějí necitlivost na případy, je lepší se s nimi poradit pomocí pomocných nástrojů než v samotném jazyce.

Alespoň IMO, kompilátor by měl vzít vstup přesně tak, jak je uveden, a ne rozhodnout, že „jste to napsali, ale předpokládám, že jste opravdu myslel něco jiného.“ Pokud chcete, aby se překlady uskutečňovaly, je lepší dělat je samostatně, s nástroji vytvořenými tak, aby dobře zvládly.

114
Jerry Coffin

Proč by někdo chtěl necitlivost na případy? V jakém scénáři je užitečné odkazovat na jednu proměnnou jako VARIABLE na jednom místě, Variable na jiném a variable na třetím? Necitlivost na případy je podrážděná. Mnohem raději dostanu chybu kompilátoru, když náhodou zadám VAriable místo Variable, než nechám, aby se takové typy překlepů dostaly do mého kódu.

Závěrem lze říci, že mnoho programovacích jazyků rozlišuje velká a malá písmena nejen z historických/inerciálních důvodů, ale proto, že necitlivost na případy je špatný nápad.

116
nohat

V Java případová citlivost Java se NEPOUŽÍVÁ k poskytnutí více možností v kódu, ale spíše pro velmi jasný a konzistentní sémantický význam. ClassesLookLikeThis. ObjectsLookLikeThis. MethodsLookLikeThis (). STATIC_VARIABLES_LOOK_LIKE_THIS. NEPOSKYTUJTE větší svobodu: možňuje vám stručně zabalit některé informace do toho, co je jinak příliš příliš podrobný jazyk.

Myslím si, že ve výslovně staticky psaných jazycích s kompilátorem mucho a IDE) je citlivost na velká písmena skvělý způsob, jak sdělovat informace (např. Java). U jazyků, jako je Ruby, by se velká a malá písmena pravděpodobně způsobit ještě VÍCE neočekávaných výsledků, i když bych byl otevřený pokusu o Ruby, který necituje na malá a velká písmena.

Domnívám se, že citlivost malých a velkých písmen s přísným systémem nezavádí kód, ale ve skutečnosti je jasnější. Zvažte možný Java:

      joe blah = new hUf();

to je docela jasné, ale co:

      hUf.WTF();

V Java tak, jak je), byste automaticky věděli, o co jde. V případě Java, která není citlivá na případy, je to dvojznačné, takže byste se museli uchýlit k jinému mechanismu odlišit třídy od instancí od balíčků od metod. A mechanismus THAT by vás pravděpodobně zvracel s tím, jak je to ošklivé :)

27
Dan Rosenstark

Nemyslím si, že to bylo „implementováno“ tolik jako „dovoleno“. Rozlišování velkých a malých písmen je výchozí stav porovnávání řetězců; to vyžaduje více práce pro kompilátora, aby se jazykové případy necitlivé, protože je třeba přidat další kód pro provedení bez rozlišování malých a velkých písmen a zachovat původní názvy tokenů pro správné hlášení chyb a varování.

To je téměř jistě důvod, proč to skončilo v C; Chtěli vytvořit jednoduchý jazyk, pro který by bylo snadné implementovat kompilátor, na úkor použitelnosti. Co se týká toho, proč je to v moderních langaugech? Protože je to samozřejmě v C, takže musí být tím správným způsobem! </ sarkasmusový režim>

24
Mason Wheeler

Pokud nic jiného, ​​zjednodušuje analýzu a umožňuje více kombinací pro názvy proměnných/tříd.

Při analýze bez rozlišování velkých a malých písmen byste se omezili na použití jedinečných identifikátorů, protože „myClass“ a „MyClass“ by byly stejné. Případně byste měli do svého analyzátoru přidat vrstvy složitosti, abyste se ujistili, že můžete určit, který identifikátor se použije na základě kontextu.

Zvažte případ jako je tento:

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

Předpokládejme, že třída XmlWriter má také statickou metodu nazvanou "Write". Voláte to na instanci nebo na třídu, pokud zde není aplikována citlivost na malá a velká písmena?

23
Adam Lear

Mám ráda malá a velká písmena, pokud z jiného důvodu, než to dělá kód více self-dokumentující:

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

Typicky jsem programoval v Pythonu, ale za mých C # dnů jsem zjistil, že je velmi vhodné pojmenovat instance třídy stejně jako třída, ale nižší (nebo velbloudový) případ (jak již uvedli ostatní):

Thing thing = new Thing();

Používání jazyků bez rozlišování velkých a malých písmen vyžaduje za tímto účelem nějakou konvenci, tj. Nějaký druh sigilů, jako například:

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

Což je „špatná věc“.

Rovněž mi připadá vhodné grep (citlivě) hledat odkaz na třídu vs. použití proměnné. S jazykem nerozlišujícím velká a malá písmena by to bylo méně snadné. Stejné pro vyhledávání a nahrazování.

A konečně, jako programátor, když vidím slova s ​​různými případy, vyskočí mi, že jsou to různé věci ... Zřídka mám chyby, kde byly proměnné případy špatné, dokonce i v dynamických skriptovaných jazycích, kde by kompilátor pomohl.

13
Hollister

Lidé věnují pozornost tvaru slov, než je skutečně čtou. Rozlišování malých a velkých písmen udržuje tvar symbolu konzistentní v celém kódu. Souhlasím také s těmi výše uvedenými, že různé úmluvy označují různé typy symbolů. Citlivost na malá a velká písmena mohou být zneužita. Špatní programátoři vždy vygenerují špatný kód ... najdou cestu.

Jako příklad si vezměte jazyk. Proč začínáme věty a pojmenováváme velkými písmeny ... Je to také kvůli unixu?

10
Tjaart

Myslím, že u staticky typovaných jazyků jako C # a Java to vlastně nepřináší žádnou hodnotu. Protože ve většině případů máte IDE), které za vás stejně automaticky opraví nesoulad případů, takže na konci dne, pokud náhodou zadám „VAriable“, my IDE to automaticky opraví na "Proměnná" pro mě. Přidejte k tomu MyClass myClass; styl konvencí a můžete vidět, že citlivost na velikost písmen nemusí být nutně špatná věc.

U dynamicky typovaných jazyků může existovat více argumentů, protože pro IDE) je těžší uhodnout autokorekci, ale v případě dynamicky typovaných jazyků už jste tak dostali mnohem víc si dělat starosti (pokud jde o překlepy), že použití konsistentní konvence o plánech nepřinese další mnohem větší zátěž.

Takže ano, i když neexistuje žádný skutečný důvod, proč by jazyky ne nemohly být citlivé na velká a malá písmena, neexistuje žádný skutečný důvod, proč by také měly být.

Tento článek od Scotta Hanselmana o "SignOn" vs. "Signon" byl o porovnání řetězců a nic společného s programovacími jazyky. Souhlasím s tím, že řetězce, které živatelé zadávají, by se vždy měli porovnávat s malými a velkými písmeny, ale myslím si, že se jedná o odlišnou kouli od identifikátorů v programovacím jazyce.

9
Dean Harding

Když jazyk rozlišuje velká a malá písmena, využívám jej k reprodukci konvenčního použití případů v matematice a přírodních vědách. Zde je seznam (v žádném případě vyčerpávající) některých konvencí případů:

  • V teorii pravděpodobnosti malá písmena f obvykle představuje funkci hustoty pravděpodobnosti (pdf), zatímco velká písmena F představuje odpovídající kumulativní distribuční funkci (cdf).
  • Také v teorii pravděpodobnosti velká písmena označují náhodné proměnné X a odpovídající malá písmena označují jejich realizace x, jako v $ Pr [X = x]\leq 0,05 $.
  • V lineární algebře se velká písmena obvykle používají k označení matic, zatímco malá písmena se obvykle používají k označení čísel, např. $ A = [a_ {ij}] $.
  • Symboly jednotek jsou psány malými písmeny (např. M na metr) s výjimkou litru (L) a jednotky odvozené od jména osoby (W pro Watt, Pa pro Pascal, N pro Newton atd.).
  • Symboly předpon, které znamenají milion nebo více, se kapitalizují (M pro mega (miliony)), a symboly menší než milion jsou malými písmeny (m pro milióny (tisíciny)).
6
A. N. Other

Jen jsem si myslel, že to bylo kvůli Unixu a C - ale to je druh kuřecího a vaječného problému, na který mohou správně odpovědět pouze geezerové.

Používám odůvodnění, které použili kuřata v „Velikonoční zajíček do města“, když se ptali, zda přišli před Vejce. Protože na Noemově archě byla kuřata, byla první kuřata. Proto, protože GCC běží na Unixu, Unix byl na prvním místě, proto se Unix tolik stará o případ, C a všechny jeho varianty a potomky, ano cokoli, co ukládá složené rovnátka, se stará o případ.

Pravděpodobně existuje souvislost mezi složenými závorkami a rozlišováním velkých a malých písmen.

3
Peter Turner

„Rozlišovat velká a malá písmena“ je pro technické osoby vždy lepší, aby snížily nejednoznačnost. Příkladem je název souboru. Řešení názvu souboru Windows je mnohem obtížnější než název souboru Unix, protože název souboru ve Windows nerozlišuje velká a malá písmena, zatímco název souboru v Unixu rozlišuje velká a malá písmena.

Zpět na programování. Pro název třídy, název metody, název proměnné většina jazyků nevynucuje pravidlo stylu pojmenování. Někdy kvůli jednoduchosti můžeme udělat „reflexi“, abychom mohli jednoduše použít název „Case sensitive“ pro navázání na jiný zdroj dat bez převodu nebo řešení problému se stejným názvem, ale v jiném případě.

2
linquize

Kromě dosud vynikajících odpovědí bych rád poukázal na to, že citlivost malých a velkých písmen vám dává také další „jmenné prostory“. Například Perl má některé speciální bloky jako BEGIN a END, které běží v různých časech než normální kód (BEGIN v době kompilace, END po ukončení normálního programu) a mají tyto bloky jako all- velká písmena je nutí vyniknout a to znamená, že varianty malých písmen nejsou rezervovaná slova.

Člověk může jít ještě dále a vyhradit si všechna velká písmena pro budoucí použití jazykem a nijak neubližovat běžným programátorům, kteří obvykle NEVEŘÍŽÍJÍ JEJICH KÓD.

2
moritz

Jsem tímto překvapením překvapen. Nyní, když nikdo nechce, abyste použili podtržítko nebo m_ v názvu pole v C #, právě jsem používal případ velblouda, a pokud je název pole stejný jako název veřejného vlastnictví, jen to, že název veřejného vlastnictví je případ Pascal a podpůrné pole je případ velblouda, postava, "tak ať to je" - to se zdá, že programová komunita obecně chce. Dosud to nezpůsobilo žádné problémy.

1
Scott Whitlock

Zejména někteří programátoři pocházejí z raných dnů BASICu, kde název proměnné může mít pouze 2 znaky.

A tak, když to může být libovolný počet postav, stanou se velmi šťastní. A spolu s rozlišováním velkých a malých písmen - protože se nechtějí starat také o to, aby se SomeName náhodně rovnal SOMENAME a způsobil chybu kvůli takovým věcem.

0
Michael W