Dlaczego w niektórych językach programowania nadal rozróżniana jest wielkość liter?

44

Nie widzę żadnego znaczenia dla rozróżniania wielkości liter w języku programowania, oprócz zaciemniania kodu.

Po co wdrażać to w języku programowania?

Aktualizacja:

Wygląda na to, że ktoś, kogo znasz, wypowiedział się w tej sprawie .

DavRob60
źródło
28
Dlaczego w niektórych językach programowania nadal występuje rozróżnianie wielkości liter?
Thomas Eding
1
Nawet w języku angielskim rozróżniana jest wielkość liter. Często cytowanym przykładem są polski i polski, które są dwoma różnymi terminami, których formy pisarskie różnią się tylko przypadkiem i które mają różne wymowy i znaczenia. IMO lepiej, żeby programowanie nie było zbyt sprytne w tym względzie i niech programiści sami opracują odpowiednie konwencje pisemne. Np. Dość często pisze się coś Person person = new Person()w języku OO, gdzie symbol „osoba” jest obiektem tymczasowym, a „osoba” jest typem klasy.
Brandin,

Odpowiedzi:

113

Podczas gdy składanie skrzynek jest dość proste w języku angielskim, w innych językach jest o wiele mniej. Jeśli niemiecki programista używa ßnazwy zmiennej, co zamierzasz uznać za odpowiednik wielkich liter? Po prostu FYI, „ß” jest zawsze używane tylko małymi literami. OTOH, „ss” jest równoważne - czy uważasz, że kompilator jest zobowiązany do ich dopasowania? Kiedy wchodzisz w Unicode, masz jeszcze bardziej interesujące problemy, takie jak postacie ze wstępnie skomponowanymi znakami diakrytycznymi w porównaniu do oddzielnego łączenia znaków diakrytycznych. Następnie przechodzisz do niektórych skryptów arabskich, z trzema oddzielnymi formami wielu liter, a nie tylko dwoma.

W ciemnych czasach większość języków programowania prawie nie rozróżniała wielkości liter. Na przykład Pascal zaczął od komputerów mainframe Control Data, które wykorzystywały tylko sześć bitów na znak (łącznie 64 kody). Większość takich maszyn używała zestawu znaków „CDC Scientific”, który zawierał tylko wielkie litery. Możesz przełączać się na inne zestawy znaków, ale większość z nich zawierała wielkie lub małe litery, ale nie oba - ale używała tych samych kodów dla obu. To samo dotyczyło starożytnych kodów Baudot i tak uważanych za standardowe w początkowych czasach COBOL, FORTRAN, BASIC itp. Do czasu, gdy dostępny był bardziej wydajny sprzęt, ich rozróżnianie wielkości liter było tak głęboko zakorzenione, że zmiana go była niemożliwa .

Z biegiem czasu rzeczywista trudność w rozróżnianiu wielkości liter stała się bardziej widoczna, a projektanci języków w większości zdecydowali („zrealizowane” byłoby prawdopodobnie dokładniejszym terminem), że kiedy / jeśli ludzie naprawdę chcą rozróżniać małe i wielkie litery, lepiej radzić sobie z narzędziami pomocniczymi niż w samym języku.

Przynajmniej IMO, kompilator powinien pobierać dane dokładnie tak, jak przedstawiono, a nie decydować, że „napisałeś to, ale założę się, że naprawdę masz na myśli coś innego”. Jeśli chcesz, aby tłumaczenia były wykonywane, lepiej jest robić je osobno, dzięki narzędziom stworzonym do tego, aby dobrze sobie z tym poradzić.

