Słowa kluczowe bez rozróżniania wielkości liter w języku [zamknięte]


31

Próbujemy napisać niestandardowy język skryptowy. Pojawiła się sugestia, aby język wybaczał, podając słowa kluczowe bez rozróżniania wielkości liter .

Osobiście nie podoba mi się ten pomysł, ale niewiele osób w moim zespole pochyla się nad nim, mówiąc, że sprawi, że użytkownik końcowy będzie szczęśliwy! Podano przykłady języków takich jak FORTRAN, BASIC, SQL, w których nie rozróżnia się wielkości liter.

Czy to dobry pomysł?


4
Cóż, Visual Basic na ogół nie rozróżnia wielkości liter, czy to odpowiada na twoje pytanie? ; P
yannis


3
Zauważ, że bardzo trudno jest rozróżnić wielkość liter w identyfikatorach, chyba że ograniczysz użytkowników do zestawu znaków ASCII.
Simon Richter

2
@MainMa: C ++ przynajmniej nie bezpośrednio. Pozwala to postacie realizacji zdefiniowane w identyfikatorze, ale to, co jest zagwarantowane tylko a-zA-Z, 0-9(z wyjątkiem na początku) i _.
Xeo

2
VB6 faktycznie używa pewnego rodzaju podejścia hybrydowego: możesz pisać słowa kluczowe i identyfikatory w dowolny sposób, a IDE natychmiast konwertuje je na zapisany sposób. (Możesz nawet napisać „endif”, a zostanie on przekonwertowany na „End If”.)
Felix Dombek

Odpowiedzi:


42

Zadaj sobie pytanie, kim jest użytkownik końcowy. Jeśli ma to być napisane przez kogoś, kto ma doświadczenie w programowaniu w C lub Javscript, lub w IT w Uniksie, to rozróżnianie wielkości liter jest prawdopodobnie słuszne, ponieważ tego właśnie oczekuje użytkownik. Ale dla większości użytkowników końcowych, nawet użytkowników zaawansowanych, będzie to mylące.

W VB / VBA / VBScript nie rozróżniana jest wielkość liter, i była to decyzja podjęta, aby umożliwić osobom niebędącym programistami łatwe zrozumienie języka. Formuły Excela, nie do końca skrypty, ale tak blisko jak wielu użytkowników, nie rozróżniają wielkości liter. W większości pism wybór wielkości liter może sprawić, że tekst będzie wyglądał bardziej lub mniej profesjonalnie i dopracowany, ale w przypadku tekstu sam nie zmieni semantycznego znaczenia słów. Dlatego uważam, że osoby, które nie są programistami, będą mylić język skryptowy uwzględniający wielkość liter.

Znowu nie jest to wybór techniczny. Jest to wybór zarządzania produktem, który musi być dokonany przez osoby, które dobrze znają odbiorców docelowych.


Zastanów się, które systemy plików rozróżniają wielkość liter, zanim spojrzysz na języki programowania. FAT / NTFS dla Windows i HFS + dla MacOS X nie rozróżniają wielkości liter, podczas gdy UFS / NFS dla Unix rozróżnia małe i wielkie litery. Zaawansowanym użytkownikom podoba się możliwość rozróżniania plików / zmiennych według drobnych różnic, podczas gdy większość użytkowników woli zachować intuicyjność. Jak mówi Avner, różnica polega na wyborze zarządzania produktem.
Michael Shopsin

4
Ponieważ jest to język skryptowy, nie trzeba się zastanawiać - niewrażliwość na wielkość liter jest właściwą drogą. Po co zwracać uwagę na wielkość liter? Jeśli odpowiedź brzmi „być jak C i Java”, czy to naprawdę dobry powód?
Ben

15
@Ben Python, Ruby, bash, Lua i Perl to przykłady bardzo popularnych języków skryptowych, w których rozróżniana jest wielkość liter. Języki bez rozróżniania wielkości liter obejmują języki korporacyjne, takie jak Delphi i SQL (i COBOL IIRC, jeśli to policzysz). Dlaczego jest to oczywiste dla języków skryptowych i dlaczego projektanci największych na świecie języków skryptowych się nie zgadzają?

2
Nie może to być oczywiste, ponieważ jest językiem skryptowym - istotne pytanie brzmi: kto wykonuje skrypt i jaki jest dla nich najlepszy wybór? (Ja też powiedzieć, że powinieneś być zgodne: jeśli słowa kluczowe są wielkości liter, proszę nie rób identyfikatory wielkość liter ...)
comingstorm

@delnan Myślę, że logicznym wyborem jest, aby język skryptów ukierunkowany na system operacyjny, w którym wbudowana jest rozróżnianie wielkości liter, powinien również rozróżniać wielkość liter.
Artemix,

16

Powinieneś zdecydować w oparciu o doświadczenie użytkownika, które chcesz przedstawić, a nie to, jak łatwe lub trudne jest wdrożenie.

Jeśli to ułatwi twoim użytkownikom rozróżnianie wielkości liter, to powinieneś to wdrożyć.

Na przykład w SQL nie jest rozróżniana wielkość liter. Dzięki temu jest bardzo łatwy w użyciu w interaktywnym otoczeniu.

Innym sposobem, aby spojrzeć na to będzie tam kiedykolwiek być różnica między keywordi Keywordw swoim języku, a ta różnica jest znacząca dla użytkownika? W przypadku języka skryptowego powiedziałbym, że odpowiedź brzmi „nie”.


