Celowe błędy ortograficzne w celu uniknięcia zarezerwowanych słów

45

Często widzę kod, który zawiera umyślne błędy pisowni popularnych słów, które na lepsze lub gorsze stały się słowami zastrzeżonymi:

  • klasslub clazzna zajęcia :Class clazz = ThisClass.class
  • kountdo zliczenia w SQL:count(*) AS kount

Osobiście uważam, że zmniejsza to czytelność. W mojej własnej praktyce nie znalazłem zbyt wielu przypadków, w których nie można byłoby użyć lepszego imienia - itemClasslub recordTotal.

Przykład z JavaDocs dla klasy pokazuje to w parametrach:

 public <U> Class<? extends U> asSubclass(Class<U> clazz)

Czy pokazuje to uzasadniony przypadek użycia?

Nicole
źródło
9
Dla przypomnienia: w Pythonie, clsto wspólna (w rzeczywistości jedna idiomatyczna) nazwa zmiennych / argumentów zawierających rzeczywiste klasy (te, które deklarujesz classsłowem kluczowym i których wszystko jest instancją).
14
Nie lubisz typedef char ínt?
Jeff
14
@muntoo Masz rację. Dostaję również błędy kompilatora dla iñt. Idzie mój plan dominacji nad światem.
Jeff
1
Złamałem tę zasadę ... i teraz czuję wstyd.
jmq
3
Nie rób tego Mogę szczerze powiedzieć, że nigdy wcześniej tego nie widziałem, a gdybym to zrobił, natychmiast zmieniłbym jego nazwę. Po prostu skrócić, jeśli mają używać non-opisową nazwę zmiennej ( Class c).
Cody Gray

Odpowiedzi:

63

IMHO, to bardzo zły pomysł. Zastrzeżone słowa są zastrzeżone z jakiegoś powodu, a wykonanie tego zmniejsza czytelność.

Całkowicie zgadzam się również z twoją drugą kwestią. Nazwanie zmiennej class, nawet jeśli możesz to zrobić, byłoby równie złe, jak nazywanie jej tmplub a. Jakiej klasy? Klasa czego? Nazwy powinny być opisowe.

Dima
źródło
15
„Zarezerwowane słowa są zastrzeżone z jakiegoś powodu” <- To. (Co, jak na ironię, jest zastrzeżone).
trycatch
16
+1, ponieważ masz rację. Ale jeśli piszesz oprogramowanie do planowania zajęć lub coś w tym stylu, klasa może być prawidłową zmienną lub nazwą klasy ...
CaffGeek
8
Meh „ Zarezerwowane słowa są zastrzeżone z jakiegoś powodu ”, co oznacza, że ​​projektanci języków są leniwi. Istnieje wiele wyrafinowanych języków, w których słowa są zarezerwowane tylko w określonych miejscach, w których są używane. Ale Ritchie zapoczątkował ten trend, gdy potrzebował lekkiego kompilatora dla języka C, i większość projektantów języków nauczyła się go stamtąd.
Ross Patterson
14
nie Ross, to dlatego, że programiści (i ogólnie czytelnicy) oczekują, że rzeczy będą miały względnie jednoznaczne znaczenie (dlatego nauka języków obcych jest często tak trudna, wszystkie rzeczy mają podwójne znaczenie lub różnią się od języka, w którym się wychowałeś w dzieciństwie, gdzie nigdy nie zauważasz tych dwuznaczności, ponieważ są one częścią twojego dziedzictwa kulturowego).
jwenting
3
@AlexanderMorou Nie, i żaden z nich nie ma większości projektantów języków, zaczynają od projektu innej osoby. Ale spójrz na Algol, Fortran, PL / I, Rexx i inne języki nie oparte na C, a zobaczysz, że gramatyki bez słów zastrzeżonych są z pewnością możliwe, tylko trudniejsze. Ritchie miał dobry powód - ludzie z Uniksa uważali, że każde naciśnięcie klawisza ma znaczenie, a na PDP-11 każdy cykl procesora ma znaczenie. Dzisiaj? Nie tak bardzo.
Ross Patterson
21