Jerry Coffin
źródło
26
+1, chciałbym powiedzieć coś podobnego, z mojego doświadczenia wynika, że ​​większość ludzi, którzy na to narzekają, to ci sami ludzie, którzy nie biorą pod uwagę innych języków / zestawów znaków.
Jeremiah Nunn
5
Moje wielkie pytanie też, czy kompilator zacznie zauważać różne pisownie, czy powinien pozwolić ci dowolnie wstawiać podkreślenia lub inne „separatory słów”? Czy może spróbuje „zrobić to, czego się spodziewasz”, gdy źle przeliterujesz identyfikator? Jak daleko to zajdzie? (BTW, Ada ze względów jasności zezwala na arbitralne podkreślanie liczb ).
dash-tom-bang
3
@Barry: Oba są prawie takie same - prawie każdy inny język na ziemi wymaga znaków, które nie są dostępne w ASCII. Co do tego, nawet jeśli sobie radzimy, jest to raczej ograniczone nawet dla języka angielskiego - na przykład zmusza cię do napisania słowa „kooperacja” jako „współpraca”. Na szczęście maszyny do pisania przyzwyczaiły ludzi do takich ograniczeń na długo przed pojawieniem się komputerów, do tego stopnia, że ​​niewiele osób uważa nawet możliwość użycia wszystkich znaków, które kiedyś uznano za konieczne.
Jerry Coffin
2
@ dash-tom-bang: napisano kompilatory, które próbowały robić takie rzeczy (poprawna pisownia i co nie). Doświadczenie pokazuje, że zwykle lepiej jest uruchomić kompilator szybciej i wyświetlać lepsze komunikaty o błędach.
Jerry Coffin
2
@phresnel Or „SZ”. Dla obu można wysunąć dobre argumenty.
Vatine
114

Dlaczego ktokolwiek chciałby, aby nie uwzględniać wielkości liter? W jakim scenariuszu warto odwoływać się do jednej zmiennej, jak VARIABLEw jednym miejscu, Variablew innym i variablew trzeciej? Niewrażliwość na przypadki jest irytująca. Wolałbym raczej otrzymać błąd kompilatora, gdy przypadkowo VAriablewpisuję Variable, niż pozwolić, aby literówki tego typu wpadały do ​​mojego kodu.

Podsumowując, w wielu językach programowania rozróżniana jest wielkość liter nie tylko ze względów historycznych / bezwładnościowych, ale ponieważ niewrażliwość na wielkość liter jest złym pomysłem.

nohat
źródło
12
Patrzysz na to na wylot. Tak, odwoływanie się do tej samej zmiennej z wieloma pisowniami może być denerwujące, ale nie jest tak złe, jak posiadanie dwóch różnych identyfikatorów odnoszących się do dwóch różnych rzeczy w tym samym zakresie, które różnią się tylko w przypadku. Niewrażliwość na wielkość liter jest dobra, ponieważ zapobiega temu. (Poza tym prosta literówka nie staje się błędem składni; zobacz link w pytaniu do postu Jeffa na ten temat.)
Mason Wheeler,
88
Ale chcę, aby proste literówki były błędami składniowymi! Nie chcę prostych literówek w kodzie i chcę, aby mój kompilator pomógł mi je znaleźć. Niewrażliwość na wielkość liter utrudnia ich znalezienie. Niewrażliwość na wielkość liter wydaje się tylko pretekstem do niechlujnego kodowania.
nohat
4
@ nohat: Zgadzam się, że kiedy piszesz cokolwiek innego niż to, co chciałeś wpisać, błąd składniowy jest dobrą rzeczą.
Tim Goodman,
13
@Mason Wheeler, ja już przeczytać artykuł, a ja po prostu nie zgadzam więcej. Używałem wielu języków bez rozróżniania wielkości liter i ciągle denerwują mnie literówki.
nohat
11
Absolutnie zgadzam się z niczym - nieuwzględnianie wielkości liter jest absurdalnym pomysłem - i zwykle zwolennicy pochodzą od ludzi, którzy wciąż tęsknią za starymi, dobrymi czasami VB / Basic.
Tim
27

W Javie wielkość liter NIE jest używana, aby zapewnić więcej opcji w kodzie, ale raczej dla bardzo jasnego i spójnego znaczenia semantycznego. ClassesLookLikeThis. objectsLookLikeThis. MethodLookLikeThis (). STATIC_VARIABLES_LOOK_LIKE_THIS. Classes.WithInnerClassesLookLikeThis. NIE zapewnia ono większej swobody: pozwala ci zwięźle upakować niektóre informacje w języku, który w innym przypadku byłby zbyt szczegółowy.

