Есть ли учебники о том, как назвать переменные?

Question

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

Answer 1

я рекомендую проверить эту книгу альтернативный текст http://ecx.images -amazon.com / images / I / 51PPS4C6i8L._BO2,204,203,200_PIsitb-sticker-arrow-click, TopRight, 35, -76_AA300_SH20_OU01_.jpg http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/ref=sr_1_1?s=books&ie=UTF8&qid=1281129036&sr=1-1

Answer 2

Я не думаю, что будут какие-то хорошие учебники, потому что нет никаких жестких правил. Вот несколько советов:

• Соответствует соглашению: переменные цикла: i, j и k; переменные номера аргументов идут в *args и **kwargs; используйте camelCase или underscored_names.

• Будьте последовательны.

• Будь лаконичен. list_of_drugs_used_in_this_program гораздо менее ясно, чем drugs. Точно так же вам не нужно включать тип имени переменной в имя: drugs_list является избыточным.

• Не переборщите с подчеркиванием. Мне никогда не нужно больше, чем один. 2+ толкает его.

• Никогда когда-либо никогда использовать метасинтаксические переменные (foo, spam ...) во всех, кроме простых и грязных примерах. method1 также отсутствует.

Но вы могли бы обобщить все это с помощью:

Не будь глупым.

---

Ти хи.

Соглашения об именовании переменных часто могут превратиться в религиозную войну, но я полностью уверен, когда я объявляю Имя худшей переменной в мире будет:

$data

Конечно, это данные! Это то что переменные содержат! Это все, что они когда-либо может содержать. Как будто ты собирать вещи, чтобы переехать в новый дом, и на стороне ящик, который вы пишете, большим черным маркером, «Дело.»

http://www.oreillynet.com/onlamp/blog/2004/03/the_worlds_two_worst_variable.html

Answer 3

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

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

1. Для коллекций используйте множественное число на естественном языке.На английском языке это означает, что данные, схемы, дети, индексы, критерии, формулы (и даже фокусы, гуси, ноги, мужчины, женщины, зубы) не являются выдуманными словами, такими как базовые схемы, дочерние элементы, индексы, критерии, формулы (и аналогичнофокусы, гуси, ноги, мужчины, женщины, зубы, верьте этому или нет, но я действительно видел некоторых из них в использовании).Оболочка верблюдов и аббревиатура наносят достаточный урон английскому как таковому, не делая больше.Хорошо, я никогда не видел датумов, но я видел мета-множественные данные.Милая Арадия, почему?
2. Тем не менее, используйте американский английский для имен, даже если вы используете другой диалект английского языка.Большинство программистов с такими диалектами научились думать о «цвете» как о значении цвета в компьютерном контексте к 12 годам, и этот принцип применяется более широко.Если мы можем иметь дело с «цветом» (одной из худших убастеризаций Вебстера), мы можем иметь дело с -ize и -ization (-ise и -isation - это псевдофранцузская аффектация 18-го C в любом случае, американцы являются традиционалистами в этом).
3. Точно так же, если вы не знаете, как правильно написать слово, которое вы используете как целое или часть имени, найдите его (посмотрите в Google и посмотрите, что говорит Google).Кто-то может провести долгое время, отвлекаясь на вашу орфографическую орфографию, которая настолько свободно распределена по всему исполняемому коду, что затрудняет ее исправление.
4. Венгерский язык плох (во многих современных языках, хотя в некоторых он имеет свое место), ноПринцип это хорошо.Если вы можете отличить const, static, instance, local и переменную параметра друг от друга за доли секунды, это хорошо.Если вы можете сразу сказать что-то о намерении, это тоже хорошо.
5. С этим связано _ перед тем, как публичные переменные сделают их не совместимыми с CLR.На самом деле это хорошо для частных переменных (если вы сделаете их общедоступными для быстрого эксперимента и забудете исправить видимость, компилятор предупредит вас).
6. Помните Закон Постеля, «будьте осторожны в своих действияхБудьте либеральны в том, что вы принимаете от других ".Один из примеров этого - действовать так, как будто вы используете язык с учетом регистра, даже если вы используете регистр без учета регистра.Связанный должен быть больше приверженцем публичных имен, чем личными.Еще одно - уделять больше внимания соблюдению конвенций, а не жаловаться на тех, кто этого не делает.

Answer 4

Все ответы здесь вполне допустимы. Самое главное: быть последовательным.

Тем не менее, вот мои правила (C #):

• идентификаторы camelCase - лично я найти это гораздо проще, чем читать подчеркивания
• Public свойства начинаются с большой буквы
• что-то я никогда не должен трогать начинается с Подчеркивание - пример, поддержка поле для свойства должно быть только тронут от собственности. Если у меня есть подчеркивает в другом месте, я знаю, что я неправильно
• Apps Венгерский, где соответствующий - целые числа, описывающие строку Идентификаторы, возможно, могут быть названы rowSelected, rowNextUnread и др. так далее. Это отличается от Системы венгерские, которые бы обозначали их как целые, такие как iSelected, iNextUnread. Системы венгерские не добавляет много, если что-нибудь, где Apps венгерский дает информацию Тип не: он говорит мне, добавляя rowItemsPerPage и colSelected является бессмысленная операция, даже если она компилируется просто отлично.

Answer 5

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

Каждое имя переменной должно быть релевантным для любых данных.хранится в переменной.

Ваша схема именования должна быть непротиворечивой .

Таким образом, основным нет-нет будут переменные из одной буквы (некоторые люди используют i и j для индексации циклов,это нормально, потому что каждый программист знает, кто они. Тем не менее, я предпочитаю «idx» вместо «i»).Также есть такие имена, как 'method1', это ничего не значит - оно должно указывать, что содержит переменная.

Другое (менее распространенное) соглашение - это нотация "венгерский", в которой тип данных имеет префикс перед именем переменной, напримеркак 'int i_idx'.Это совершенно бесполезно в современных объектно-ориентированных языках программирования.Не говоря уже о вопиющем нарушении принципа СУХОЙ.

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

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

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

Answer 6

Привет, мне всегда следует указывать самые явные имена:

string_to_hash = "blabla"
hash(sring_to_hash)

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

Answer 7

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

Answer 8

Не учебник ... больше похоже на руководство / лучшую практику:http://msdn.microsoft.com/en-us/library/xzf533w0(VS.71).aspx

Answer 9

Вы прочитали Code Complete?Он делает полный трактат об этом в книге.Определенно лучшая стратегия именования, которую я видел в печати ... И легко найти около 1000 программистов, которые называют это одним из 5 лучших ресурсов для программистов и разработки программ.

Простомои $ .05

Answer 10

Вы не указали, какой язык вы ищете.Поскольку ваш вопрос помечен .NET, вот документ, которому я следую при написании кода C #: http://weblogs.asp.net/lhunt/pages/CSharp-Coding-Standards-document.aspx.