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ł?
a-zA-Z
,0-9
(z wyjątkiem na początku) i_
.Odpowiedzi:
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.
źródło
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
keyword
iKeyword
w swoim języku, a ta różnica jest znacząca dla użytkownika? W przypadku języka skryptowego powiedziałbym, że odpowiedź brzmi „nie”.źródło
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 olcuc
w 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
,FOO
iFoo
wszyscy 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ść.źródło
foo
iFoo
powinny być traktowane jako synonimy lub odrębne. Bez takiej deklaracji jest to błąd dla obu z nich. A ponieważ deklaracja się nie rozszerzaFOO
,FOO
nadal jest zabroniona; należy go dodać.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ądaObject 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ę.
źródło
"double quotes"
(lub[brackets]
w MS SQL) w SQL,[brackets]
w VB.net i@atsign
w C #.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 .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.
źródło
Czy potrafisz deklarować zmienne w locie? Jeśli tak, sprzeciwiam się rozróżnianiu wielkości liter, ponieważ śledzenie błędu spowodowanego przez
w przeciwieństwie do
niepotrzebnie prosi o czas debugowania, gdy równoważenie dwóch instrukcji ułatwia życie.
źródło
a
iA
powinien 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 ...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ą.
źródło
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ł).
źródło
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).
źródło
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:
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?
źródło
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 hwnd
jest znacznie lepszy. Podejrzewam, że to wszystko z powoduFILE
. 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!)typedef struct node *NODE
. Jestem pewien, że właśnie tam Microsoft musiał to zauważyć. Więc obwiniaj Bell LabsHWND
.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 !!
źródło
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.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.
źródło
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 zmiennacar
jest tworzona typuCar
.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.
źródło
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.Car myCar;
o wiele lepiej?