Sądzę, że w jawnie statycznych językach z kompilatorem mucho i obsługą IDE rozróżnianie wielkości liter to świetny sposób na komunikację informacji (np. Java). W przypadku języków takich jak Ruby rozróżnianie wielkości liter prawdopodobnie spowodowałoby WIĘCEJ nieoczekiwanych wyników, chociaż byłbym otwarty na wypróbowanie Ruby bez rozróżniania wielkości liter.

Myślę, że rozróżnianie wielkości liter w ścisłym systemie nie zaciemnia kodu, ale w rzeczywistości czyni go wyraźniejszym. Rozważ możliwy kod Java:

      joe blah = new hUf();

to całkiem jasne, ale co z:

      hUf.WTF();

W obecnej wersji Java automatycznie wiesz, co to jest. W Javie bez rozróżniania wielkości liter jest ona niejednoznaczna, dlatego trzeba by użyć innego mechanizmu, aby odróżnić klasy od instancji od pakietów od metod. I TEN mechanizm prawdopodobnie sprawiłby, że zwymiotowałbyś z tym, jak brzydki jest :)

Dan Rosenstark
źródło
2
NIEEEE! NIE WIĘCEJ CZYNNIKÓW !! int nazwa_pakietu_metody_pakietu? !!
Michael K
2
@Michael, dziwne, jak się wydaje, że nikt nie zauważa, że ​​podkreślenie jest kłopotliwe w pisaniu.
Dan Rosenstark
2
to zależy od twojej klawiatury. Dla mnie (przy użyciu francuskiej klawiatury) _ jest łatwy do pisania, {} są znacznie trudniejsze (używanie AltGr, aby do nich dotrzeć).
PhiLho
6
Ach, więc rozróżnianie wielkości liter jest nową notacją węgierską.
David Thornley
1
Jest to „ bardzo jasne i spójne znaczenie semantyczne ” tylko wtedy, gdy kompilator to egzekwuje. Teraz kompilator, który wymagał, aby nazwy klas zaczynały się od wielkich liter, a nazwy metod pisane małymi literami, w rzeczywistości może być interesującym powodem dużej wrażliwości na wielkość liter.
Ross Patterson
24

Nie sądzę, że zostało „zaimplementowane” tak bardzo, jak „dozwolone”. Rozróżnianie wielkości liter jest domyślnym stanem porównań ciągów; inżynierowi kompilatora wymaga dodatkowej pracy, aby rozróżnić wielkość liter w języku, ponieważ należy dodać dodatkowy kod, aby wykonać rozróżnianie wielkości liter i zachować oryginalne nazwy tokenów w celu poprawnego raportowania błędów i ostrzeżeń.

To prawie na pewno dlatego skończyło się na C; chcieli stworzyć prosty język, który byłby łatwy do wdrożenia dla kompilatora, kosztem użyteczności. Co do tego, dlaczego znajduje się we współczesnych językach? Ponieważ jest oczywiście w C, więc musi to być właściwy sposób! </ tryb sarkazmu>

Mason Wheeler
źródło
3
Ponadto myślę, że w latach 60. i 70., kiedy wymyślano języki programowania, przestrzeń i szybkość są BARDZO ważne. Nie możemy sobie pozwolić na dodatkowe instrukcje i miejsce na porównania bez rozróżniania wielkości liter. W nowoczesnych językach jest to raczej problem „zawsze tak było”. Nie ma powodu, aby nowe języki (jak C #) to robiły.
Jay
1
@Jay: A jednak, z jakiegokolwiek powodu, Pascal, który poprzedza C i wpłynął na jego projekt, nie uwzględnia wielkości liter i nadal kompiluje się szybciej. ;)
Mason Wheeler
@Mason: Nie sądziłem, że Pascal wpłynął na C ... Musiałem to sprawdzić. Zasadniczo wszystkie pochodzą z Algolu / Fortranu! people.mandriva.com/~prigaux/language-study/diagram.png
Jay
1
@Matt: Umm ... skąd to bierzesz? Wszystkie zasoby, które widziałem, datują Pascala na 1970 r. I C na 1972 r.
Mason Wheeler
16
Dzieci w tych czasach. Kiedyś nie mieliśmy małych liter i podobało nam się. Wystarczyło 6 bitów. Oczywiście, teraz wszyscy jesteśmy głusi na SHOUTING.
KeithB,
23

