Как сокращать имена переменных [закрыто]

Я всегда борюсь с аббревиатурой имен переменных. Есть ли какой-либо стандарт для сокращения имен переменных?

6 голосов | спросил Huzaifa 30 AMpSat, 30 Apr 2011 02:38:30 +040038Saturday 2011, 02:38:30

6 ответов


64

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

ответил Rein Henrichs 30 AMpSat, 30 Apr 2011 02:49:38 +040049Saturday 2011, 02:49:38
12

Я не программист на C #, поэтому я не могу дать вам много советов о соглашениях C #. Но у меня есть некоторые мысли об аббревиатурах.

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

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

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

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

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

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

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

ответил T Duncan Smith 30 AMpSat, 30 Apr 2011 02:52:00 +040052Saturday 2011, 02:52:00
2

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

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

ответил 30 AMpSat, 30 Apr 2011 02:43:55 +040043Saturday 2011, 02:43:55
2

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

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

классическая книга Стив Макконнелла Code Complete отлично подходит для таких вещей.

ответил Richard 30 AMpSat, 30 Apr 2011 03:02:02 +040002Saturday 2011, 03:02:02
2

Если у вас есть сомнения, укажите это.

Точка имени переменной так, чтобы смысл кода был более понятным. Если аббревиатура очень очевидна, тогда вы можете просто использовать наименьшую возможную. Имена переменных и имена функций обычно являются единственными битами человеческого языка в коде и поэтому действуют как «ориентиры» для человеческого глаза, чтобы найти соответствующие части кода (или, в большой базе кода, такие инструменты, как grep или ack), а также как подсказки для понимания.

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

Это нормально сокращать, когда ...

... Когда сокращенная форма используется на устном или письменном английском языке не только людьми, работающими над вашим проектом (многие словари предоставляют такую ​​информацию рядом с термином, который они определяют).

var extensible_markup_language_element; // don't do this
var xml_element; // better
var element; // possible if the name of the function or the documentation make it clear you're dealing with XML and not the periodic table
docs.toString(); // most people capable of reading code know docs == documentation

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

var auth = user.auth;
if (auth) // If the user is authenticated?
          // If the user is authorised to do something?
          // If the authentication function exists for that user group?
          // If some setting called auth is turned on for that user?
          // If the user is the author of the document in question?
          // If the user has some authority?

var attrNames = retrieveAttrs();
if (attrNames)  // hm, attrNames sounds like an array of strings - which will be boolean true even if empty - this if looks like a bug!

const MDF // author is writing an iOS app for ordering hand-carved artisanal fibreboard so anyone familiar with the problem domain knows this has plainly nothing to do with Microsoft Database Files. Though maybe the first time it comes up in the code the author should perhaps still put its full name

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

foreach $i (1..10) { say $announcement->[$i] }

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

some_command --transaction-message "Done" # a bit wordy - keep, but ALSO allow for convenience:
some_command --msg "Done" # might be useful
some_command -m "Done"    # if you can spare -m

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

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

... Когда вы работаете над созданным проектом, который имеет несколько вкладчиков и руководство по стилю, которое требует сокращений. В этом случае сократите только в соответствии с руководством по стилю, но обратите внимание на проблемы и будьте готовы комментировать комментарии (например, «это список имен атрибутов в виде строк»).

  

Типы должны заканчиваться на «_t»; Определения исходной структуры в «_struct»

     

- https://metacpan.org/source/SHLOMIF/XML -LibXML-2.0117 /HACKING.txt

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

ответил user52889 2 Jam1000000amFri, 02 Jan 2015 01:16:10 +030015 2015, 01:16:10
0

Мы сокращаем переменные, чтобы перестать печатать большие переменные, но в то же время сокращенная переменная должна быть достаточно явной, чтобы вы могли понять, что она держит, а не возвращаться туда, где она была объявлена ​​или была создана вначале. Так, например:

int accountBalanceInSavings

- > может быть сокращено до

int accBalInSaving

--- > но сокращая его до

int accBal

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

ответил Gaurav Sehgal 30 AMpSat, 30 Apr 2011 07:46:44 +040046Saturday 2011, 07:46:44

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132