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

Ответ 1

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

fastPerson
slowPerson

иначе просто

person

все в порядке со мной.

Ответ 2

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

Что не так, если у вас есть два типа Личность и человек, то это очень неправильно.

Ответ 3

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

Person person = new Person(); // okay

int Int = 42; // pure evil

Ответ 4

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

var abc = new Person();

Ответ 5

Если Person является общим персонажем в контексте, то "человек" - действительно хорошее имя. Конечно, если у Человека есть определенная роль в коде, тогда лучше назвать ее, используя роль.

Ответ 6

Я полагаю, что я заведуй за это, но...

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

Ответ 7

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

Ответ 8

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

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

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

Ответ 9

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

Лицо человека = новое лицо();

Person person2 = new Person();

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

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

Ответ 10

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

Ответ 11

Я использую это в своем коде и не думаю, что с ним что-то не так. Тем не менее, я (возможно) не использовал бы его в методе дольше, чем, скажем, один экран, и если есть несколько экземпляров класса Person. Определенно не называйте их person1, person2, person3... вместо этого используйте что-то более описательное, например person_to_del, person_to_ban, person_to_update и т.д.

Ответ 12

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

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

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

Ответ 13

Это зависит.

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

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

Ответ 14

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

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

aPerson = Person()

Ответ 15

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

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

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

Вызов просто Person дает большой шанс сделать ваш код самодокументированным.

Ответ 16

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

Например, я использую 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

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

На самом деле посмотрите на запись в wikipedia (от http://en.wikipedia.org/wiki/CamelCase)

Стиль программирования и кодирования

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

В этих рекомендациях часто различают UpperCamelCase и lowerCamelCase, обычно указывающие, какое разнообразие должно использоваться для определенных типов объектов: переменные, поля записей, методы, процедуры, типы и т.д.

Один широко используемый стиль Java-кодирования диктует использование UpperCamelCase для классов, а lowerCamelCase - для экземпляров и методов. [19] Признавая это использование, некоторые IDE, такие как Eclipse, реализуют ярлыки на основе CamelCase. Например, в функции Eclipse Content assist при вводе только строчных букв слова 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" ).

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

Ответ 17

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

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

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

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

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

Ответ 18

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

Ответ 19

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

Ответ 20

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

Ответ 21

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

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

Decimal _decimal = item.BaseCost + item.Tax;

Вместо этого будет указано более описательное имя, например "_total" или "_cost".

Ответ 22

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

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

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

Ответ 23

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

Хотя вчера мне стало интересно, почему

private enum DataType {NEW, OLD}

не работает в С#...

В частности, вы можете использовать String, String, Double, Double,... по желанию в С#.

Ответ 24

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

Ответ 25

Person person = new Person()

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

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

string Person;
string person;

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

Ответ 26

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

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

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

Ответ 27

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

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

Ответ 28

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

void SaveToDatabase(Person person) {...}

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

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

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

чем это

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

Однако, пожалуйста, пожалуйста, пожалуйста, не ставьте "a" или "t" перед именем типа. И.Е. aперсонаж для "человека" или "человек" для "человека". Его чрезмерно сложно и не добавляет много, если значение. Кроме того, вы начинаете загрязнять область видимости с помощью множества переменных, начинающихся с a или t, что может свести к минимуму значение intelli-sense.

Ответ 29

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

Person aPerson = new Person();

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

Ответ 30

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

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

Лицо человека = новое лицо();

Сотрудник сотрудника = person.getRole(EMPLOYEE);

Родительский родитель = person.getRole(PARENT);

person.getFullName();

employee.getSalary();

parent.getChildren();

parent.getFullName();//принятие рисунка декоратора при воспроизведении

if (person.hasRole(EMPLOYEE)) {

   ...

}

И так далее.

Если область видимости переменной ограничена (например, метод инкапсуляции - 10-15 строк), я могу даже использовать "p" вместо "person". Более короткие имена переменных менее отвлекают вас от попыток удержать контекст в голове. Избегайте безвозмездных префиксов, таких как венгерская нотация "а" или (дрожь) и их ответвления. (Имейте в виду, что я не имею ничего против таких префиксов, когда они используются в соответствующем контексте - код С++/COM/ATL/Win32 и т.д., Где он помогает сохранить назначения /typecasting прямо).

Мои два (!) бита: -)