Преднамеренные опечатки, чтобы избежать зарезервированных слов

45

Я часто вижу код, который включает преднамеренные опечатки общих слов, которые, к лучшему или худшему, стали зарезервированными словами:

  • klassили clazzдля класса :Class clazz = ThisClass.class
  • kountдля подсчета в SQL:count(*) AS kount

Лично я считаю, что это снижает читабельность. В моей собственной практике я не нашел слишком много случаев, когда нельзя было бы использовать лучшее имя - itemClassили recordTotal.

Пример из JavaDocs для класса показывает это в параметрах:

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

Это показывает разумный вариант использования?

Николь
источник
9
Для записи: В Python clsэто общее (на самом деле, идиоматическое) имя для переменных / аргументов, ограничивающих реальные классы (те, которые вы объявляете с помощью classключевого слова и у которых все является экземпляром).
14
Тебе не нравится typedef char ínt?
Джефф
14
@muntoo Ты прав. Я также получаю ошибки компилятора для iñt. Вот мой план мирового господства.
Джефф
1
Я нарушил это правило ... и теперь мне стыдно.
JMQ
3
Не делай этого. Я могу честно сказать, что я никогда не видел это раньше, и если бы я это сделал, я бы сразу переименовал это. Просто сокращайте, если вам нужно использовать неописательное имя переменной ( Class c).
Коди Грей

Ответы:

63

ИМХО, это очень плохая идея. Зарезервированные слова зарезервированы по причине, и это снижает читаемость.

Я также полностью согласен с вашим вторым пунктом. Назвать переменную class, даже если бы вы могли это сделать, было бы так же плохо, как назвать ее tmpили a. Что за класс? Класс чего? Имена должны быть описательными.

Дима
источник
15
«Зарезервированные слова зарезервированы по причине» <- Это. (Что, по иронии судьбы, зарезервировано.)
trycatch
16
+1 потому что ты прав. Но если вы пишете программное обеспечение для планирования занятий или что-то в этом роде, класс может быть допустимой переменной или именем класса ...
CaffGeek
8
Мех. « Зарезервированные слова зарезервированы по причине », которая заключается в том, что дизайнеры языка ленивы. Есть довольно много сложных языков, где слова зарезервированы только в определенных местах, где они используются. Но Ритчи начал эту тенденцию, когда ему понадобился легкий компилятор для C, и большинство языковых дизайнеров узнали об этом.
Росс Паттерсон
14
нет, Росс, это потому, что программисты (и читатели в целом) ожидают, что вещи будут иметь достаточно однозначное значение (именно поэтому изучение иностранных языков часто бывает настолько сложным, что все вещи имеют двойное значение или значение отличается от языка, который вы подняли в детстве, где вы никогда не замечаете эти двусмысленности, потому что они являются частью вашего культурного наследия).
С
3
@AlexanderMorou Нет, и у большинства из них нет языковых дизайнеров, они просто начинают с чужого дизайна. Но посмотрите на Algol, Fortran, PL / I, Rexx и другие языки, не основанные на C, и вы увидите, что грамматики без зарезервированных слов, безусловно, возможны, только сложнее. У Ричи была веская причина - люди из Unix чувствовали, что каждое нажатие клавиши имело значение, а на PDP-11 каждый цикл процессора имел значение. Сегодня? Не так много.
Росс Паттерсон
21

Руководство по стилю Python конкретно упоминает эту проблему и предлагает:

Если имя вашего общедоступного атрибута вступает в противоречие с зарезервированным ключевым словом, добавьте к его имени один завершающий символ подчеркивания. Это предпочтительнее аббревиатуры или искаженного написания.

Это кажется довольно хорошим общим правилом, если предположить, что оно не противоречит семантике конкретного языка.

Райан
источник
7
Я чувствую, что это действительно плохой совет от руководства по стилю. Если имя вашего атрибута так близко к ключевому слову, вы должны найти лучшее имя. Простое наклеивание подчеркивания на конце не добавляет никакого смысла и делает его способным запутать следующего парня, который читает код.
Уэйн Джонстон
18
@Wayne: Как вы собираетесь назвать операцию объединения в структуре поиска объединения, когда unionиспользуется ключевое слово (как в C)? Вы собираетесь назвать это fooтолько потому, что это не должно выглядеть union?
Фред Фу
OTOH, clsэто стандартное имя аргумента для метода класса. Также, например, в Django объекты имеют .idатрибут, который, конечно, конфликтует со idвстроенной функцией.
vartec
1
@GoloRoden Я никогда не слышал, чтобы кто-то говорил, что они «объединяют» два набора при вычислении объединения. Это просто не часть языка. «Слияние» было бы лучше, но mergeметод все равно нуждался бы в документации, явно заявляющей, что он реализует объединение и был переименован по чисто техническим причинам.
Фред Фу
2
@GoloRoden Согласно Merriam-Webster, это не глагол, но посмотрите этот ответ .
Maaartinus
18