Jeśli nic więcej, upraszcza to parsowanie i pozwala na więcej kombinacji dla nazw zmiennych / klas.

W przypadku analizowania bez rozróżniania wielkości liter użytkownik musiałby używać unikalnych identyfikatorów, ponieważ „myClass” i „MyClass” byłyby tym samym. Alternatywnie, musisz dodać warstwy złożoności do parsera, aby upewnić się, że możesz określić, który identyfikator jest używany na podstawie kontekstu.

Rozważ taki przypadek:

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

Załóżmy, że klasa XmlWriter ma również metodę statyczną o nazwie „Zapis”. Czy wywołujesz go w instancji lub w klasie, jeśli nie zastosowano tu rozróżniania wielkości liter?

Adam Lear
źródło
14
To zła konwencja nazewnictwa. Chciałbym kogoś udusić jeśli writei Writebyły dwa zupełnie różne sposoby.
TheLQ
5
Muszę się zgodzić z TheLQ w tej sprawie. Doprowadza mnie to do szału, kiedy pracuję w bibliotece C i widzę deklaracje typu „HWND hwnd;”. Każdy, kto wykorzystuje takie rozróżnianie wielkości liter, powinien zostać zabrany i zastrzelony.
Mason Wheeler,
4
@ TheLQ metody mają ten sam przypadek. Jako przykład użyłem różnych przypadków w nazwach klas / zmiennych.
Adam Lear
6
@ Anne Lear, myślę, że to zły przykład. W przypadku języka, w którym nie jest rozróżniana wielkość liter, nie musisz się martwić o to, którą metodę wywołać, ponieważ już masz błąd składniowy, próbując użyć nazwy klasy dla nazwy zmiennej.
Matt Olenik,
5
@Matt nie powinieneś kodować bez podświetlania składni. Rozumiem bez IDE, ale kodowanie w edytorze bez podświetlania składni ... dlaczego ktokolwiek miałby to zrobić dla siebie?
Davy8
13

Podoba mi się rozróżnianie wielkości liter, jeśli tylko z tego powodu sprawia, że ​​kod sam się dokumentuje:

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

Zwykle programuję w Pythonie, ale w czasach C # bardzo wygodnie było nazwać instancje klas takie same jak klasa, ale małe (lub wielbłądzkie) litery (jak powiedzieli inni):

Thing thing = new Thing();

Używanie języków bez rozróżniania wielkości liter wymaga w tym celu innej konwencji, tj. Pewnego rodzaju sigil, takiego jak:

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

Co jest „złą rzeczą”.

Uważam również, że wygodne jest grep (z rozróżnianiem wielkości liter), aby znaleźć odniesienie do klasy w porównaniu do użycia zmiennej. W przypadku języka bez rozróżniania wielkości liter byłoby to łatwiejsze. To samo dotyczy wyszukiwania i zamiany.

Wreszcie, jako programista, kiedy widzę słowa z różnymi przypadkami, wyskakuje mi, że są to różne rzeczy ... Rzadko mam błędy, w których zmienne przypadki były błędne, nawet w dynamicznych językach skryptowych, w których kompilator by pomógł.

Hollister
źródło
10

Ludzie zwracają uwagę na kształt słów, zanim je przeczytają. Rozróżnianie wielkości liter utrzymuje spójność kształtu symbolu w całym kodzie. Zgadzam się również z powyższymi stwierdzeniami, że różne konwencje oznaczają różne typy symboli. Wrażliwość na wielkość liter i niewrażliwość mogą być nadużywane. Źli programiści zawsze generują zły kod ... znajdą sposób.

