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

Например, возьмите этот фрагмент кода:

var person = new Person();

или для вас Pythonistas:

person = Person()

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

Или что-то мне не хватает? Если да, было бы полезно, если бы вы могли предоставить пример кода, вызывающего проблемы.

Каковы аргументы тех, кто говорит вам, что это плохо? Я все время это делаю. Это самый простой и выразительный способ дать имя отдельной переменной типа. Если вам нужны два Personобъекта, вы можете добавить к префиксу personмногозначительные прилагательные, например

fastPerson
slowPerson

иначе просто

person

меня устраивает.

Я часто использую этот шаблон в сигнатурах методов. Если я не могу предоставить альтернативное описательное имя, то ИМХО, в этом нет ничего плохого.

Что неправильно, если у вас есть два типа Person и person, тогда это очень-очень неправильно.

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

Person person = new Person(); // okay

int Int = 42; // pure evil

Если кто-то говорит, что это зло, спросите его, лучше ли это:

var abc = new Person();

Если Личность в контексте является общей Личностью, то «человек» - действительно хорошее имя. Конечно, если у человека есть определенная роль в коде, то лучше назвать ее, используя роль.

Полагаю, за это меня проголосуют против, но ...

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

Я не думаю, что это обязательно «плохо», но, очевидно, если вы можете квалифицировать это, чтобы дать ему больше контекста, например, что это за человек (вы имеете дело только с одним из предположительно многих возможных людей), то его выбирает кто-то другой вверх может понять лучше.

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

Я использую это довольно часто, так как обнаружил, что переменная в нижнем регистре фактически сообщает мне не только то, что это экземпляр, но и имя класса.

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

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

aPerson = Person()

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

Например, я использую 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упускает большой шанс сделать ваш код самодокументированным.

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

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

Я тоже не вижу в этой практике никаких проблем. Пока существует только одна переменная этого класса, ее легко писать и легко читать. Imo, это применимо даже в простом текстовом редакторе. Я лично не могу припомнить, чтобы кто-нибудь называл это плохим или даже аморальным. Просто продолжай делать это :)

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

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

Decimal _decimal = item.BaseCost + item.Tax;

Вместо этого было бы рекомендовано более описательное имя, такое как «_total» или «_cost».

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

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

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

Person person = new Person()Сам часто пользуюсь . Обычно используется в Java / C #.

Хотя вчера я задался вопросом, почему

private enum DataType {NEW, OLD}

не работает на C # ...

Особенно видя , как вы можете использовать String, string, Double, double, ... по желанию в C #.

Person person = new Person()

хорошо в моей книге.

Ужас становится, когда у вас есть:

string Person;
string person;

Очень легко смешать 2.

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

Что касается типов CLR (int, string и т. Д.), Вы можете использовать String или string (и т. Д.) Для объявления типа, поэтому я бы избегал использования чего-то вроде

int Int = 0;
string String = "hi there";

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

fastPerson / slowPerson, как указано выше, хороши ... они описательны и отличаются от имени типа переменной ... но давай, человек, вызывать int "Int" было бы просто лениво.

Я бы сказал, что это никогда не бывает аморальным - это просто имя вашей базовой переменной. Если вы не можете придумать лучшее имя, назвав его в честь его типа является хорошим значением по умолчанию (для сложных типов. Только - для встроенных типов его зла ) и много времени там действительно не лучшее названия , потому что вы не» Я ничего не знаю о переменной. Как с этим методом

void SaveToDatabase(Person person) {...}

Единственное, что вы могли бы с полным основанием назвать человеком, это person_to_saveто, что кажется лишним.

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

void AddToAccount(Account account, Person person)  {...}

чем это

void AddToAccount(Account account, Person dependent)  {...}

Однако, пожалуйста, пожалуйста - хорошенько, пожалуйста, не ставьте «a» или «t» перед названием типа. IE aPerson для «человека» или tPerson для «человека». Это слишком сложно и ничего не добавляет. Кроме того, вы начинаете засорять область видимости кучей переменных, которые начинаются с a или t, что может минимизировать значение intelli-sense.

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

Person aPerson = new Person();

Думаю, это делает код более естественным.

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

Мое практическое правило? Заявления в коде должны читаться как простые английские предложения.

Человек 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 и т. Д., Где это помогает сохранять прямое присвоение / приведение типов).

Мои две (!) Биты :-)