Код запаха.

string stringVariable = "";

Приведенный выше код ничего не говорит мне о предполагаемом использовании переменных.

class Klass

Та же проблема

string UserNameString = "bmackey"

Приведенный выше код не должен требовать добавления строки ключевого слова к имени переменной. Если вам нужно идентифицировать типы по имени переменной, ваш код слишком длинный. Уплотнить-рефакторинг.

P.Brian.Mackey
источник
Он ничего не говорит вам, потому что это не «код», это объявление изолированной переменной. «Класс» или «класс» может очень хорошо рассказать вам все, что вам нужно знать. Например, универсальный метод может получить Class<T>параметр, и это может иметь смысл. Так что я не согласен с тем, что это запах кода.
Андрес Ф.
5

Лично я думаю, что это совершенно правильный вариант для вашего стиля кода.

Это зарезервированные слова, поэтому компилятору не нужно решать, имеете ли вы в виду механику языка или свою переменную. Имея это в виду, это означает, что они ожидают, что люди будут нуждаться в переменной, такой как зарезервированное слово.

Просматривая исходный код в комплекте с JDK 1.6 R21, я обнаружил 917 случаев появления «clazz». Видимо, они думали, что это приемлемый стиль.

Как ваша команда относится к этому? Если вы думаете, что это плохо, но остальные 9 парней в вашей команде думают, что это хорошо, тогда вы должны укусить пулю и принять это. Пока есть сообщение о том, что хорошо, а что нет, и вы поднимаете вопросы, которые видите, как видите их, все должно быть хорошо.

То, как ваша команда относится к стилю кода, важнее, чем мое мнение или кто-либо еще в этом посте . Это относится и к любым другим решениям в отношении стиля кода, которые могут у вас возникнуть.

corsiKa
источник
1
Правильно, но со временем ваша команда изменится. Через много лет в будущем какой-нибудь бедняга будет смотреть на твой код, полный классов и слов, и говорить «WTF!».
MrFox
4
Если вы используете оба, klassи clazzэто плохо. Вы должны быть последовательными, чтобы они могли выучить это только один раз. И в идеале это прописано в рекомендациях по стилю команд, так что это неудивительно.
CorsiKa
Код написан не только для людей в вашей команде, но и для остального мира, чтобы читать. Когда ваша команда находится в автобусе, идущем по обрыву, кто-то другой начинает читать код. Используйте имена, которые полностью и кратко описывают, что такое переменная, а не то, как она представлена.
Роб K
1
Нет, просто нет. У вашей команды гораздо больше шансов медленно менять членов со временем. Вы можете планировать, что один человек будет сбит автобусом, но вы не можете планировать, что вся ваша команда будет сбита автобусом. Большая часть кода написана примерно для дюжины людей, когда-либо нуждающихся в ее прочтении, половина из них во время проверки кода.
CorsiKa
4

Преднамеренные ошибки в написании слов, чтобы избежать зарезервированных слов - плохая идея.

  • Ошибочные написания трудно отличить от правильного написания, поэтому они затрудняют чтение кода.

  • Ошибочные орфографические ошибки трудно запомнить, так что несколько несовместимых орфографических ошибок могут конкурировать внутри кода, что делает код труднее писать и труднее читать.

  • Зарезервированные слова относятся к языку, используемому для решения проблемы, а не к самой проблеме. Имя переменной должно указывать на концепцию, связанную с проблемой.

Поэтому лучше выбрать альтернативное описательное имя или, если не существует удовлетворительной альтернативы, квалифицировать зарезервированное слово как в:

public static Method findBenchmarkMethod(BenchmarkRecord benchmark) {
    Class<?> benchmarkedClass = ClassUtils.loadClass(benchmark.generatedClass());
    return findBenchmarkMethod(benchmarkedClass, benchmark.generatedMethod());
}
user40989
источник
3

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)

будет гораздо лучше описывать, для чего используется параметр, чем когда-либо Клац.

hlovdal
источник
ИМХО, это не лучше, вы можете назвать его «classToBeAccessed» или как угодно, но любое более описательное имя просто показывает очевидное. Мне нравятся длинные имена, только если они предоставляют полезную информацию.
Maaartinus
1
classToBeAccessedдействительно хорошее имя ( classToBeCheckedвозможно, будет даже лучше).
Хловдал
1

Если они используют зарезервированное имя для переменной, это переменная с плохим именем. Даже если это законное имя, например, Class для программного обеспечения в классе.

