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

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 .

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ć.

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.

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 :)

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>

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?

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ł.

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?

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.

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)).

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.

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.

„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.

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.

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.