3
+1 dla „czy ta różnica będzie znacząca dla użytkownika”. Użytkownik jest najważniejszy.
Ben

Dlaczego korzystanie z języka SQL jest łatwiejsze w ustawieniach interaktywnych z powodu braku rozróżniania wielkości liter? Czy to dlatego, że możesz przypadkowo włączyć Caps Lock i nie zauważyć?
Kaz.

@Kaz - Prawie.
ChrisF

11

Języki programowania powinny rozróżniać małe i wielkie litery, kropka. Ludzie mogą bardzo łatwo się do tego dostosować: po prostu muszą pamiętać, aby pracować głównie małymi literami i uważać na identyfikatory mieszanych lub wielkich liter w istniejących interfejsach API.

Kiedyś wydawało się oczywiste, że w językach nie jest rozróżniana wielkość liter. Wynika to z faktu, że małe litery nie były dostępne we wszystkich systemach komputerowych i ich urządzeniach we / wy (klawiatury, drukarki i urządzenia wyświetlające). Implementacje języka programowania musiały akceptować programy pisane wielkimi literami, ponieważ tylko te mogły być wyświetlane lub drukowane. W tym celu musieli rozróżniać małe i wielkie litery, ponieważ akceptacja wielkich liter i rozróżnianie wielkich i małych liter oznacza jednocześnie odrzucanie małych liter. Małe litery były czymś, czego chcieli programiści, ale nie zawsze. Nikt tak naprawdę nie chciał pracować z programami, które krzyczały wielkimi literami; to było tylko ograniczenie sprzętowe.

