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

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

Person aPerson = new Person();

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

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

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

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

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

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

Person person = new Person()

прекрасен в моей книге.

Wheh это становится ужасным, когда Вы имеете:

string Person;
string person;

Очень легкий перепутать 2.

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

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

private enum DataType {NEW, OLD}

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

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

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

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

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

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

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

Decimal _decimal = item.BaseCost + item.Tax;

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

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

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

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

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

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

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

• Видят, что принцип Larry Wall "Локальной Неоднозначности в порядке" - http://www.wall.org/~larry/natural.html .

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

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

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

Person person = new Person(); // okay

int Int = 42; // pure evil

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

var abc = new Person();

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это зависит.

, Если у Вас есть строгий стиль капитализации, таким образом, переменные начинают нижний регистр (и используют или under_scores или Camel-регистр для разрывов слова), и Классы начинаются с Прописных букв, тогда очевидно, что человек является переменной, и Человек является классом, и когда кто-то поймет это, они, будет казаться, не будут в перекрывающихся пространствах имен. (Точно так же люди почти никогда не запутываются между глаголом или существительным "полировка" и прилагательным "польский язык".)

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

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

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

aPerson = Person()

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

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

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

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

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

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

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

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

, Который тогда граничил бы "Плохо". Однако в этом случае необходимо тогда осуществить рефакторинг orginal личность для различения два.

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

Полагаю, я буду осужден за такие слова, но ...

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

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

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

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.

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

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

Person person = new Person();

Employee employee = person.getRole(EMPLOYEE);

Parent parent = person.getRole(PARENT);

person.getFullName();

employee.getSalary();

parent.getChildren();

parent.getFullName(); // предполагая паттерн декоратора в игре

if (person.hasRole(EMPLOYEE)) {

...

}

И так далее.

Если область применения переменной ограничена (например, инкапсулирующий метод состоит из 10-15 строк), я могу даже использовать 'p' вместо 'person'. Короткие имена переменных меньше отвлекают, когда вы пытаетесь удержать в голове контекст. Избегайте ненужных префиксов, таких как 'a' или (вздрогните) венгерской нотации и ее ответвлений. (Разумеется, я ничего не имею против таких префиксов, если они используются в соответствующем контексте - C++ / COM / ATL / Win32 API код и т.д., где это помогает сохранить назначение / типизацию).

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