Przewodnik po stylach Pythona wyraźnie wskazuje ten problem i sugeruje:

Jeśli twoja publiczna nazwa atrybutu koliduje z zarezerwowanym słowem kluczowym, dodaj do nazwy atrybutu pojedynczy końcowy znak podkreślenia. Jest to lepsze niż skrót lub zepsuta pisownia.

To wydaje się być całkiem dobrą ogólną zasadą, zakładając, że nie koliduje z semantyką określonego języka.

Ryan
źródło
7
Wydaje mi się, że to kiepska rada przewodnika po stylu. Jeśli nazwa atrybutu jest tak bliska słowu kluczowemu, powinieneś znaleźć lepszą nazwę. Samo umieszczenie podkreślenia na końcu nie dodaje żadnego znaczenia i sprawia, że ​​może pomylić następnego faceta, który czyta kod.
Wayne Johnston
18
@Wayne: Jak nazwiesz operację związkową w strukturze znajdowania związku, gdy unionjest słowem kluczowym (jak w C)? Chcesz to nazwać footylko dlatego, że nie powinno to wyglądać union?
Fred Foo,
OTOH, clsto standardowa nazwa argumentu dla metody klasy. Również na przykład w Django obiekty mają .idatrybut, który oczywiście powoduje konflikt z idwbudowaną funkcją.
vartec
1
@GoloRoden Nigdy nie słyszałem, żeby ktokolwiek powiedział, że „łączyli” dwa zestawy podczas obliczania związku. To po prostu nie jest część żargonu. „Scalenie” byłoby lepsze, ale mergemetoda nadal wymagałaby dokumentacji wyraźnie stwierdzającej, że implementuje unię i została przemianowana ze względów czysto technicznych.
Fred Foo,
2
@GoloRoden Według Merriam-Webster nie jest to czasownik, ale zobacz tę odpowiedź .
maaartinus
18

Zapach kodowy.

string stringVariable = "";

Powyższy kod nie mówi mi nic o przeznaczeniu zmiennych.

class Klass

Taki sam problem

string UserNameString = "bmackey"

Powyższy kod nie powinien wymagać ciągów słów kluczowych dołączanych do nazwy zmiennej. Jeśli musisz zidentyfikować typy według nazwy zmiennej, kod jest za długi. Refaktor kondensacyjny.

P.Brian.Mackey
źródło
Nic ci nie mówi, ponieważ nie jest to „kod”, to deklaracja zmiennej izolowanej. „Klasa” lub „klasa” może równie dobrze powiedzieć ci wszystko, co musisz wiedzieć. Na przykład metoda ogólna może otrzymać Class<T>parametr, co może mieć sens. Nie zgadzam się więc, że to zapach kodu.
Andres F.,
5

Osobiście uważam, że jest to całkowicie poprawna opcja dla twojego stylu kodu.

Są to słowa zastrzeżone, więc kompilator nie musi decydować, czy masz na myśli mechanikę języka, czy swoją zmienną. Mając to na uwadze, oznacza to, że oczekują , że ludzie będą potrzebować zmiennej, takiej jak słowo zastrzeżone.

Przeglądając źródło w pakiecie z JDK 1.6 R21, znajduję 917 wystąpień „clazz”. Najwyraźniej myśleli, że to akceptowalny styl.

Co czuje Twój zespół? Jeśli uważasz, że to źle, ale pozostałych 9 facetów w twoim zespole uważa, że ​​to dobrze, musisz ugryźć kulę i zaakceptować ją. Tak długo, jak istnieje komunikacja na temat tego, co jest w porządku, a co nie, a ty poruszasz problemy, które widzisz tak, jak je widzisz, powinno być w porządku.

Twoje zdanie na temat stylu kodu jest ważniejsze niż moja opinia lub ktokolwiek inny w tym poście . Dotyczy to tego i wszelkich innych decyzji dotyczących stylu kodu.