Przez pewien czas często składano skrzynki w terminalach. Gdyby terminal mógł wyświetlać tylko wielkie litery, ale trzeba było zalogować się do systemu komputerowego obsługującego duże i małe litery, terminal składałby małe litery na wielkie. Myślisz, że to było tak dawno temu? „Podobnie jak Apple II, Apple II Plus nie miał funkcji małych liter”. (http://en.wikipedia.org/wiki/Apple_II_Plus) Gdy użytkownicy wczesnych komputerów Apple wybrali numer BBS, który zawierał małe i duże litery, emulator terminala (lub host) musiał to wszystko złożyć na wielkie litery. Wiadomości pisane wielkimi literami były wówczas popularne na tablicach ogłoszeń. Ta funkcjonalność jest nadal dostępna w systemach operacyjnych typu Unix, takich jak jądro Linux. Na przykład wpisz stty olcucw wierszu polecenia powłoki.Dyscyplina linii tty w systemie Unix może odwzorowywać małe litery na duże na wyjściu i może mapować duże litery na małe na wejściu. Pozwala to na pracę w języku programowania małymi literami na terminalu, który nie ma małych liter.

Niewrażliwość na wielkość liter to przestarzała koncepcja z minionej epoki komputerów, która nie działa zbyt dobrze we współczesnym świecie internacjonalizacji komputerów. Czy rozszerzasz to na inne języki? Co powiesz na francuski: czy uważasz È i è za równoważne? Czy japoński? Czy uważasz hiragana i katakana za zwykłe przypadki, tak że フ ァ イ ル i ふ ぁ い る są tym samym identyfikatorem? Obsługa takiego szaleństwa znacznie skomplikuje twój analizator leksykalny, który będzie musiał mieć mapy równoważności wielkości liter dla całej przestrzeni Unicode.

Pamiętaj, że matematyka rozróżnia małe i wielkie litery. Na przykład sigma z wielkich liter może oznaczać sumowanie, podczas gdy sigma z małych liter oznacza coś innego, na przykład odchylenie standardowe. Może się to zdarzyć w tej samej formule bez żadnych trudności. (Czy język programowania sprawi, że Σ i σ będą równoważne?)

Angielska ortografia jest wrażliwa. Na przykład wiele właściwych rzeczowników odpowiada zwykłym rzeczownikom lub nawet innym częściom mowy. „may” jest czasownikiem, ale „maj” to miesiąc lub imię kobiety. Ponadto, jeśli akronim lub skrót jest zapisany małymi literami, może to być mylące. SAT oznacza scholastyczny test umiejętności, podczas gdy „sat” jest imiesłowem przeszłym słowa „sit”. Inteligentni ludzie zwracają uwagę na szczegóły i odpowiednio wykorzystują duże litery.

Zasadniczo, każdy nowy język programowania utworzony od 1985 r., Bez rozróżniania wielkości liter, jest DLA TYCH, KTÓRZY WCIĄŻ SĄ W E-MAILACH I OGŁOSZENIACH BEZ DRUGIEJ MYŚLI.

Co się stanie, jeśli Twój język będzie kiedykolwiek używany jako cel generowania kodu do tłumaczenia kodu na inny język, a w tym języku rozróżniana jest wielkość liter? Będziesz musiał jakoś przekształcić wszystkie nazwy, aby uchwycić to rozróżnienie. (Twierdzenie, że nie jest to decyzja techniczna, a jedynie kwestia preferencji emocjonalnych docelowych odbiorców, jest śmieszne).

Spójrz na irytujące problemy związane z obsługą spraw w systemie Windows, gdy pliki są importowane z innego systemu operacyjnego. To problem techniczny. Systemy plików z rozróżnianiem wielkości liter mają problem z danymi obcymi, które nie uwzględniają wielkości liter.

Common Lisp osiągnął idealne podejście: w nazwach symboli rozróżniana jest wielkość liter, ale po odczytaniu tokenów są one składane na wielkie litery. Oznacza to, że tokeny foo, fOO, FOOi Foowszyscy mają takie samo znaczenie symboli: symbol, którego nazwa jest przechowywany jako ciąg znaków "FOO". Ponadto takie zachowanie jest tylko domyślną konfiguracją tabeli odczytu. Czytelnik może składać litery na wielkie, małe, odwracać lub zachowywać. Dwie ostatnie opcje powodują, że dialekt rozróżnia małe i wielkie litery. W ten sposób użytkownicy mają maksymalną elastyczność.


1
„Co powiesz na francuski: czy uważasz È i è za równoważne? Czy japoński? Czy uważasz hiragana i katakana za zwykłe przypadki, tak że フ ァ イ ル i ふ ぁ い る są tym samym identyfikatorem?” Odpowiedź brzmi „tak” i jest to tylko głupota, jeśli uważasz, że kultury innych ludzi są głupie.
Ben

Cóż, przygotuj się na eksplozję twojej małej głowy, ponieważ nie sądzę, że kultury innych ludzi są głupie (z pewnymi wyjątkami, w odniesieniu do bieżących wydarzeń na świecie), ale jednocześnie uważam, że traktowanie フ ァ イ ル i całkowicie moralne jestふ ぁ い る jako ten sam identyfikator w języku programowania.
Kaz.

@Ben znasz wymienione kultury? Gdybyś wiedział, o czym mówił Kaz, nie nazwałbyś go głupcem.
David Cowden,

1
@DavidCowden, w żadnym momencie nie nazwałam Kaz głupcem. Zgadzam się, że zawsze należy używać tego samego przypadku wszędzie tam, gdzie używa się identyfikatora. Różnica Kana jest ważniejsza niż różnica wielkości liter, podobnie jak różnica akcentu jest większa niż różnica wielkości liter. Jakkolwiek głupio jest mieć dwa identyfikatory, które różnią się tylko przypadkiem, tak samo głupio jest mieć dwa identyfikatory, które różnią się tylko kana lub akcentem. Bardziej sensowne jest zakazanie identyfikatorów różniących się tylko kana lub akcentem niż traktowanie ich tak samo, ale nie ma sensu traktować ich jako odmiennych.
Ben

Jeśli zabraniasz identyfikatorów, które różnią się tylko przypadkiem, akcentem, kaną lub czymkolwiek, to milcząco przyznajesz, że są takie same (ale tylko nalegając na spójność). Lepiej nie banować takich rzeczy i pozostawić je użytkownikom w celu zachowania konwencji kodowania. Lepszym pomysłem byłoby posiadanie systemu deklaratywnego, w którym program mógłby to potwierdzić fooi Foopowinny być traktowane jako synonimy lub odrębne. Bez takiej deklaracji jest to błąd dla obu z nich. A ponieważ deklaracja się nie rozszerza FOO, FOOnadal jest zabroniona; należy go dodać.
Kaz.

6

Rzeczywistym czynnikiem decydującym jest to, jak często będziesz chciał mieć wiele rzeczy o tej samej nazwie. Rozróżnianie wielkości liter działa w języku SQL, ponieważ często nie ma potrzeby nazywania kolumny SELECT. Byłoby denerwujące w Javie, ponieważ każda inna linia wygląda Object object = new Object()tam, gdzie chcesz, aby ta sama nazwa odnosiła się do klasy, instancji i konstruktora.

Innymi słowy, rozróżnianie wielkości liter jest najbardziej przydatne w przypadku przeciążania nazwy, a przeciążanie jest szczególnie przydatne w dużych, złożonych projektach. W przypadku rzadszych zastosowań, takich jak język skryptowy, rozróżnianie wielkości liter może znacznie ułatwić programowanie.

Kiedyś stworzyłem język reguł, w którym identyfikatory nie tylko nie rozróżniają wielkości liter, ale były również niewrażliwe na spacje. Pozwoliłem także na tworzenie aliasów odnoszących się do tego samego identyfikatora. Na przykład ProgrammersStackExchange, wymiana stosu programistów i PSE są rozdzielone na dokładnie ten sam symbol i mogą być używane zamiennie.

W mojej domenie działało to bardzo dobrze, ponieważ domena miała wiele bardzo dobrze znanych sposobów na odniesienie się do tej samej rzeczy, a konflikty nazw były rzadkie. Nikt nie byłby zaskoczony, wpisując zapytanie przy użyciu jednej nazwy, a wynik użył innej. Obsługa języków bardzo ułatwiła tłumaczenie między domeną a językiem programowania. Utrudniło to jednak niektóre zadania, takie jak znalezienie wszystkich odniesień do zmiennej. Na szczęście w moim przypadku tego rodzaju sytuacje albo rzadko pojawiały się, albo były dość łatwe do zbudowania narzędziowego wsparcia, ale trzeba wziąć pod uwagę własną sytuację.


Nie sądzę, że chcę ponownie użyć słów kluczowych dla nazw. SQL, Visual Basic i C # (dwie pierwsze bez rozróżniania wielkości liter i druga z rozróżnianiem wielkości liter) rozwiązują to, umożliwiając sposób cytowania identyfikatorów: "double quotes"(lub [brackets]w MS SQL) w SQL, [brackets]w VB.net i @atsignw C #.
Random832

„jak często będziesz chciał mieć wiele rzeczy o tej samej nazwie”. Niewrażliwość na wielkość liter oznacza, że ​​należy dodać narzut, aby jednoznacznie nazwać nazwy, które w innym przypadku byłyby rozpatrywane indywidualnie (np. M jako prefiks dla „członka”, aby odróżnić od nazwy właściwości nieprefiksowej, powiedzmy).
nwahmaet

Dlaczego nazwałbyś obiekt obiektowy? To tylko prośba o kłopoty.
Ben

@Ben, załóżmy, że implementujesz obiekt kontenera, co jeszcze zamierzasz wywołać parametr do metody dodawania?
Winston Ewert

@WinstonEwert, nazwałbym to o. Naprawdę nie ma znaczenia, jak to nazwiesz, ponieważ jest to tylko nazwa parametru. Pod warunkiem, że nie jest to obraźliwe, nielegalne lub może powodować zamieszanie .
Ben

5

Zakładając, że w Twoim języku skryptowym rozróżniana jest wielkość liter - czy zamierzasz utworzyć kompilator lub moduł sprawdzania składni, który poinformuje użytkownika, czy popełni literówkę, używając niewłaściwej wielkości liter w nazwie zmiennej lub słowie kluczowym? Jeśli nie, byłby to bardzo silny argument za tym, aby język nie rozróżniał wielkości liter.


Dobra uwaga, ale nie odpowiedź.

@delnan: być może nie jest to odpowiedź tak dobra jak ta z Avnera Shahara-Kashtana (której dałem +1), ale prawdopodobnie pomocna dla PO.
Doc Brown,

3
Tak, pomocne jako komentarz;)

