Навмисні помилки, щоб уникнути зарезервованих слів

Я часто бачу код, який включає навмисні написання загальних слів, які на краще чи гірше стали зарезервованими словами:

• klassабо clazzдля класу :Class clazz = ThisClass.class
• kountдля підрахунку в SQL:count(*) AS kount

Особисто я вважаю, що це зменшує читабельність. У власній практиці я не знайшов занадто багато випадків, коли кращого імені не можна було використовувати - itemClassабо recordTotal.

Приклад з JavaDocs for Class показує це в параметрах:

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

Чи показує це розумний випадок використання?

ІМХО, це дуже погана ідея. Зарезервовані слова зарезервовані з причини, і це робить зменшення читабельності.

Я також повністю згоден з вашим другим моментом. Іменування змінної class, навіть якщо ви могли це зробити, було б так само погано, як іменування її tmpабо a. Який клас? Клас чого? Назви повинні бути описовими.

Даний посібник із стилів Python конкретно вирішує цю проблему та пропонує:

Якщо ім’я вашого загальнодоступного атрибута стикається із зарезервованим ключовим словом, додайте до імені атрибута єдиний кінцевий підкреслення. Це краще, ніж абревіатура або зіпсований правопис.

Це здається досить хорошим загальним правилом, якщо припустити, що воно не суперечить семантиці певної мови.

Кодовий запах.

string stringVariable = "";

Наведений вище код нічого не каже мені про змінні, які планується використовувати.

class Klass

Та ж проблема

string UserNameString = "bmackey"

Наведений вище код не повинен вимагати рядка ключового слова, доданого до імені змінної. Якщо вам потрібно визначити типи за назвою змінної, ваш код занадто довгий. Конденсатор-рефактор.

Особисто я вважаю, що це абсолютно вірний варіант для вашого стилю коду.

Вони зарезервовані слова, тому компілятору не доведеться вирішувати, чи ви мали на увазі мову-механіку чи вашу змінну. Зважаючи на це, це означає, що вони очікують, що люди матимуть потребу в змінній, як зарезервоване слово.

Перебираючи джерело в комплекті з JDK 1.6 R21, я знаходжу 917 випадків "клазу". Мабуть, вони вважали це прийнятним стилем.

Як ваша команда ставиться до цього? Якщо ви вважаєте, що це погано, але інші 9 хлопців з вашої команди вважають, що це добре, то вам доведеться кусати кулю і прийняти її. Поки є повідомлення про те, що добре, а що ні, і ви ставите проблеми, які ви бачите так, як їх бачите, це повинно бути добре.

Те, як ваша команда ставиться до стилю коду, важливіше, ніж моя думка, чи хтось інший у цій публікації . Це стосується цього та будь-яких інших рішень у стилі коду, які ви можете мати.

Навмисне написання помилок, щоб уникнути зарезервованих слів, є поганою ідеєю.

• Неправильне написання важко відрізнити від правильного написання, тому вони ускладнюють читання коду.

• Важко запам’ятати написання помилок, тому декілька непослідовних правописів, можливо, змагатимуться в коді, що ускладнює запис і важче читати.

• Застережені слова відносяться до мови, яка використовується для вирішення проблеми, а не до самої проблеми. Ім'я змінної має вказувати на поняття, пов'язане з проблемою.

Тому краще вибрати альтернативну, описову назву або, якщо не існує задовольняючої альтернативи, кваліфікувати зарезервоване слово як:

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

Class clazzпахне на кшталт "я не потрудився спробувати придумати гарне ім'я". Змінна завжди щось представляє, і добре ім'я це описує. Я відмовляюся уявляти, що, clazzнаприклад, за будь-яких обставин є найкращим можливим ім'ям. Це посилання на клас -> class_reference, це копія об'єкта класу -> class_copy і т. Д. Можливо, також випадає "клас" і просто використовується описове слово, наприклад

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

Тут clazz - цільовий клас, на якому слід перевірити, так що

checkMemberAccess(Class<?> target, int which)

Набагато краще б описати, для чого використовується параметр, ніж завжди буде clazz.

