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

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?

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.

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.

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.

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.

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());
}

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.

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.

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

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

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.

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.

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.