Więc jeśli przeredagowano to, by powiedzieć, że dobrym pomysłem jest ostrzeżenie użytkownika o rozróżnianiu wielkości liter, to byłaby to odpowiedź? Dla mnie to zostało założone.
JeffO

Nie, to byłby drobny problem, który prawie nie odpowiada na pytanie sformułowane jako odpowiedź. MOIM ZDANIEM.

4

Czy potrafisz deklarować zmienne w locie? Jeśli tak, sprzeciwiam się rozróżnianiu wielkości liter, ponieważ śledzenie błędu spowodowanego przez

ATypo = 42; 

w przeciwieństwie do

Atypo = 42; 

niepotrzebnie prosi o czas debugowania, gdy równoważenie dwóch instrukcji ułatwia życie.


2
IMHO ułatwia także czytanie. W końcu, kiedy zaczynasz zdanie, zaczynasz pisać pierwsze słowo, ale nie zmieniasz jego znaczenia. To samo powinno dotyczyć kodu!
NWS

2
@ delnan - chciałeś czytelności, używa tego samego alfabetu, po co zmieniać znaczenie, kiedy zmieniasz wielkość liter?
NWS

1
@delnan, według Sądu Najwyższego Stanów Zjednoczonych Ameryki, języki komputerowe są wyrazistym językiem zaprojektowanym do zrozumienia zarówno przez komputery, jak i przez ludzi (orzekając, że kod komputerowy jest chroniony przez pierwszą poprawkę). Nie są Anglikami, ale są językiem, a powiedzenie „BOB” różni się od „bob” różni się od „Bob” jest idiotyczne w każdym języku przeznaczonym dla ludzi. Tak, możemy nauczyć się sobie z tym radzić, ale to nie jest żadna wymówka.
Ben

2
@Ben Pozwól mi zrobić analogię. Notacja matematyczna jest, w przeciwieństwie do języków programowania, wyłącznie dla ludzi. Nie ma tu zastosowania zwykły argument, że nieistotność wielkości liter jest historycznym artefaktem starożytnych komputerów. Wątpię jednak, by jakikolwiek matematyk argumentowałby to ai Apowinien być wymienny. Sprawy są spójne, bez wyjątków. Na przykład, w niektórych kontekstach dla zestawów używane są wielkie litery, podczas gdy małe litery są elementami zestawu. Kolejny przykład występuje w elektrotechnice, małe litery są zależne od czasu, a duże litery są niezależne od czasu ...

2
@Ben ... w tych i innych kontekstach nie widzę rozróżniania wielkości liter jako ograniczenia. Widzę to jako uwolnienie zbędnych symboli, które można wykorzystać w bardziej produktywny sposób, poprzez konwencje, które przekazują znaczenie, między innymi, wielką literą. Jak każda krótka notacja specyficzna dla domeny, może to wydawać się laikowi obce, ale pozwala ekspertom komunikować się lepiej i szybciej.

2

Podano przykłady języków takich jak FORTRAN, BASIC, SQL, w których nie rozróżnia się wielkości liter.

Powodem, dla którego FORTRAN i SQL (i COBOL) nie rozróżniają wielkości liter, jest to, że zostały pierwotnie zaprojektowane do użytku na komputerach, na których normalne zestawy znaków miały tylko wielkie litery. Niewrażliwość na wielkość liter w tych językach (przynajmniej) jest bardziej historycznym artefaktem niż wyborem projektu językowego.

