Аморально ли я использовать имя переменной, которая отличается от ее типа только регистром?

Question

Например, возьмите этот кусок кода:

var person = new Person();

или для вас Pythonistas:

person = Person()

Мне постоянно говорят, насколько это плохо, но я еще не видел пример аморальности этих двух строк кода. Для меня человек - это человек, и попытка дать ему другое имя - пустая трата времени. Я полагаю, что за несколько дней до выделения синтаксиса это было бы очень важно. Но в наши дни довольно легко отличить имя типа от имени переменной. Черт, даже здесь легко увидеть разницу на SO.

Или я что-то упускаю? Если это так, было бы полезно, если бы вы могли привести пример кода, который вызывает проблемы.

Answer 1

Не аморально, но глобальный поиск найдет и Person, и person, если вам не удастся активировать чувствительность к регистру. Я предпочитаю префикс, чтобы сделать глобальный поиск / замену проще, но абсолютно НЕ венгерский или что-то длинное / сложное. Итак, я использую ...

Person для класса / типа aPerson для локальной переменной thePerson для параметра метода myPerson для переменной экземпляра ourPerson для переменной класса

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

Answer 2

Это зависит.

Если у вас строгий стиль использования заглавных букв, поэтому переменные начинаются со строчных букв (и используют для разрыва слов либо under_scores, либо camelCase), а классы начинаются с заглавных букв, тогда очевидно, что person - это переменная, а Person - это класс, и когда кто-то это понимает, они не будут находиться в перекрывающихся пространствах имен. (Точно так же люди почти никогда не путаются между глаголом или существительным «польский» и прилагательным «польский».)

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

Answer 3

Я называю имя так, как оно есть: если переменная представляет человека с двумя собаками, назовите его personWith2Dogs. Если переменная имеет короткую область видимости (например, цикл var), то человек в порядке.

Answer 4

Я бы сказал, что вы, вероятно, имеете в виду какое-то конкретное применение при создании объекта. Один только тип очень редко отражает это использование.

Поэтому, если вы хотите создать новый контакт в приложении адресной книги, вы можете вызвать переменную newContact.

И если вы проводите модульное тестирование своего кода для проверки поведения Person объектов без заданных имен, вы можете назвать их unnamedPerson или что-то подобное.

Называя его просто person упускает большие шансы сделать ваш код самодокументированным.

Answer 5

Какие именно аргументы используют эти люди?

Если они не позволяют вам использовать person в качестве имени переменной, вы можете добавить префикс «a».

aPerson = Person()

Answer 6

Только если вы программируете на VB6. В этом случае то, что вы делаете, является незаконным, но не аморальным.

Answer 7

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

• Показатель хорошей детализации кода: если ваши методы короткие, одноцелевые и имеют описательное имя, вам не нужно много информации в именах переменных. Если у вас есть длинные методы, которые делают много вещей и вам нужно отслеживать много контекста и состояния, то имена ваших переменных должны быть более информативными.

• Индикатор вычислений общего назначения, помещаемых в методы общего назначения: если вы выполняете промежуточное манипулирование структурами данных в бизнес-методе, например, необходимо дедуплицировать массив пользователей, вы будете должны иметь переменные в области видимости с именами, такими как users[] и deduplicatedUsers[]. Если вы переместите дедупликацию к служебному методу, вы можете вызвать метод Utils.dedup(array) и вызвать дедуплицированный массив deduplicatedArray или просто result.

• Java-декомпиляторы часто используют такую ​​схему для именования локальных переменных (переменные экземпляра и класса обычно доступны в байт-коде, а локальные переменные - нет), и результаты более читабельны, чем вы могли ожидать Факт часто более читабелен, чем исходный источник.

• См. Принцип Ларри Уолла "Локальная неоднозначность в порядке" - http://www.wall.org/~larry/natural.html.

Answer 8

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

Например, я использую lowerCamelCase для экземпляров, переменных и UpperCamelCase для классов e.t.c.

Стандарты кодирования должны устранить эту проблему.

Когда я смотрю на успешные программы с открытым исходным кодом, они часто имеют стандарты кодирования

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 (он же «стиль Паскаля») для других типов идентификаторов. [20]

Python рекомендует использовать UpperCamelCase для имен классов. [21]

Реестр NIEM требует, чтобы элементы данных XML использовали UpperCamelCase, а атрибуты XML - lowerCamelCase.

Не существует единого соглашения о включении заглавных букв (главным образом, аббревиатур и инициализмов) в имена CamelCase. Подходы включают оставление всей аббревиатуры в верхнем регистре (например, в «useHTTPConnection») и оставление только первой буквы в верхнем регистре (например, в «useHttpConnection»).

Случай с верблюдом отнюдь не универсален в вычислительной технике. Пользователи нескольких современных языков программирования, особенно из семейства Lisp и Forth, почти всегда используют дефисы. Среди причин, которые иногда приводятся, заключается в том, что для этого не требуется сдвиг на большинстве клавиатур, что слова более читабельны, когда они разделены, и что верблюжий регистр может просто не быть надежно сохранен в нечувствительных к регистру языках или в случае фальсификации регистра (таких как Common Lisp, который, будучи технически чувствительным к регистру языком, по умолчанию канонизирует (складывает) идентификаторы в верхний регистр).

Answer 9

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

Если они отличаются только регистром, он будет хорошо работать в чувствительных к регистру языках, например C #, но не в VB.NET.

Так, например, в VB я бы написал

Private _name As String

но

Public Property Name() As String
    Get
        Return _name
    End Get
    Set(ByVal Value As String)
        _name = Value
    End Set
End Property

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

Answer 10

Я тоже так делаю, и я не понимаю, почему это должно быть «аморально». Хотя я могу понять, что это «может» иногда сбивает с толку, но сегодня у нас есть IDE с intellisense и подсветкой синтаксиса, которые обеспечат (если вы допустите ошибку и будете ссылаться на вашу переменную вместо вашего класса и наоборот) увидеть вашу ошибку довольно быстро. И у нас также есть компилятор. :)