Якщо вони використовують зарезервоване ім'я для змінної, це змінна назва з поганим іменем. Навіть якщо це законне ім'я, наприклад, Class для програмного забезпечення для аудиторії.

Неправильно названі змінні є ознакою погано продуманого або випадкового коду - остерігайтеся інших ґутчей у тій частині програмного забезпечення, яку ви підтримуєте.

Я вважаю, що навмисні написання помилок або скорочень є гарною ідеєю, якщо їх використовувати обережно і послідовно .

Розглянемо на Java:

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

Місце використання неправильних написань - це те, де зарезервоване слово - це найкраще слово для роботи. Існує два місця, щоб не використовувати неправильних написань, де вас можуть спокусити.

1. Вам не здається думати про хороше ім’я
2. Вам просто потрібна фіктивна змінна, і вона не потребує описової назви

У першому випадку цілком очевидно, що лінь рідко є доброю політикою створення коду якості. У другому випадку виберіть дійсно коротку змінну. Так роблять математики весь час, а програмісти - для індексів. Немає жодних причин обмежувати це робити індексами, якщо це дійсно лише фіктивна змінна:

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 */ }

Ви нічого не втрачаєте з короткими назвами змінних, коли метод або структура коду повідомляє вам, що там має бути.

Я бачив законні способи використання Class klassрефлексії, де ви дійсно працюєте з екземпляром Classкласу.

Я часто бачу код, який включає навмисні написання загальних слів, які на краще чи гірше стали зарезервованими словами:

klass або clazz для класу: Class clazz = ThisClass.class

kount для підрахунку в SQL: count (*) AS kount

Особисто я вважаю, що це зменшує читабельність. У власній практиці я не знайшов занадто багато випадків, коли не можна було використовувати кращу назву - itemClass або recordTotal.

Однак це так часто, що я не можу не задатися питанням, чи я єдиний? Хтось має поради чи ще краще, цитував рекомендації від шанованих програмістів щодо цієї практики?

Для локальних змінних та формальних аргументів це просто не має значення.

Будь-яке ім’я чудово, доки воно не буде навмисно вводити в оману чи дратує. У вашому прикладі:

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

не має значення, чи є єдиною локальною змінною "clazz" або "klass" або "cls" або просто "c". Я, мабуть, просто накреслив вираз:

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

Довжина імені змінної повинна бути пов'язана з областю змінної. Для локальних змінних у коротких методах (і всі вони повинні бути короткими) дуже короткі назви є чудовими.

Я думаю, що неправильно написані слова - це завжди погана ідея. Це просто не приємно вашим читачам. Мені, наприклад, було б цікаво, чи щось я пропустив, коли бачу слово klass. (Чи мали на увазі це class, чи вони мали на увазі пірата?) Принаймні, мені всі правописи, які я визнаю, дратують.

Для тих небагатьох випадків, коли зарезервоване слово справді є єдиним значущим, що відомо про змінну, я б використав такі альтернативи:

• Якщо це аргумент функції, використовуйте aClassзамість class.

• Якщо це локальна чи членська змінна, використовуйте myClassзамість class.

• Якщо це аксесуар, використовуйте getClass()замість class().

Звичайно, доданий префікс є досить безглуздим, і його слід використовувати лише в крайньому випадку. Але принаймні це не заважає розумовому аналізатору вашого читача, і це невдалий спосіб уникнути застережених слів.

Однією з переваг творчого написання є краща можливість пошуку. Я думаю, що набагато простіше зробити повний пошук коду унікальних речей, ніж звичайних слів, де занадто часто ви знайдете всі неправильні речі та 1000 їх. Як приклад, я використовував kzpg.com. Google це зараз, і ви побачите лише кілька звернень. Він унікальний і тому дуже досконалий.

Але я вважаю, що це питання є думкою більше, ніж сутністю. Я особисто виріс у Форті, де було все про слова, і їх багато. Один навчився бути дуже креативним, щоб врятувати пальці. Врешті-решт у мене було близько 640 000 символів, більш-менш у моїй джерельній базі. Таким чином, тримати слова короткими було важливо для роботи.