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

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

fastPerson
slowPerson

иначе просто

person

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

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

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

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

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

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

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

Аморально ... Нет. Сложнее, чем должно быть для рефакторинга, .. Да.

Попробуйте "_person"

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

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

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

Person person = new Person(); // okay

int Int = 42; // pure evil

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

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

aPerson = Person()

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

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

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

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

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

Я тоже не вижу в этой практике никаких проблем. Пока существует только одна переменная этого класса, ее легко писать и легко читать. 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#.

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

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

Person aPerson = new Person();

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

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

Человек person = новый Человек ();

Человек person2 = новый Человек ();

Тогда это было бы на грани «Плохого». Однако в этом случае вам следует провести рефакторинг своего исходного персонажа, чтобы различать их.

Что касается вашего примера, имя переменной «человек» является полностью описательным именем для объекта «Человек». Поэтому в этом нет ничего плохого.

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" было бы просто лениво.

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

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

Я часто использую это в своем коде и не думаю, что с этим что-то не так. Тем не менее, я (вероятно) не стал бы использовать его в методе дольше, чем, скажем, один экран, и если существует несколько экземпляров класса 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 - это класс, и когда кто-то это понимает , они не будут находиться в перекрывающихся пространствах имен. (Точно так же люди почти никогда не путают глагол или существительное «полировать» и прилагательное «польский».)

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

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

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

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

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

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

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

var abc = new Person();

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

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

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

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

void SaveToDatabase(Person person) {...}

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

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

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

чем это

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

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

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

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

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

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

Это не только нормально, но и разумно.

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

http://msdn.microsoft.com/en-us/library/fzcth91k(VS.71).aspx

Нет, неплохо назвать это по-другому, например.

Person clerk = new Person();
Person manager = new Person();

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

Person xyz = new Person();