corsiKa
źródło
1
Racja, ale ostatecznie twój zespół się zmieni. Wiele lat później pojawi się jakiś biedak, który patrzy na twój kod pełen klas i klauzur i mówi „WTF!”.
MrFox,
4
Jeśli używasz obu klassi clazzto źle. Musisz być konsekwentny, aby musieli się tego nauczyć tylko raz. Idealnie jest to również określone w wytycznych dotyczących stylu drużyn, więc nie jest to żadną niespodzianką.
corsiKa
Kod jest napisany nie tylko dla ludzi w twoim zespole, ale dla reszty świata do przeczytania. Kiedy twój zespół jedzie autobusem, który przejeżdża przez urwisko, ktoś inny może zacząć czytać kod. Używaj nazw, które całkowicie i zwięźle opisują, czym jest zmienna, a nie jak jest reprezentowana.
Rob K
1
Nie, po prostu nie. Wasz zespół ma znacznie większe szanse na powolną rotację członków z czasem. Możesz zaplanować, że jedna osoba zostanie potrącona przez autobus, ale nie możesz zaplanować, że cały zespół zostanie potrącony przez autobus. Większość kodu jest napisana dla kilkunastu osób, które kiedykolwiek muszą go przeczytać, z czego połowa podczas przeglądania kodu.
corsiKa
4

Umyślne pisanie w celu uniknięcia słów zastrzeżonych to zły pomysł.

  • Błędy ortograficzne są trudne do odróżnienia od poprawnej pisowni, dlatego utrudniają odczytanie kodu.

  • Błędy ortograficzne są trudne do zapamiętania, dlatego kilka niespójnych błędów ortograficznych może konkurować w kodzie, co sprawia, że ​​kod jest trudniejszy do napisania i trudniejszy do odczytania.

  • Słowa zastrzeżone odnoszą się do języka używanego do rozwiązania problemu, a nie do samego problemu. Nazwa zmiennej powinna wskazywać na koncepcję związaną z problemem.

Dlatego lepiej jest wybrać alternatywną, opisową nazwę lub, jeśli nie ma zadowalającej alternatywy, zakwalifikować słowo zastrzeżone jak w:

public static Method findBenchmarkMethod(BenchmarkRecord benchmark) {
    Class<?> benchmarkedClass = ClassUtils.loadClass(benchmark.generatedClass());
    return findBenchmarkMethod(benchmarkedClass, benchmark.generatedMethod());
}
użytkownik40989
źródło
3

Class clazzpachnie jak „Nie zawracałem sobie głowy wymyśleniem dobrego imienia”. Zmienna zawsze coś reprezentuje, a dobre imię to opisuje. Nie wyobrażam sobie, że clazzna przykład w żadnych okolicznościach jest to najlepsza możliwa nazwa. Czy jest to odwołanie do klasy -> odwołanie do klasy, jest kopią obiektu klasy -> kopia_klasy, itp. Możliwe, że również upuszcza „klasę” i po prostu używa słowa opisowego, np.

java.lang.SecurityManager.checkMemberAccess(Class<?> clazz, int which)
Parameters
    clazz -- the class that reflection is to be performed on.

Tutaj clazz jest klasą docelową, na której ma zostać wykonane sprawdzenie, więc

checkMemberAccess(Class<?> target, int which)

znacznie lepiej opisałby, do czego służy ten parametr niż kiedykolwiek clazz.

hlovdal
źródło
IMHO nie jest lepsze, możesz nazwać to „classToBeAccessed” lub cokolwiek, ale każda bardziej opisowa nazwa po prostu pokazuje oczywiste. Lubię długie nazwiska tylko wtedy, gdy zawierają przydatne informacje.
maaartinus
1
classToBeAccessedto naprawdę dobre imię ( classToBeCheckedbyć może nawet lepsze).
hlovdal
1

Jeśli używają zastrzeżonej nazwy dla zmiennej, jest to źle nazwana zmienna. Nawet jeśli jest to legalna nazwa, na przykład Class for software classroom.

Źle nazwane zmienne są oznaką źle przemyślanego lub zwyczajnego kodu - strzeż się innych błędów w utrzymywanym oprogramowaniu.

czwartek
źródło
0

Uważam, że celowe błędy ortograficzne lub skróty są dobrym pomysłem, jeśli są stosowane ostrożnie i konsekwentnie .

