Сокращения в программировании

Question

Иногда, чтобы сделать имя переменной / метода / класса описательным, мне нужно сделать его длиннее. Но я не хочу, я хотел бы иметь короткие имена, которые легко читать. Поэтому я подумал о специальном дополнении к IDE, таком как Visual Studio, которое могло бы писать короткие имена для класса, метода, поля, но иметь возможность добавлять длинные имена. Если вам нужно - вы можете сделать все это длинным или вы можете сделать одно имя длинным. Если вы хотите уменьшить его - используйте сокращение, как два представления одного и того же кода. Я хотел бы знать, что другие думают об этом? Как вы думаете, это полезно? Кто-нибудь будет использовать вид дополнения?

Answer 1

Почему бы просто не использовать стандартную систему комментирования XML, встроенную в Visual Studio. Если вы введете /// над классом / методом / переменной и т. Д., Это создаст заглушку комментария. Эти комментарии всплывают через Intelisense / Code Completion с дополнительной информацией.

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

См .: http://msdn.microsoft.com/en-us/magazine/cc302121.aspx

Answer 2

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

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

Если имя метода слишком длинное, то это не должен быть один метод ...

Я бы не стал использовать такое дополнение.

Answer 3

Я никогда не беспокоюсь о длинных именах. Если имя метода становится слишком длинным, это также может указывать на то, что метод делает слишком много (если в нем не содержится действительно длинное слово). С другой стороны, я также стараюсь не повторяться. Я бы не имел, например, Account.AccountId, а Account.Id. Я также откинулся на пространство имен; если в пространстве имен ясно, в каком домене я нахожусь, я обычно стараюсь не повторять это в именах классов или членов.

Итог; Я не вижу себя использующим такое дополнение.

Answer 4

Другие программисты без этого дополнения могут оказаться в затруднительном положении, потому что, если вы дадите слишком короткие имена, они не будут полностью понимать код, если вы дадите длинные имена, они потеряют время на чтение и со временем разозлятся, потому что длинные имена трудно запомнить: P

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

Я бы не использовал это дополнение.

Answer 5

С ReSharper 4 и выше, вы можете получить автоматическое расширение имен типов и переменных, которые являются верблюжьими или паскальскими:

_{(источник: jetbrains.com )}

Таким образом, вы можете вызвать вашу переменную myExtremelyLongAndDescriptiveVariableName, а затем просто набрать mELADVN, чтобы использовать ее.

Answer 6

Ни я. Дело в том, что вы говорите о VisualStudio. Это требует большой нагрузки на запоминание имен большинства переменных (длинных и коротких) с IntelliSense. Как сказал Пауэр, пока код читабелен и понятен, это все, что имеет значение.

Answer 7

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

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

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

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

ОО-дизайн должен помочь иерархически разбить функциональность на пространства имен и классы, уменьшая потребность в таких длинных именах на уровне класса / метода)

Наконец, если вам действительно нужно сократить имена, большинство языков большинства языков предоставляют простые способы зачистки пространств имен и / или добавления совершенно новых псевдонимов для имен (например, «typedef» и «using» в C ++, «using» в C #) , поэтому в локализованном регионе вы можете легко обратиться к длинному имени через сокращенный вариант или псевдоним, если хотите.

Answer 8

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

Answer 9

Мне бы хотелось иметь короткие имена, которые легко читается.

Это часто противоречие в терминах.

Возьмем, к примеру, имя типа oScBf, если вы еще не знаете, для чего оно практически не читается. Это вывод ScreenScuffer, onlineSourceBitflag, openScannerBrowsefile, outdoorSpecialBikiniflected ...?

Более длинные имена идентификаторов обычно предпочтительнее. Несмотря на то, что это больше для чтения, это еще проще для понимания.

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

Answer 10

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