Weź język za przykład. Dlaczego zaczynamy zdania i nazywamy rzeczy wielkimi literami ... Czy dzieje się tak również z powodu Uniksa?

Tjaart
źródło
@JUST Komentarze mają na celu poszukiwanie wyjaśnień, a nie dłuższą dyskusję. Jeśli masz rozwiązanie, zostaw odpowiedź. Jeśli Twoje rozwiązanie jest już opublikowane, głosuj za nim. Jeśli chcesz, aby omówić tę odpowiedź z innymi, skorzystaj czat . Aby uzyskać więcej informacji, zobacz często zadawane pytania .
Adam Lear
9

Myślę, że dla statycznie wpisywanych języków, takich jak C # i Java, tak naprawdę nie ma żadnej wartości. Ponieważ w większości przypadków masz IDE, które i tak automatycznie poprawi dla Ciebie niedopasowania wielkości liter, więc na koniec dnia, jeśli przypadkowo wpisam „VAriable”, moje IDE automatycznie poprawi to na „ Zmienna „dla mnie. Dodaj do tego MyClass myClass;konwencje stylu, a zobaczysz, że rozróżnianie wielkości liter niekoniecznie jest złą rzeczą.

W przypadku języków z dynamicznym pisaniem argumentów może być więcej, ponieważ IDE trudniej jest odgadnąć autokorekcję, ale w przypadku języków z dynamicznym pisaniem masz już o wiele więcej powodów do zmartwień (pod względem literówki), że stosowanie spójnej konwencji casingu nie spowoduje jeszcze większego obciążenia.

Tak więc, chociaż nie istnieje żaden prawdziwy powód, dla którego języki nie rozróżniają wielkości liter, nie ma też żadnego prawdziwego powodu, dla którego powinny być takie.

Artykuł Scotta Hanselmana na temat „SignOn” vs „Signon” dotyczył porównań ciągów znaków i nie miał nic wspólnego z językami programowania. Zgadzam się, że ciągi, które wpisują użytkownicy, zawsze powinny być porównywane bez rozróżniania wielkości liter, ale myślę, że to inna gra dla identyfikatorów w języku programowania.

Dean Harding
źródło
1
+1 za wzmiankę o „IDE, które automatycznie poprawi niedopasowania wielkości liter”
DavRob60,
3
IDE są dla Wimps. Programuję ołówkiem i papierem, a następnie skanuję kod.
Dan Rosenstark,
6

Kiedy w języku rozróżniana jest wielkość liter, korzystam z niego, aby odtworzyć konwencjonalne użycie przypadków w matematyce i nauce. Oto lista (nie wyczerpująca) niektórych konwencji spraw:

  • W teorii prawdopodobieństwa małe litery fzwykle reprezentują funkcję gęstości prawdopodobieństwa (pdf), podczas gdy duże litery Freprezentują odpowiednią funkcję rozkładu skumulowanego (cdf).
  • Również w teorii prawdopodobieństwa wielkie litery oznaczają zmienne losowe X, a odpowiadające im małe litery oznaczają ich realizacje x, jak w $ Pr [X = x] \ leq 0,05 $.
  • W algebrze liniowej wielkie litery są zwykle używane w odniesieniu do macierzy, podczas gdy małe litery są ogólnie używane w odniesieniu do liczb, np. $ A = [a_ {ij}] $.
  • Symbole jednostek zapisywane są małymi literami (np. M dla licznika), z wyjątkiem litrów (L) i jednostek pochodzących od nazwiska osoby (W dla Wata, Pa dla Pascala, N dla Newtona i tak dalej).
  • Symbole przedrostków, które oznaczają milion lub więcej, są pisane wielkimi literami (M dla mega (milionów)), a te mniej niż milion są małymi literami (m dla milli (tysięcznych)).
Inne
źródło
3
Ważny punkt, ale naruszyłbyś konwencje kodowania prawie każdego popularnego języka programowania, które używają rozróżniania wielkości liter do własnych celów.
Ken Bloom
3