Rozważ w Javie:

class X { public X() { } }
X x = new X();
x.getClass;  // Wha?  How does "get" help anything?
x.class;     // Best, but requires more lexer/parser work
x.klass;     // At least as good as getClass
x.clazz;     // Same

Miejsce, w którym można używać błędów ortograficznych, to miejsce, w którym słowo zastrzeżone jest zdecydowanie najlepszym słowem dla danego zadania. Istnieją dwa miejsca, w których nie można używać błędów ortograficznych, w których można ulec pokusie.

  1. Nie masz ochoty myśleć o dobrym nazwisku
  2. Chcesz tylko zmienną fikcyjną i nie potrzebuje ona opisowej nazwy

W pierwszym przypadku jest dość oczywiste, że lenistwo rzadko jest dobrą polityką do tworzenia wysokiej jakości kodu. W drugim przypadku wybierz naprawdę krótką zmienną. To właśnie robią matematycy cały czas, a programiści robią indeksy. Nie ma powodu ograniczać się do robienia tego dla indeksów, jeśli tak naprawdę jest to tylko zmienna fikcyjna:

boolean isMyName(String testName) { return myName.equals(testName); }
boolean isMyName(String s) { return myName.equals(s); }

Date nextMeeting(Klass klass) { return /* something */ }
Date nextMeeting(Klass k) { return /* something */ }

Nie tracisz nic z krótkimi nazwami zmiennych, gdy metoda lub struktura kodu mówi ci, co musi tam być.

Rex Kerr
źródło
2
Przepraszam, nie mogę się zgodzić. Jak dokładnie działa nextMeeting? Logika jest niejasna. Zmuszasz mnie do szukania definicji Klassa za każdym razem, gdy czytam twój kod, ponieważ nazwa nie ma znaczenia. Jeśli zamiast tego miałbyś nextMeeting (MeetingRoom meetingRoom), miałbym jedną definicję mniejszej klasy (klass? Clazz?) Do przeczytania, a tym samym byłbym bardziej produktywny. Kod jest czytany znacznie więcej niż napisany.
MrFox,
@suslik - nextMeeting(MeetingRoom r)jest dużo. Co meetingRoomcię tam prowadzi? Gdyby to było nextMeeting(int meetingRoom), rozumiem, ale moim celem jest użycie krótkich nazw zmiennych, gdy informacje są już dostępne z innych źródeł .
Rex Kerr
Mój post bardziej dotyczył istnienia Klassa w bazie kodu. Czasami zgadzam się z krótkimi nazwami zmiennych, ale jeśli twoje metody stają się długie, a ja muszę ciągle srcollować, aby upewnić się, że „r” jest MeetingRoom, to też nie jest świetne. Jestem ciekawy, co jest wadą MeetingRoom? Przestrzeń pozioma? Za długo pisać?
MrFox
@suslik - Tak, tracisz kontekst poziomy z długimi nazwami zmiennych. Długimi metodami gubisz kontekst pionowy, więc najlepiej jest ich unikać (ale zgadzam się, jeśli i tak to zrobisz, prawdopodobnie chcesz, aby nazwy zmiennych były lepszymi przypomnieniami). Klassbyła alternatywą, gdy było zarezerwowane słowo . Nie polecam używania błędów pisowni, gdy dostępna jest oryginalna pisownia!
Rex Kerr
0

Widziałem uzasadnione użycie Class klasspodczas refleksji w miejscu pracy z instancją Classklasy.

Mateusz
źródło
2
Pytanie nie dotyczy tego, czy istnieje przypadek, w którym masz instancję, ale czy powinieneś użyć tej pisowni lub bardziej opisowej nazwy, takiej jak userClasslub innej opcji.
Nicole
2
W takim przypadku wolałbym classInstancewięcej klass.
Konrad Morawski
2
@KonradMorawski: Ale wszystkie obiekty, z którymi pracujesz, są instancjami, więc classInstancesą dość zbędne. Co więcej, mogłem sobie wyobrazić coś takiego class klass; Object classInstance = klass.newInstance;.
maaartinus
0

