Я часто вижу код, который включает преднамеренные опечатки общих слов, которые, к лучшему или худшему, стали зарезервированными словами:
klass
илиclazz
для класса :Class clazz = ThisClass.class
kount
для подсчета в SQL:count(*) AS kount
Лично я считаю, что это снижает читабельность. В моей собственной практике я не нашел слишком много случаев, когда нельзя было бы использовать лучшее имя - itemClass
или recordTotal
.
Пример из JavaDocs для класса показывает это в параметрах:
public <U> Class<? extends U> asSubclass(Class<U> clazz)
Это показывает разумный вариант использования?
cls
это общее (на самом деле, идиоматическое) имя для переменных / аргументов, ограничивающих реальные классы (те, которые вы объявляете с помощьюclass
ключевого слова и у которых все является экземпляром).typedef char ínt
?iñt
. Вот мой план мирового господства.Class c
).Ответы:
ИМХО, это очень плохая идея. Зарезервированные слова зарезервированы по причине, и это снижает читаемость.
Я также полностью согласен с вашим вторым пунктом. Назвать переменную
class
, даже если бы вы могли это сделать, было бы так же плохо, как назвать ееtmp
илиa
. Что за класс? Класс чего? Имена должны быть описательными.источник
Руководство по стилю Python конкретно упоминает эту проблему и предлагает:
Это кажется довольно хорошим общим правилом, если предположить, что оно не противоречит семантике конкретного языка.
источник
union
используется ключевое слово (как в C)? Вы собираетесь назвать этоfoo
только потому, что это не должно выглядетьunion
?cls
это стандартное имя аргумента для метода класса. Также, например, в Django объекты имеют.id
атрибут, который, конечно, конфликтует соid
встроенной функцией.merge
метод все равно нуждался бы в документации, явно заявляющей, что он реализует объединение и был переименован по чисто техническим причинам.Код запаха.
Приведенный выше код ничего не говорит мне о предполагаемом использовании переменных.
Та же проблема
Приведенный выше код не должен требовать добавления строки ключевого слова к имени переменной. Если вам нужно идентифицировать типы по имени переменной, ваш код слишком длинный. Уплотнить-рефакторинг.
источник
Class<T>
параметр, и это может иметь смысл. Так что я не согласен с тем, что это запах кода.Лично я думаю, что это совершенно правильный вариант для вашего стиля кода.
Это зарезервированные слова, поэтому компилятору не нужно решать, имеете ли вы в виду механику языка или свою переменную. Имея это в виду, это означает, что они ожидают, что люди будут нуждаться в переменной, такой как зарезервированное слово.
Просматривая исходный код в комплекте с JDK 1.6 R21, я обнаружил 917 случаев появления «clazz». Видимо, они думали, что это приемлемый стиль.
Как ваша команда относится к этому? Если вы думаете, что это плохо, но остальные 9 парней в вашей команде думают, что это хорошо, тогда вы должны укусить пулю и принять это. Пока есть сообщение о том, что хорошо, а что нет, и вы поднимаете вопросы, которые видите, как видите их, все должно быть хорошо.
То, как ваша команда относится к стилю кода, важнее, чем мое мнение или кто-либо еще в этом посте . Это относится и к любым другим решениям в отношении стиля кода, которые могут у вас возникнуть.
источник
klass
иclazz
это плохо. Вы должны быть последовательными, чтобы они могли выучить это только один раз. И в идеале это прописано в рекомендациях по стилю команд, так что это неудивительно.Преднамеренные ошибки в написании слов, чтобы избежать зарезервированных слов - плохая идея.
Ошибочные написания трудно отличить от правильного написания, поэтому они затрудняют чтение кода.
Ошибочные орфографические ошибки трудно запомнить, так что несколько несовместимых орфографических ошибок могут конкурировать внутри кода, что делает код труднее писать и труднее читать.
Зарезервированные слова относятся к языку, используемому для решения проблемы, а не к самой проблеме. Имя переменной должно указывать на концепцию, связанную с проблемой.
Поэтому лучше выбрать альтернативное описательное имя или, если не существует удовлетворительной альтернативы, квалифицировать зарезервированное слово как в:
источник
Class clazz
пахнет как «Я не удосужился попытаться придумать хорошее имя». Переменная всегда представляет что-то, и хорошее имя описывает это. Я отказываюсь представить, что,clazz
например, при любых обстоятельствах это лучшее имя из всех возможных. Является ли это ссылкой на класс -> class_reference, является ли это копией объекта класса -> class_copy и т. Д. Возможно, также отбрасывает "класс" и просто использует описательное слово, напримерЗдесь clazz - целевой класс, на котором должна выполняться проверка, поэтому
будет гораздо лучше описывать, для чего используется параметр, чем когда-либо Клац.
источник
classToBeAccessed
действительно хорошее имя (classToBeChecked
возможно, будет даже лучше).Если они используют зарезервированное имя для переменной, это переменная с плохим именем. Даже если это законное имя, например, Class для программного обеспечения в классе.
Переменные с плохим именем являются признаком плохо продуманного или случайного кода - остерегайтесь других ошибок в поддерживаемой вами части программного обеспечения.
источник
Я думаю, что преднамеренные опечатки или сокращения являются хорошей идеей, если их использовать осторожно и последовательно .
Рассмотрим в Java:
Место, где можно использовать орфографические ошибки, - это то, что зарезервированное слово, несомненно, является лучшим словом для работы. Есть два места, где нельзя использовать орфографические ошибки, где вы можете испытать искушение.
В первом случае довольно очевидно, что лень редко является хорошей политикой для создания качественного кода. Во втором случае выберите действительно короткую переменную. Это то, что математики делают все время, и программисты делают для индексов. Нет никаких причин ограничивать себя этим для индексов, если это действительно фиктивная переменная:
Вы ничего не потеряете с короткими именами переменных, когда метод или структура кода говорит вам, что должно быть там.
источник
nextMeeting(MeetingRoom r)
это много. ЧтоmeetingRoom
тебя там привлекает? ЕслиnextMeeting(int meetingRoom)
бы я понял, я бы хотел использовать короткие имена переменных, когда информация уже доступна из других источников .Klass
была альтернатива, когда было зарезервированное слово . Я не рекомендую использовать орфографические ошибки, когда доступно оригинальное написание!Я видел законное использование
Class klass
при отражении, когда вы действительно работаете с экземпляромClass
класса.источник
userClass
или какой-либо другой вариант.classInstance
закончитьklass
.classInstance
это довольно избыточно. Более того, я мог представить что-то подобноеclass klass; Object classInstance = klass.newInstance;
.Для локальных переменных и формальных аргументов это просто не имеет значения.
Любое имя хорошо, если оно не вводит в заблуждение и не раздражает. В вашем примере:
не имеет значения, является ли единственная локальная переменная "clazz" или "klass" или "cls" или просто "c". Я бы, наверное, просто встроил выражение:
Длина имени переменной должна быть связана с областью действия переменной. Для локальных переменных в коротких методах (и все они должны быть короткими) подойдут очень короткие имена.
источник
ClassUtils.loadClass(benchmark.generatedClass())
=>benchmark.generatedClass()
- потерянClassUtils.loadClass
по путиЯ думаю, что орфографические ошибки всегда плохая идея. Это просто не приятно для ваших читателей. Мне, например, было бы интересно, если я что-то пропустил, когда я вижу слово
klass
. (Ониclass
имели в виду , или они имели в виду пирата?) По крайней мере для меня все опечатки, которые я узнаю, раздражают.Для очень немногих случаев, когда зарезервированное слово действительно единственное существенное, что известно о переменной, я бы использовал следующие альтернативы:
Если это аргумент функции, используйте
aClass
вместоclass
.Если это локальная переменная или переменная-член, используйте
myClass
вместоclass
.Если это аксессор, используйте
getClass()
вместоclass()
.Конечно, добавленный префикс довольно бессмысленен, и, следовательно, его следует использовать только в крайнем случае. Но, по крайней мере, это не мешает умственному анализатору вашего читателя, и это надежный способ избежать зарезервированных слов.
источник
Одно из преимуществ творческого правописания - лучшая поисковая способность. Я думаю, что гораздо проще выполнить полный поиск кода по уникальным вещам, чем по обычным словам, где слишком часто вы найдете все неправильные вещи и 1000 из них. В качестве примера я использовал собственный kzpg.com. Google, что сейчас, и вы увидите только несколько просмотров. Это уникально и поэтому очень легко найти.
Но в какой-то мере я думаю, что этот вопрос является вопросом мнения более чем существенным. Я лично вырос на Форт, где все было о словах, и о многих из них. Человек научился очень изобретательно спасать свои пальцы. В итоге у меня было около 640 000 символов, более или менее в моей исходной базе. Поэтому, чтобы слова были короткими, важно, чтобы работа была выполнена.
источник