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

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

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

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

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

 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 случаев появления «clazz». Видимо, они думали, что это приемлемый стиль.

Как ваша команда относится к этому? Если вы думаете, что это плохо, но остальные 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)

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

Если они используют зарезервированное имя для переменной, это переменная с плохим именем. Даже если это законное имя, например, 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класса.

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

Класс или класс для класса: Класс класс = 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 символов, более или менее в моей исходной базе. Поэтому, чтобы слова были короткими, важно, чтобы работа была выполнена.