Właśnie pomyślałem, że to z powodu Uniksa i C - ale to rodzaj problemu z kurczakiem i jajkiem, na który tylko dziadkowie potrafią poprawnie odpowiedzieć.

Posługuję się uzasadnieniem zastosowanym przez Kurczaki w „Wielkanocnym króliczku przybywa do miasta”, gdy zapytano ich, czy przyszły przed jajami. Ponieważ w Arce Noego były kury, kury były pierwsze. Dlatego, ponieważ GCC działa na Uniksie, Unix był na pierwszym miejscu, dlatego ponieważ Unix tak bardzo troszczy się o wielkość liter, C i wszystkie jej warianty i potomki, to wszystko, co nakłada nawiasy klamrowe, dba o wielkość liter.

Prawdopodobnie istnieje również związek między nawiasami klamrowymi a rozróżnianiem wielkości liter.

Peter Turner
źródło
Unix pojawił się wiele lat przed GCC, ale oryginalny kompilator BCPL pojawił się przed Unixem i generalnie stworzył „składnię C”.
Ross Patterson
2

Oprócz doskonałych odpowiedzi podanych do tej pory chciałbym zauważyć, że rozróżnianie wielkości liter daje również dodatkowe „przestrzenie nazw”. Na przykład Perl posiada kilka specjalnych bloków jak BEGINi ENDuruchamianych podczas różnych porach niż normalne kodu (BEGIN w czasie kompilacji, END po normalny program został zakończony), a po tym, jak wszystkie kapitalizacji czyni je wyróżniać, i oznacza, że małe litery warianty nie są słowami zastrzeżonymi.

Można posunąć się jeszcze dalej i zarezerwować nazwy pisane wielkimi literami do przyszłego użycia przez język i nie wyrządzać żadnej szkody zwykłym programistom, którzy zwykle NIE ZROBIJĄ W SWOIM KODZIE.

Moritz
źródło
2

„Uwzględnianie wielkości liter” jest zawsze lepsze dla osób technicznych, aby zmniejszyć dwuznaczność. Weź nazwę pliku jako przykład. Radzenie sobie z nazwą pliku Windows jest większym problemem niż nazwa pliku Unix, ponieważ nazwa pliku w systemie Windows nie rozróżnia wielkości liter, podczas gdy nazwa pliku w systemie Unix rozróżnia małe i wielkie litery.

Powrót do programowania. W przypadku nazwy klasy, nazwy metody, nazwy zmiennej większość języków nie wymusza reguły stylu nazewnictwa. Czasami ze względu na prostotę wykonania „refleksji” możemy po prostu użyć nazwy „rozróżniana wielkość liter”, aby połączyć się z innym źródłem danych bez konwersji lub rozwiązać problem o tej samej nazwie, ale w innym przypadku.

linquize
źródło
Nonsens. Wydaje się, że zmniejsza to niejednoznaczność, ponieważ już oczekuje się zachowania z rozróżnianiem wielkości liter.
Ross Patterson
1

Jestem zaskoczony tym głosem. Teraz, gdy nikt nie chce, abyś używał podkreślenia lub m_nazwy pola w języku C #, właśnie używałem wielbłąda, a jeśli nazwa pola jest taka sama jak nazwa właściwości publicznej, to tylko nazwa właściwości publicznej to wielkość Pascala a podkładem jest wielbłąd, jak sądzę, „niech tak będzie” - tego właśnie chce cała społeczność programistów. Do tej pory nie spowodował żadnych problemów.

Scott Whitlock
źródło
0

Zwłaszcza niektórzy programiści pochodzą z początków BASIC-a, gdzie nazwa zmiennej może mieć tylko 2 znaki.

Kiedy więc może być dowolna liczba postaci, stają się bardzo szczęśliwi. I wraz z rozróżnianiem wielkości liter - ponieważ nie chcą się również martwić, SomeNameże przypadkowo będą równi SOMENAMEi spowodują błąd z powodu takich rzeczy.

Michael W.
źródło