Teraz możesz argumentować, że niewrażliwość na wielkość liter jest bardziej wybaczająca, ale drugą stroną jest to, że rozróżnianie wielkości liter powoduje, że kod jest bardziej czytelny, ponieważ zapewnia współdziałanie z użyciem funkcji łączenia się z aplikacją.


4
Mam dość argumentu „X jest dobry, Y wymusza powiązaną rzecz Z, dlatego Y robi dobrze, wymuszając X” (np. Rozsądny styl kodowania / zasada Python / offside). Żaden dobry programista nie wykorzystuje wielkich liter w sposób, który poważnie wpływa na czytelność, nawet jeśli jest to dozwolone. Ci, którzy nadużywają rozróżniania wielkości liter, również niesolidnie używają wielkich liter w środowisku rozróżniającym wielkość liter (i popełniają setki innych okrucieństw), są po prostu zmuszeni do korzystania z tej samej złej wielkiej litery dla każdego użycia indywidualnej nazwy. Źli programiści mogą pisać Fortran w dowolnym języku. (Oświadczenie: Jestem wielkim fanem rozróżniania wielkości liter!)

Zgadnij co. Mam dość czytania kodu napisanego przez złych programistów, którzy myślą, że są tak dobrymi programistami, że mogą opracować własne reguły stylu. (Zastrzeżenie: Nauczyłem się programować w czasach FORTRAN i COBOL, i nie cierpię nieczułości liter i innych okropności językowych z tamtej epoki.)
Stephen C

Każde użycie dużej litery w języku niewrażliwym na wielkość liter stanowi nadużycie niewrażliwości.
Kaz

@Kaz - erm ... spróbuj powiedzieć to milionowi programistów SQL.
Stephen C

1

Rozróżnianie wielkości liter uważane jest za szkodliwe.

W życiu nie jest rozróżniana wielkość liter, ani użytkownicy, ani programiści.

Języki, w których rozróżniana jest wielkość liter, to historyczny wypadek z ograniczonymi systemami, w których porównywanie bez rozróżniania wielkości liter jest trudne. Ten handicap już nie istnieje, więc nie ma powodu, aby ponownie tworzyć system komputerowy uwzględniający wielkość liter.

Chciałbym powiedzieć, że rozróżnianie wielkości liter jest złe , ponieważ stawia wygodę komputera przed wygodą użytkownika.

(Powiązane, przypominam sobie kilka lat temu, jakiś geniusz odmówił zapłacenia rachunku za kartę kredytową, ponieważ jego nazwisko było pisane wielkimi literami, ale napisał to mieszaną literą. Dlatego argumentował, że nie był on odpowiednio skierowany do niego i nie był uzasadnione żądanie zapłaty. Sędzia potraktował argument tak, jak na to zasługiwał).


Rozróżnianie wielkości liter nie stawia wygody komputera przed wygodą użytkownika. Zaimplementowałem języki z rozróżnianiem wielkości liter i bez rozróżniania wielkości liter, a jedyną różnicą jest dodatkowe wywołanie funkcji w kilku miejscach. Także inne odpowiedzi mówią, że brak wrażliwości na przypadki jest historycznym artefaktem ze względu na ograniczone zestawy znaków - zaprzecza twojej teorii, prawda?

Unicode umieszcza to w zupełnie innej dziedzinie.
DeadMG

3
Ten blog nie podaje żadnego uzasadnienia, dlaczego jest zły w C, tylko w Pythonie lub PHP, a OP nie mówi o rozróżnianiu wielkości liter, tylko o słowach kluczowych . Ten link nie ma absolutnie nic do powiedzenia na ten temat.
DeadMG

1
Edytory @Ben mogą (i robią) naprawiać pisanie podczas pisania bez względu na reguły języka. Zezwalanie na błędy, które mimo to prześlizgują się (np. Ponieważ nie masz pod ręką fantazyjnego edytora), nie pomaga. Oznacza to pozostawienie problemu, zamiast narzekać na jego naprawę. Co więcej, kiedy użyję spójnej wielkiej litery, mogę mieć wiele różnych identyfikatorów różniących się wielkością liter, ale oznaczających bardzo różne rzeczy i łatwych do przeanalizowania dla ludzi dzięki kontekstowi i wielkości liter, bez dwuznaczności.

2
@Ben: W niektórych językach obowiązują bardzo rygorystyczne zwyczaje leksykalne, a nawet reguły. W wersjach C i C ++ wielkimi literami jest makro, a makra powinny pozostać wielkimi literami, aby zapobiec pomyłkom. Niektóre języki mają różne znaczenie dla symboli z początkowymi lub bez wielkich liter (i nie wiem, jak dobrze by się spisały w różnych językach, które nie mają odpowiednich wielkich i małych liter). Jeśli masz takie reguły lub konwencje, uzyskujesz efekt różnych przestrzeni nazw, a powielanie nazw identyfikatorów w różnych obszarach nazw często działa.
David Thornley,

1

Z mojego osobistego doświadczenia nie widzę dużej różnicy między językami rozróżniającymi małe i małe litery.

Ważniejsze jest nazewnictwo i konwencje strukturalne, które programista powinien zachować w swoim kodzie, a żaden kompilator ani parser nie sprawdzi go za niego. Jeśli będziesz przestrzegać jakichś reguł, z łatwością poznasz właściwą nazwę (nie pomyślisz, że nazwałeś zmienną checkOut lub CheckOut), a twój kod prawdopodobnie rozróżnia małe i wielkie litery i jest łatwiejszy do odczytania.