Переменные с плохим именем являются признаком плохо продуманного или случайного кода - остерегайтесь других ошибок в поддерживаемой вами части программного обеспечения.

thursdaysgeek
источник
0

Я думаю, что преднамеренные опечатки или сокращения являются хорошей идеей, если их использовать осторожно и последовательно .

Рассмотрим в 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 */ }

Вы ничего не потеряете с короткими именами переменных, когда метод или структура кода говорит вам, что должно быть там.

Рекс Керр
источник
2
Извините, я не могу согласиться. Как работает nextMeeting? Логика неясна. Вы заставляете меня искать определение Klass каждый раз, когда я читаю ваш код, потому что имя бессмысленно. Если бы вместо этого у вас было nextMeeting (MeetingRoom meetingRoom), у меня было бы одно определение класса (klass? Clazz?) Для чтения, и, следовательно, более продуктивным. Код читается намного больше, чем написано.
MrFox
@suslik - nextMeeting(MeetingRoom r)это много. Что meetingRoomтебя там привлекает? Если nextMeeting(int meetingRoom)бы я понял, я бы хотел использовать короткие имена переменных, когда информация уже доступна из других источников .
Рекс Керр
Мой пост был больше о существовании Klass в кодовой базе. Я иногда согласен с короткими именами переменных, но если ваши методы становятся длиннее, а вы должны продолжать проверять, чтобы убедиться, что "r" - это MeetingRoom, то это тоже не здорово. Мне любопытно, какова обратная сторона MeetingRoom? Горизонтальное пространство? Слишком долго печатать?
MrFox
@suslik - Да, вы теряете горизонтальный контекст с длинными именами переменных. Вы теряете вертикальный контекст с помощью длинных методов, поэтому лучше всего избегать их (но я согласен, если вы все равно это сделаете, вы, вероятно, захотите, чтобы имена ваших переменных были лучшими напоминаниями). Klassбыла альтернатива, когда было зарезервированное слово . Я не рекомендую использовать орфографические ошибки, когда доступно оригинальное написание!
Рекс Керр
0

Я видел законное использование Class klassпри отражении, когда вы действительно работаете с экземпляром Classкласса.

Мэтью
источник
2
Вопрос не в том, есть ли какой-либо случай, когда у вас есть экземпляр, а в том, следует ли вам использовать это правописание или более описательное имя, например, userClassили какой-либо другой вариант.
Николь
2
В таком случае я предпочел бы classInstanceзакончить klass.
Конрад Моравский
2
@KonradMorawski: Но все объекты, с которыми вы работаете, являются экземплярами, так что classInstanceэто довольно избыточно. Более того, я мог представить что-то подобное class klass; Object classInstance = klass.newInstance;.
Maaartinus
0

Я часто вижу код, который включает преднамеренные опечатки общих слов, которые, к лучшему или худшему, стали зарезервированными словами:

Класс или класс для класса: Класс класс = 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());

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

Кевин Клайн
источник
Ваш встроенный выглядит неправильно ClassUtils.loadClass(benchmark.generatedClass())=> benchmark.generatedClass()- потерян ClassUtils.loadClassпо пути
комнат
0

Я думаю, что орфографические ошибки всегда плохая идея. Это просто не приятно для ваших читателей. Мне, например, было бы интересно, если я что-то пропустил, когда я вижу слово klass. (Они classимели в виду , или они имели в виду пирата?) По крайней мере для меня все опечатки, которые я узнаю, раздражают.

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

  • Если это аргумент функции, используйте aClassвместо class.

  • Если это локальная переменная или переменная-член, используйте myClassвместо class.

  • Если это аксессор, используйте getClass()вместо class().

Конечно, добавленный префикс довольно бессмысленен, и, следовательно, его следует использовать только в крайнем случае. Но, по крайней мере, это не мешает умственному анализатору вашего читателя, и это надежный способ избежать зарезервированных слов.

cmaster
источник
0

Одно из преимуществ творческого правописания - лучшая поисковая способность. Я думаю, что гораздо проще выполнить полный поиск кода по уникальным вещам, чем по обычным словам, где слишком часто вы найдете все неправильные вещи и 1000 из них. В качестве примера я использовал собственный kzpg.com. Google, что сейчас, и вы увидите только несколько просмотров. Это уникально и поэтому очень легко найти.

Но в какой-то мере я думаю, что этот вопрос является вопросом мнения более чем существенным. Я лично вырос на Форт, где все было о словах, и о многих из них. Человек научился очень изобретательно спасать свои пальцы. В итоге у меня было около 640 000 символов, более или менее в моей исходной базе. Поэтому, чтобы слова были короткими, важно, чтобы работа была выполнена.

Эллиптический вид
источник
Эта ссылка сейчас не работает.
Питер Мортенсен,