Często widzę kod, który zawiera umyślne błędy pisowni popularnych słów, które na lepsze lub gorsze stały się słowami zastrzeżonymi:

klass lub clazz dla class: Class clazz = ThisClass.class

kount for count w SQL: count (*) AS kount

Osobiście uważam, że zmniejsza to czytelność. W mojej własnej praktyce nie znalazłem zbyt wielu przypadków, w których nie można byłoby użyć lepszej nazwy - itemClass lub recordTotal.

Jednak jest to tak powszechne, że nie mogę przestać się zastanawiać, czy jestem jedynym? Czy ktoś ma jakieś porady, a nawet lepsze, cytowane rekomendacje od szanowanych programistów dotyczące tej praktyki?

W przypadku zmiennych lokalnych i argumentów formalnych to po prostu nie ma znaczenia.

Każde imię jest w porządku, pod warunkiem, że nie jest celowo wprowadzające w błąd ani denerwujące. W twoim przykładzie:

public static Method findBenchmarkMethod(BenchmarkRecord benchmark) {
    Class<?> clazz = ClassUtils.loadClass(benchmark.generatedClass());
    return findBenchmarkMethod(clazz, benchmark.generatedMethod());
}

nie ma znaczenia, czy pojedyncza zmienna lokalna to „clazz”, „klass”, „cls” czy po prostu „c”. Prawdopodobnie po prostu wstawiłbym wyrażenie:

return findBenchmarkMethod(ClassUtils.loadClass(benchmark.generatedClass()),
                           benchmark.generatedMethod());

Długość nazwy zmiennej powinna być związana z zakresem zmiennej. W przypadku zmiennych lokalnych w krótkich metodach (i wszystkie powinny być krótkie), bardzo krótkie nazwy są w porządku.

Kevin Cline
źródło
twoja linia wygląda niepoprawnie ClassUtils.loadClass(benchmark.generatedClass())=> benchmark.generatedClass()- zgubiona ClassUtils.loadClasspo drodze
komara
0

Myślę, że błędy ortograficzne są zawsze złym pomysłem. To po prostu nie jest miłe dla czytelników. Zastanawiam się, czy coś mi umknęło, gdy zobaczyłem to słowo klass. (Czy mieli na myśli class, czy mieli na myśli pirata?) Przynajmniej dla mnie wszystkie pisowni, które rozpoznaję, są irytujące.

W bardzo niewielu przypadkach, gdy słowo zastrzeżone jest tak naprawdę jedyną znaczącą rzeczą znaną o zmiennej, użyłbym następujących alternatyw:

  • Jeśli jest to argument funkcji, użyj aClasszamiast class.

  • Jeśli jest to zmienna lokalna lub zmienna członkowska, użyj myClasszamiast class.

  • Jeśli jest to akcesor, użyj getClass()zamiast class().

Oczywiście dodany prefiks jest dość bezcelowy i dlatego powinien być zawsze używany jako ostateczność. Ale przynajmniej nie koliduje z parserem mentalnym czytelnika i jest to bezpieczny sposób na uniknięcie słów zastrzeżonych.

cmaster
źródło
0

Jedną z zalet kreatywnej pisowni jest lepsza zdolność wyszukiwania. Myślę, że o wiele łatwiej jest przeprowadzić pełne wyszukiwanie kodu dla unikalnych rzeczy, niż dla zwykłych słów, w których zbyt często można znaleźć wszystkie złe rzeczy i 1000 z nich. Jako przykład posiadałem kzpg.com. Google, teraz i zobaczysz tylko kilka trafień. Jest wyjątkowy i dlatego bardzo łatwo go znaleźć.

Ale w pewnym sensie myślę, że to pytanie dotyczy bardziej opinii niż treści. Osobiście dorastałem na Forth, gdzie chodziło o słowa i wiele z nich. Nauczył się bardzo kreatywny w oszczędzaniu palców. W końcu miałem około 640 000 znaków, mniej więcej w mojej bazie źródłowej. Dlatego krótkie słowa były ważne dla wykonania pracy.

Widok eliptyczny
źródło
Ten link jest teraz zepsuty.
Peter Mortensen