Nie należy używać CheckOut i CheckOut i Checkout oraz cHeCkOuT i CHECKOUT w tym samym znaczeniu. Uszkodzi to czytelność i sprawi, że zrozumienie tego rodzaju kodu będzie bardziej bolesne (ale są gorsze rzeczy, które można zrobić, aby zniszczyć czytelność kodu).

Jeśli zastosujesz jakieś reguły, zobaczysz na pierwszy rzut oka:

CheckOut.getInstance () - jest to metoda statyczna klasy o nazwie checkOut.calculate () - jest to metoda obiektu przechowywanego w zmiennej lub polu publicznym o nazwie _checkOut.calculate () - jest to metoda obiektu przechowywanego w prywatnym polu o nazwie CHECKOUT - jest to końcowe pole / zmienna statyczna lub stała

bez sprawdzania niektórych innych plików lub części pliku. Przyspiesza odczytywanie kodu.

Widzę wielu programistów stosujących podobne reguły - w językach, których często używam: Java, PHP, Action Script, JavaScript, C ++.

W rzadkich przypadkach można się rozgniewać na brak rozróżniania wielkości liter - na przykład, gdy chcemy użyć CheckOut dla nazwy klasy i CheckOut dla zmiennej i nie można tego zrobić, ponieważ koliduje ze sobą. Jest to jednak problem programisty używanego do rozróżniania wielkości liter i używania go w konwencjach nazewnictwa. Można mieć reguły ze standardowymi prefiksami lub postfiksami w języku bez rozróżniania wielkości liter (nie programuję w VB, ale wiem, że wielu programistów VB ma tego rodzaju konwencje nazewnictwa).

W kilku słowach: Widzę lepiej rozróżnianie wielkości liter (tylko w przypadku języków zorientowanych obiektowo), ponieważ większość programistów korzysta z języków rozróżniających wielkość liter, a większość z nich stosuje konwencje nazewnictwa oparte na rozróżnianiu wielkości liter, więc chcieliby, aby język był wrażliwy na wielkość liter, aby były w stanie trzymać się swoich zasad bez żadnych modyfikacji. Ale jest to raczej argument religijny - nie obiektywny (nie oparty na prawdziwych wadach lub dobrych stronach wrażliwości na wielkość liter) - ponieważ nie widzę żadnego, jeśli chodzi o dobrego programistę, jeśli chodzi o bAd DeVeLoPeR, można stworzyć koszmarny kod nawet gdy jest rozróżniana wielkość liter, więc nie jest to duża różnica).


1

W językach programowania nie jest rozróżniana wielkość liter.

Głównym powodem, dla którego w tak wielu językach rozróżniana jest wielkość liter, jest po prostu kultowy projekt języka: „C zrobił to w ten sposób, a C jest niezwykle popularny, więc musi mieć rację”. I podobnie jak w wielu innych sprawach, C popełnił ten błąd w sposób oczywisty.

Jest to właściwie część filozofii jazdy opartej na C i UNIX: jeśli masz wybór między złym rozwiązaniem, które jest łatwe do wdrożenia, a dobrym rozwiązaniem, które jest trudniejsze do wdrożenia, wybierz złe rozwiązanie i zrzuć ciężar pracy na swój bałagan na użytkownik. Może to zabrzmieć jak snark, ale to absolutna prawda. Jest znany jako zasada „gorsze jest lepsze” i był bezpośrednio odpowiedzialny za szkody warte miliardy dolarów w ciągu ostatnich kilku dziesięcioleci ze względu na C i C ++, dzięki czemu pisanie błędnego i niepewnego oprogramowania jest zbyt łatwe.

Uczynienie języka niewrażliwym na wielkość liter jest zdecydowanie łatwiejsze; nie potrzebujesz tabel leksykalnych, parsera i symboli, aby wykonać dodatkową pracę, aby upewnić się, że wszystko pasuje w sposób bez rozróżniania wielkości liter. Ale to także zły pomysł z dwóch powodów:

  • Po pierwsze, szczególnie jeśli budujesz język skryptowy, prostą literówkę, w której nazywasz coś „myObject” w jednym miejscu, a „MyObject” w innym, gdzie oczywiście odnosisz się do tego samego obiektu, ale po prostu trochę nie zgadzasz się z wielkimi literami , nie zmienia się w błąd czasu wykonywania. (Jest to niesławne jako główny problem w językach skryptowych, które źle to rozumieją, takich jak Python).
  • Po drugie, brak rozróżniania wielkości liter oznacza, że ​​nie można nadużywać rozróżniania wielkości liter, aby to samo słowo odnosiło się do dwóch różnych rzeczy w tym samym zakresie po prostu przez zmianę wielkich liter. Jeśli kiedykolwiek musiałeś pracować z kodem Windows w środowisku C i natrafić na takie brzydkie deklaracje jak HWND hwnd;, będziesz dokładnie wiedział, o czym mówię. Ludzie, którzy tak piszą, powinni zostać zabrani i zastrzeleni, a uczynienie języka niewrażliwym na wielkość liter zapobiega przedostawaniu się nadużyć do rozróżniania wielkości liter w kodzie.

