Например, возьмите этот фрагмент кода:
var person = new Person();
или для вас Pythonistas:
person = Person()
Мне постоянно говорят, насколько это плохо, но я еще не видел примера безнравственности этих двух строк кода. Для меня человек - это Личность, и попытки дать ему другое имя - пустая трата времени. Я полагаю, что до выделения синтаксиса это было бы большим делом. Но в наши дни довольно легко отличить имя типа от имени переменной. Черт возьми, здесь, на SO, даже легко увидеть разницу.
Или что-то мне не хватает? Если да, было бы полезно, если бы вы могли предоставить пример кода, вызывающего проблемы.
language-agnostic
coding-style
naming-conventions
variable-names
Джейсон Бейкер
источник
источник
Person Person=new Person();
для этого дела? Как сказано в Вопросе, мы живем во времена такой невероятной подсветки синтаксиса и распознавания контекста, что мой компилятор никогда не жаловался на то, что я делаю именно это. Мне просто нравятся мои переменные CamelCased - почему бы и нет (в ситуациях, когдаPerson Person
это общий и единственный экземпляр класса, а конфликт отсутствует и не возможен)?Ответы:
Каковы аргументы тех, кто говорит вам, что это плохо? Я все время это делаю. Это самый простой и выразительный способ дать имя отдельной переменной типа. Если вам нужны два
Person
объекта, вы можете добавить к префиксуperson
многозначительные прилагательные, напримериначе просто
меня устраивает.
источник
Я часто использую этот шаблон в сигнатурах методов. Если я не могу предоставить альтернативное описательное имя, то ИМХО, в этом нет ничего плохого.
Что неправильно, если у вас есть два типа Person и person, тогда это очень-очень неправильно.
источник
Я все время использую его для временных ссылок на объекты. Я бы избегал этого, как чумы для примитивных типов данных.
источник
Если кто-то говорит, что это зло, спросите его, лучше ли это:
источник
var temp = new Person();
(Отказ от ответственности: я знаю, что действительно есть места для одноразового использования временных переменных, но часто, когда я вижу это в чьем-то коде, автор просто никогда не возвращался к тому, чтобы дать переменной подходящее имя, и это может также будет "abc".)Если Личность в контексте является общей Личностью, то «человек» - действительно хорошее имя. Конечно, если у человека есть определенная роль в коде, то лучше назвать ее, используя роль.
источник
Полагаю, за это меня проголосуют против, но ...
Мы, программисты, только что пережив столетие, став свидетелями эпических убийств и жадности, по-настоящему счастливы, если самое безнравственное, что мы можем сделать, - это назвать переменную.
источник
Я не думаю, что это обязательно «плохо», но, очевидно, если вы можете квалифицировать это, чтобы дать ему больше контекста, например, что это за человек (вы имеете дело только с одним из предположительно многих возможных людей), то его выбирает кто-то другой вверх может понять лучше.
источник
Джейсон - Я не уверен, кто сказал тебе, что это плохо. Ряд авторов используют это как стандартный способ выражения экземпляра (в нижнем регистре) класса ( в верхнем регистре ).
Я использую это довольно часто, так как обнаружил, что переменная в нижнем регистре фактически сообщает мне не только то, что это экземпляр, но и имя класса.
Если у кого-то не будет веских аргументов в пользу обратного, я обязательно продолжу это делать.
источник
Причина, по которой это считается плохим, заключается в том, что если вам нужно иметь 2 человека в будущем, вы можете получить код, который выглядит так.
Человек person = новый Человек ();
Человек person2 = новый Человек ();
Тогда это было бы на грани «Плохого». Однако в этом случае вам следует провести рефакторинг вашего исходного персонажа, чтобы различать их.
Что касается вашего примера, имя переменной «человек» - это совершенно описательное имя для объекта «Человек». Поэтому в этом нет ничего плохого.
источник
Я говорю имя для того, что это такое: если переменная представляет человека с двумя собаками, назовите его
personWith2Dogs
. Если переменная имеет короткую область видимости (например, цикл var), тогда с человеком все в порядке.источник
Я часто использую это в своем коде и не думаю, что с этим что-то не так. Тем не менее, я (вероятно) не стал бы использовать его в методе дольше, чем, скажем, один экран, и если существует несколько экземпляров класса Person. Определенно не называйте их person1, person2, person3 ... вместо этого используйте что-нибудь более описательное, например person_to_del, person_to_ban, person_to_update и т. Д.
источник
Не аморально, но глобальный поиск найдет и то,
Person
и другое, иperson
если вы не активируете чувствительность к регистру. Я предпочитаю префикс, чтобы упростить глобальный поиск / замену, но абсолютно НЕ венгерский или что-то длинное / сложное. Итак, я использую ...Person
для класса / типаaPerson
для локальной переменнойthePerson
для параметра методаmyPerson
для переменной экземпляраourPerson
для переменной классаВ редких случаях я могу использовать
p
в локальном контексте, где у меня есть МНОГО ссылок, но обычно это относится только к индексам циклов и т.п.источник
Это зависит.
Если у вас строгий стиль использования заглавных букв, поэтому переменные начинаются с нижнего регистра (и используют либо under_scores, либо camelCase для разрывов слов), а классы начинаются с заглавных букв, тогда очевидно, что person - это переменная, а Person - это класс, и когда кто-то это понимает , они не будут находиться в перекрывающихся пространствах имен. (Точно так же люди почти никогда не путают глагол или существительное «полировать» и прилагательное «польский».)
Если у вас нет такого стиля, значит, у вас есть два имени, которые легко перепутать, и они отличаются только регистром. Это плохо.
источник
Какие точные аргументы используют эти люди?
Если они не позволяют вам использовать человека в качестве имени переменной, вы можете подумать о добавлении префикса «a».
источник
Я думаю, что ты делаешь нормально. Я думаю, что в целом важно иметь согласованные стандарты кодирования.
Например, я использую lowerCamelCase для экземпляров, переменных и UpperCamelCase для классов и т. Д.
Стандарты кодирования должны устранить эту проблему.
Когда я смотрю на успешные программы с открытым исходным кодом, у них часто есть стандарты кодирования.
http://drupal.org/coding-standards
http://help.joomla.org/content/view/826/125/
http://wiki.rubyonrails.org/rails/pages/CodingStandards
http://lxr.linux.no/linux/Documentation/CodingStyle
Согласие со стандартами кодирования должно стать вашей последней битвой по этому поводу.
На самом деле посмотрите запись в википедии (из http://en.wikipedia.org/wiki/CamelCase )
Стиль программирования и кодирования
Иногда рекомендуется использовать внутренние заглавные буквы для обозначения границ слов в соответствии с рекомендациями по стилю кодирования для написания исходного кода (например, язык программирования Mesa и язык программирования Java). Рекомендации, содержащиеся в некоторых из этих руководств, поддерживаются инструментами статического анализа, которые проверяют исходный код на соответствие.
В этих рекомендациях часто проводится различие между UpperCamelCase и lowerCamelCase, обычно указывается, какое разнообразие следует использовать для конкретных типов сущностей: переменных, полей записи, методов, процедур, типов и т. Д.
Один широко используемый стиль кодирования Java требует, чтобы UpperCamelCase использовался для классов, а lowerCamelCase - для экземпляров и методов [19]. Признавая это использование, некоторые IDE, такие как Eclipse, реализуют ярлыки на основе CamelCase. Например, в функции поддержки содержимого Eclipse ввод только заглавных букв слова CamelCase будет предлагать любое подходящее имя класса или метода (например, ввод «NPE» и активация помощника по содержимому может предложить «NullPointerException»).
Исходная венгерская нотация программирования указывает, что сокращение нижнего регистра для «типа использования» (не типа данных) должно предшествовать всем именам переменных, а оставшаяся часть имени должна быть в UpperCamelCase; как таковой это форма lowerCamelCase. CamelCase - это официальное соглашение для имен файлов в Java и для персонального компьютера Amiga.
Microsoft .NET рекомендует использовать lowerCamelCase для параметров и закрытых полей и UpperCamelCase (также известный как «Pascal Style») для других типов идентификаторов. [20]
Python рекомендует использовать UpperCamelCase для имен классов. [21]
Реестр NIEM требует, чтобы элементы данных XML использовали UpperCamelCase, а атрибуты XML использовали lowerCamelCase.
Не существует единого соглашения для включения аббревиатур в верхнем регистре (в основном акронимов и инициализмов) в имена CamelCase. Подходы включают в себя оставление всей аббревиатуры в верхнем регистре (например, в «useHTTPConnection») и оставление только первой буквы в верхнем регистре (например, в «useHttpConnection»).
Корпус Camel отнюдь не универсален в вычислительной технике. Пользователи нескольких современных языков программирования, особенно из семейств Lisp и Forth, почти всегда используют дефисы. Среди причин, которые иногда приводят, является то, что для этого не требуется сдвиг на большинстве клавиатур, что слова более читабельны, когда они разделены, и что верблюжий регистр может просто не сохраняться надежно в нечувствительных к регистру языках или языках со складыванием регистра (например, Common Lisp, который, хотя технически и является языком с учетом регистра, по умолчанию преобразует (сворачивает) идентификаторы в верхний регистр).
источник
Можно привести более веский аргумент в пользу того, что такие имена методов не только безвредны, но могут быть индикатором хорошего качества кода.
Индикатор хорошей детализации кода: если ваши методы короткие, одноцелевые и имеют описательные названия, вам не нужно много информации в именах переменных. Если у вас есть длинные методы, которые выполняют множество функций и вам необходимо отслеживать большой объем контекста и состояния, тогда имена переменных должны быть более наглядными.
Индикатор универсальных вычислений, переданных в универсальные методы: если вы выполняете промежуточные манипуляции со структурами данных в бизнес-методе, например, массив пользователей должен быть дедуплицирован, вам необходимо иметь переменные в области видимости с такими именами, как
users[]
иdeduplicatedUsers[]
. Если вы переместите дедупликацию в служебный метод, вы можете вызвать методUtils.dedup(array)
, и вы можете вызвать дедуплицированный массивdeduplicatedArray
или простоresult
.Декомпиляторы Java часто используют подобную схему для именования локальных переменных (переменные экземпляра и класса обычно доступны в байт-коде, но локальные переменные нет), и результаты более читабельны, чем вы могли ожидать, на самом деле часто более читаемы, чем первоисточник.
См. Принцип Ларри Уолла «Локальная неоднозначность - это нормально» - http://www.wall.org/~larry/natural.html .
источник
Я бы сказал, что вы, вероятно, имеете в виду какое-то конкретное использование, когда создаете объект. Один только тип очень редко отражает это использование.
Поэтому, если вы хотите создать новый контакт в приложении адресной книги, вы можете вызвать переменную
newContact
.И если вы модульно тестируете свой код для проверки поведения
Person
объектов без заданных имен, вы можете вызвать ихunnamedPerson
или что-то подобное.Вызов этого просто
person
упускает большой шанс сделать ваш код самодокументированным.источник
var he_who_must_not_be_named = new Person();
? :-)Только если вы программируете на VB6. В таком случае то , что вы делаете, незаконно, но не аморально.
источник
Я тоже так делаю и не понимаю, почему это должно быть «аморальным». Хотя я могу понять, что это иногда может сбивать с толку, но сегодня у нас есть IDE с intellisense и подсветкой синтаксиса, которая гарантирует, что (если вы сделаете ошибку и укажете свою переменную вместо своего класса, и наоборот) увидеть свою ошибку довольно быстро. А еще у нас есть компилятор. :)
источник
Я тоже не вижу в этой практике никаких проблем. Пока существует только одна переменная этого класса, ее легко писать и легко читать. Imo, это применимо даже в простом текстовом редакторе. Я лично не могу припомнить, чтобы кто-нибудь называл это плохим или даже аморальным. Просто продолжай делать это :)
источник
Я думаю, что «правило», о котором вы, возможно, думаете, больше предназначено для примитивных типов и классов, в которых имя класса является плохим именем переменной.
Например, если вы рассчитываете стоимость определенного товара в интернет-магазине, следующий код будет не лучшим вариантом:
Вместо этого было бы рекомендовано более описательное имя, такое как «_total» или «_cost».
источник
Единственная проблема, связанная с подобными вещами, которую я обнаружил, - это то, нужно ли вам одно и то же имя для частного члена, а также для общедоступного свойства.
Если они различаются только регистром, это будет нормально работать на языках с учетом регистра, таких как C #, но не на VB.NET.
Так, например, в VB я бы написал
но
Я бы сделал то же самое на C #, чтобы перевод с одного на другой был безболезненным. Это также делает его немного менее подверженным ошибкам, так как очень легко неправильно прочитать или набрать слова, которые различаются только регистром.
источник
Не аморально, но если ваше лучшее имя для вашей переменной - это имя типа, что-то не так, или вы просто делаете доказательство концепции или что-то в этом роде. Для меня имя переменной должно относиться к значению в бизнес-контексте, а не к языку программирования. Разобраться в коде будет сложнее.
источник
Person person = new Person()
Сам часто пользуюсь . Обычно используется в Java / C #.Хотя вчера я задался вопросом, почему
не работает на C # ...
Особенно видя , как вы можете использовать
String
,string
,Double
,double
, ... по желанию в C #.источник
хорошо в моей книге.
Ужас становится, когда у вас есть:
Очень легко смешать 2.
источник
То, что было сказано мне, кроме несоответствия нашим стандартам кодирования, позволяет избежать путаницы, когда кто-то другой читает мой код. Лично я не вижу в этом проблемы, если понятен смысл.
Что касается типов CLR (int, string и т. Д.), Вы можете использовать String или string (и т. Д.) Для объявления типа, поэтому я бы избегал использования чего-то вроде
источник
Опасно делать единственную разницу в использовании заглавных букв ... продолжайте делать это для большого проекта, и я гарантирую, что вы столкнетесь с причудливыми ошибками, которые вы не можете обнаружить.
fastPerson / slowPerson, как указано выше, хороши ... они описательны и отличаются от имени типа переменной ... но давай, человек, вызывать int "Int" было бы просто лениво.
источник
Я бы сказал, что это никогда не бывает аморальным - это просто имя вашей базовой переменной. Если вы не можете придумать лучшее имя, назвав его в честь его типа является хорошим значением по умолчанию (для сложных типов. Только - для встроенных типов его зла ) и много времени там действительно не лучшее названия , потому что вы не» Я ничего не знаю о переменной. Как с этим методом
Единственное, что вы могли бы с полным основанием назвать человеком, это
person_to_save
то, что кажется лишним.Однако во многих случаях вы можете улучшить читаемость кода, заменив person на более информативное имя. Например, это менее наглядно
чем это
Однако, пожалуйста, пожалуйста - хорошенько, пожалуйста, не ставьте «a» или «t» перед названием типа. IE aPerson для «человека» или tPerson для «человека». Это слишком сложно и ничего не добавляет. Кроме того, вы начинаете засорять область видимости кучей переменных, которые начинаются с a или t, что может минимизировать значение intelli-sense.
источник
Я бы не сказал, что это ужасно. Я обычно добавляю к имени переменной префикс 'a' в таких вещах, чтобы показать, что это единственный экземпляр типа, поэтому я бы сделал
Думаю, это делает код более естественным.
источник
Абсолютно ничего плохого в этом нет с учетом оговорок, указанных другими (резюмируя здесь для удобства): не делать этого с примитивными типами, рефакторинг исходного экземпляра, если другой экземпляр добавляется позже, не использовать регистр символов для различения имен классов и т. Д.
Мое практическое правило? Заявления в коде должны читаться как простые английские предложения.
Человек person = новый Человек ();
Сотрудник employee = person.getRole (СОТРУДНИК);
Родитель parent = person.getRole (PARENT);
person.getFullName ();
employee.getSalary ();
parent.getChildren ();
parent.getFullName (); // предполагаем, что шаблон декоратора в игре
if (person.hasRole (СОТРУДНИК)) {
...
}
И так далее.
Если область действия переменной ограничена (например, метод инкапсуляции составляет 10-15 строк), я могу даже использовать «p» вместо «person». Более короткие имена переменных меньше отвлекают при попытке удержать контекст в голове. Избегайте бесплатных префиксов, таких как «а» или (вздрогнуть) венгерских обозначений и их ответвлений. (Имейте в виду, я ничего не имею против таких префиксов, когда они используются в соответствующем контексте - код C ++ / COM / ATL / Win32 API и т. Д., Где это помогает сохранять прямое присвоение / приведение типов).
Мои две (!) Биты :-)
источник