Как назвать переменные

Question

• Какие правила вы используете для именования ваших переменных?
• Где разрешено использование одной буквы?
• Как много информации вы указали в названии?
• как, например, код?
• какие ваши предпочтительные бессмысленные имена переменных? (после foo & bar)
• почему они пишутся "foo" и "bar" , а не FUBAR

Answer 1

Правила, которых я придерживаюсь;

Описывает ли имя полностью и точно, что представляет переменная?

Относится ли название к реальной проблеме, а не к решению на языке программирования?

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

Определители вычисленных значений, если таковые имеются, в конце имени?

Они специально созданы только в той точке, которая требуется?

Answer 2

Какие правила вы используете для именования ваших переменных? camelCase для всех важных переменных, CamelCase для всех классов

Где разрешены однобуквенные переменные? В конструкциях циклов и в математических функциях, где однозначное имя переменной соответствует математическому определению.

Как много информации вы указали в названии? Вы должны быть в состоянии прочитать код как книгу. Имена функций должны сообщать вам, что делает функция (scalarProd (), addCustomer () и т. Д.)

Как насчет, например, кода?

каковы ваши предпочтительные бессмысленные имена переменных? (после foo & bar) temp, tmp, input, я никогда не использую foo и bar.

Answer 3

Я научился никогда не использовать однобуквенные имена переменных в мои дни VB3. Проблема в том, что если вы хотите искать везде, где используется переменная, то поиск по одной букве будет довольно трудным!

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

for (int firstStageRocketEngineIndex = 0; firstStageRocketEngineIndex < firstStageRocketEngines.Length; firstStageRocketEngineIndex++)
{
  firstStageRocketEngines[firstStageRocketEngineIndex].Ignite();
  Thread.Sleep(100);  // Don't start them all at once. That would be bad.
}

Answer 4

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

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

За некоторыми исключениями (венгерская нотация), я думаю, последовательное использование может быть более полезным, чем любой произвольный набор правил. То есть каждый раз делай так же.

.

Answer 5

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

// это моя строковая переменная $ strVar = "";

// это будет представлять массив $ arrCards = array ();

// это целое число $ intTotal = NULL:

// объект $ objDB = new database_class ();

// булево $ blValid = true;

Answer 6

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

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

Answer 7

Мне нравится добавлять мои переменные в префиксы: str = String, int = Integer, bool = Boolean и т. Д.

Использование одной буквы быстро и просто в циклах: для i = от 0 до 4 ... цикл

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

Foo & Bar используются для примера кода, чтобы показать, как работает код. Вместо этого вы можете использовать практически любые другие бессмысленные символы. Я обычно просто использую i, x, & y.

Мое личное мнение о foo bar против fu bar таково, что это слишком очевидно, и никто не любит 2-символьные переменные, 3 намного лучше!

Answer 8

В DSL и других свободно распространяемых интерфейсах часто имена переменных и методов, взятые вместе, образуют лексическую сущность. Например, мне лично нравится (по общему признанию еретика) шаблон именования, в котором глагол помещается в имя переменной, а не в имя метода. @see 6-е правило именования переменных

Также мне нравится спартанское использование $ в качестве имени переменной для основной переменной фрагмента кода. Например, класс, который довольно печатает древовидную структуру, может использовать $ для экземпляра StringBuffer inst. @see Это многословно!

В противном случае я обращаюсь к разговорнику программиста Эйнара Хоста. @ смотри http://www.nr.no/~einarwh/phrasebook/

Answer 9

Обновлено

Во-первых, наименование зависит от существующих соглашений, будь то язык, инфраструктура, библиотека или проект. (В Риме ...) Пример: используйте стиль jQuery для плагинов jQuery, используйте стиль Apple * для приложений iOS. Первый пример требует большей бдительности (поскольку JavaScript может стать беспорядочным и не проверяться автоматически), в то время как второй пример проще, так как стандарт хорошо соблюдается и соблюдается. YMMV в зависимости от лидеров, сообщества и особенно инструментов.

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

---

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

• Удобочитаемость - важные части должны иметь сплошные названия; но эти имена не должны заменять надлежащую документацию intent . Тест на читабельность кода заключается в том, что вы можете вернуться к нему несколько месяцев спустя и при этом быть достаточно понимающим, чтобы не бросить все это на первый взгляд. Это значит избегать аббревиатур; см. дело против венгерской нотации .

• Возможность записи - общие части и шаблон должны быть простыми (особенно если нет IDE), поэтому писать код проще и веселее. Это немного вдохновлено стилем Роба Пайка .

• Обслуживаемость - если я добавлю тип к своему имени, например arrItems, то будет плохо, если я изменю это свойство на экземпляр класса CustomSet, который расширяет Array. Типовые примечания должны храниться в документации и только при необходимости (для API и т. П.)

• Стандарт, общее наименование - Для тупых сред (текстовые редакторы): классы должны быть в ProperCase, переменные должны быть короткими и, если необходимо, должны быть в snake_case, а функции должны быть в camelCase.

---

Для JavaScript это классический случай ограничений языка и инструментов, влияющих на именование. Это помогает отличать переменные от функций по разным именам, поскольку нет IDE, чтобы держать вас за руку, в то время как this и prototype и другие шаблоны затеняют ваше зрение и сбивают с толку ваши навыки дифференцирования. Также нередко видеть, что все несущественные или глобально полученные переменные в области видимости сокращаются. В языке нет import [path] as [alias];, поэтому локальные переменные становятся псевдонимами. И затем есть множество различных условных обозначений. Единственное решение здесь (и где угодно, на самом деле) - надлежащая документация о намерениях (и личности).

Кроме того, сам язык основан на области действия и замыканиях на уровне функций, поэтому из-за некоторой гибкости блоки с переменными в уровнях уровня 2+ могут выглядеть очень грязными, поэтому я видел название, в котором _ добавляется для каждого уровень в цепочке областей действия к переменным в этой области.

Answer 10

местные жители: fooBar; члены / типы / функции FooBar интерфейсы: IFooBar

Что касается меня, отдельные буквы действительны, только если название классическое; i / j / k только для индексов локальной петли, x, y, z для векторных частей.

переменные имеют имена, которые передают значение, но достаточно короткие, чтобы не переносить строки

Foo, бар, Баз . Рассол также любимый.