Zrób więc dodatkowy wysiłek, aby zrobić to dobrze. Powstały kod będzie czystszy, łatwiejszy do odczytania, mniej błędów i sprawi, że użytkownicy będą bardziej produktywni, i czy nie jest to ostateczny cel jakiegokolwiek języka programowania?


Języki programowania powinny mieć zakres leksykalny, aby wychwytywać tego typu błędy przed czasem wykonywania (nawet jeśli są one wysoce dynamiczne). Common Lisp jest językiem wysoce dynamicznym, ale kompilatory mówią nam, kiedy użyliśmy zmiennej, która nie ma powiązania leksykalnego i nie została globalnie zdefiniowana jako zmienna dynamiczna. Nie możesz polegać na tym, że nie rozróżnia się wielkości liter, ponieważ chcesz wyłapać wszystkie literówki, nie tylko te, które zawierają wielkość liter.
Kaz.

Nie mam nic przeciwko HWND hwnd;. Jest to przykład, w którym rozróżnianie wielkości liter działa dobrze. Konwencja typu „Indian Hill” typu „All Cap” jest jednak głupia. hwnd_t hwndjest znacznie lepszy. Podejrzewam, że to wszystko z powodu FILE. Dawno Wersja 6 Unix miał w swoim pliku nagłówka I / O biblioteki to: #define FILE struct _iobuf. Było to wielkimi literami, ponieważ było to makro. Kiedy stał się typem pisma w ANSI C, pisownia wszystkich wielkich liter została zachowana. I myślę, że naśladując to, wymyślono konwencję ALL_CAPS_TYPE i skodyfikowano ją w „Indian Hill Style Guide Bell Lab” (oryginalny!)
Kaz.

Jeśli teraz przejrzysz Google „Indian Hill Style Guide”, znajdziesz głównie odniesienia do dokumentu Bell Labs z 1990 r., W którym całkowicie żałuje się wszystkich nazw maszynopisów: bez śladu takiej rekomendacji. Ale oryginalna wersja zalecała takie rzeczy typedef struct node *NODE. Jestem pewien, że właśnie tam Microsoft musiał to zauważyć. Więc obwiniaj Bell Labs HWND.
Kaz.

1

Nie mogę uwierzyć, że ktoś powiedział: „rozróżnianie wielkości liter ułatwia czytanie kodu”.

Z pewnością nie! Spojrzałem przez ramię kolegi na zmienne o nazwie Firma i firma (zmienna publiczna Firma, dopasowana prywatna firma zmienna), a jego wybór czcionki i koloru sprawia, że ​​niezwykle trudno jest odróżnić te dwa - nawet gdy są obok siebie.

Prawidłowe zdanie powinno brzmieć: „Mieszane wielkości liter ułatwiają czytanie kodu”. To o wiele bardziej oczywista prawda - np. Zmienne o nazwie CompanyName i CompanyAddress zamiast nazwy firmy. Ale żaden język, który znam, powoduje, że używasz tylko nazw zmiennych małych liter.

Najbardziej szaloną konwencją, jaką znam, jest ta „wielka, publiczna, mała prywatna”. Prosi tylko o kłopoty!

Moje podejście do błędów jest „lepsze, aby coś zawiodło głośno i tak szybko, jak to możliwe, niż cicho zawiodło, ale wydaje się, że odnosi sukces”. I nie ma wcześniejszego czasu niż kompilacja.

Jeśli omyłkowo użyjesz zmiennej małej litery, gdy chciałeś użyć wielkich liter, często kompiluje się, jeśli odwołujesz się do niej w tej samej klasie . W ten sposób możesz odnieść sukces zarówno w czasie kompilacji, jak i w czasie wykonywania, ale subtelnie postępujesz niewłaściwie i być może długo go nie wykryjesz. Kiedy wykryjesz, że coś jest nie tak

Znacznie lepiej zastosować konwencję, w której zmienna prywatna ma przyrostek - np. Zmienna publiczna firmy, zmienna prywatna CompanyP. Nikt nie zamierza przypadkowo pomieszać tych dwóch i pojawiają się razem w inteligencji.

Kontrastuje to z zastrzeżeniem, że ludzie muszą zgodzić się na węgierską notację, w której prefiksowana zmienna prywatna pCompany nie pojawiłaby się w dobrym miejscu w intellisesne.

Ta konwencja ma wszystkie zalety strasznej konwencji wielkich / małych liter i nie ma żadnych jej wad.

Fakt, że ludzie odczuwają potrzebę odwoływania się do rozróżniania wielkości liter w celu rozróżnienia zmiennych, pokazuje moim zdaniem zarówno brak wyobraźni, jak i brak zdrowego rozsądku. Lub, niestety, ludzkie owce lubią przestrzegać konwencji, ponieważ „zawsze tak było”.

Spraw, aby rzeczy, z którymi pracujesz, były wyraźnie i wyraźnie różne, nawet jeśli są ze sobą powiązane !!


1
Dobra, tak companyName == companyname. Wydaje się to rozsądne, ale jak radzisz sobie z lokalizacjami? Czy kompilowanie programu w różnych częściach świata spowoduje inną semantykę, tak jak w PHP? Czy będziesz całkowicie anglo-centryczny i będzie obsługiwał tylko zestaw do wydruku ASCII w identyfikatorach? Niewrażliwość na wielkość liter jest bardzo złożona i zapewnia bardzo mały dodatkowy zysk.
Phoshi

0

Nie powinieneś wprowadzać rozróżniania wielkości liter bez bardzo dobrego powodu. Na przykład poradzenie sobie z porównaniem wielkości liter w Unicode może być suką. Wrażliwość na wielkość liter (lub jej brak) w starszych językach jest nieistotna, ponieważ ich potrzeby były bardzo różne.

Programiści w tej erze oczekują rozróżniania wielkości liter.


1
Porównywanie przypadków nie jest takie trudne. Po prostu rozłóż swoje identyfikatory. É = E '= e' = é. Pamiętaj, że nadal można wybrać , które przypadek rządzi do naśladowania, a angielski jest rozsądnym wyborem. (z pewnością, jeśli twoje słowa kluczowe są również w języku angielskim)
MSalters

2
Tak, są „takie trudne” w całej przestrzeni Unicode.
Kaz.

1
„Programiści w tej erze oczekują rozróżniania wielkości liter”? Tylko jeśli cierpią na syndrom sztokholmski, ponieważ zbyt długo pracowali z rodziną C.
Mason Wheeler,

Cóż, rodzina C stanowi tylko bardzo dużą część języków i kodu. Poza tym myślę, że to dobrze, a twój komentarz nie sugeruje powodu, dla którego tak nie jest.
DeadMG

0

Rozróżnianie wielkości liter sprawia, że ​​kod jest bardziej czytelny, a programowanie łatwiejsze.

  • Ludziom łatwiej jest odczytać właściwe użycie mieszanej wielkości liter .

  • Pozwala / zachęca CamelCase, aby to samo słowo z różną wielkością liter mogło odnosić się do pokrewnych rzeczy: Car car; W ten sposób nazwana zmienna carjest tworzona typu Car.

  • ALL_CAPS_WITH_UNDERSCORES wskazuje stałe zgodnie z konwencją w wielu językach

  • all_lower_with_underscores może być użyte dla zmiennych składowych lub czegoś innego.

  • Wszystkie nowoczesne narzędzia programistyczne (kontrola źródła, edytory, diff, grep itp.) Są zaprojektowane z myślą o rozróżnianiu wielkości liter. Na zawsze będziesz mieć problemy z narzędziami, które programiści przyjmują za pewnik, jeśli utworzysz język bez rozróżniania wielkości liter.

  • Jeśli język zostanie zinterpretowany, może wystąpić negatywna konsekwencja w analizie kodu bez rozróżniania wielkości liter.

  • Co z postaciami nieanglojęzycznymi? Czy teraz decydujesz się nigdy nie obsługiwać języków koptyjskich, chińskich i hindi? Zdecydowanie sugeruję, aby ustawić domyślny język na UTF-8, który obsługuje niektóre języki, w których występują znaki bez odpowiednika wielkich lub małych liter. Nie użyjesz tych znaków w słowach kluczowych, ale kiedy zaczniesz wyłączać rozróżnianie wielkości liter w różnych narzędziach (na przykład, aby znaleźć rzeczy w plikach), napotkasz surrealistyczne i prawdopodobnie nieprzyjemne doświadczenia.

Jaka jest korzyść? Wspomniane 3 języki pochodzą z lat 70. lub wcześniejszych. Nie robi tego żaden współczesny język.

Z drugiej strony wszystko, co naprawdę uszczęśliwia użytkownika końcowego, daje światu trochę światła. Jeśli naprawdę wpłynie to na zadowolenie użytkowników, musisz to zrobić.

Jeśli chcesz, aby użytkownicy końcowi byli naprawdę prostymi użytkownikami, możesz zrobić coś więcej niż rozróżnianie wielkości liter / niewrażliwość - spójrz na Scratch ! Kilka mniej kreskówkowych kotów i bardziej przyjazne dla biznesu kolory, a ty znasz najbardziej przyjazny język, jaki kiedykolwiek widziałem - i nie musisz nic pisać! Tylko myśl.


1
Myślę, że chciałeś powiedzieć „nieuwzględnianie wielkości liter to koszmar”. Japończycy mają skrzynkę: hiragana i katakana są swego rodzaju różnymi skrzynkami. Podobnie jak A i a są w pewnym sensie „takie same”, podobnie jak あ i ア. Katakana jest czasami używana do podkreślenia, podobnie wielkie litery w językach, które używają alfabetu łacińskiego. Nie trzeba dodawać, że idiotyzmem byłoby traktowanie hiragany i katakany tak samo w przypadku identyfikatorów języka programowania.
Kaz

Dzięki - to wzbogaca! Po prostu posprzątałem swój post.
GlenPeterson

1
Car car;jest jednym z najlepszych argumentów przeciwko rozróżnianiu wielkości liter: jest brzydka, a jeśli twój język nie rozróżnia wielkości liter, nie możesz w ten sposób nadużywać rozróżniania wielkości liter.
Mason Wheeler,

1
Czy jest Car myCar;o wiele lepiej?
GlenPeterson

@Mason Wheeler: Jeśli ograniczymy nasze konstrukcje językowe do tych, których nie możemy nadużywać, nie będziemy w stanie wiele zrobić, prawda? Moja rada dla osób nadużywających rozróżniania wielkości liter brzmi „nie”.
David Thornley,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.