Соглашения об именовании переменных? [закрыто]

11

Я только начал использовать ReSharper (для C #), и мне нравится, что его код пахнет искателем, он показывает мне кое-что о моем написании, которое я хотел исправить давным-давно (в основном, соглашения об именах переменных).

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

Второе, что побудило меня переоценить это мои соглашения об именах для обработчиков событий GUI. Я обычно использую стандарт VS ControlName_Action, и мои элементы управления обычно используют венгерскую нотацию (в качестве суффикса, чтобы помочь прояснить в коде, что видно пользователю, а что нет при работе с переменной с аналогичным именем), поэтому я в конечном итоге получаю OK_btn_Click ( ) что вы думаете об этом? Должен ли я уступить соглашению ReSharper или есть другие одинаково действительные варианты?

Зив
источник

Ответы:

19

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

Не позволяйте инструменту определять ваши стандарты - используйте его для реализации своих собственных.

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

mjhilton
источник
Конечно, мне действительно нравится, как это помогает мне контролировать свои локальные переменные, но мне любопытно узнать о стандартах других людей, особенно когда это касается обработчиков событий.
Зив
Достаточно справедливо, я отредактировал, чтобы дать некоторые подробности личного опыта.
Mjhilton
11
+1 за «Не позволяйте инструменту определять ваши стандарты»
techie007
«Не позволяйте инструменту определять ваши стандарты» только что стало одной из моих любимых программных цитат всех времен.
Сегги
18

Что касается

но нужно ли подчеркивание? тебе это удобно?

Одна вещь, которая мне больше всего нравится в использовании подчеркивания, это то, что он значительно сокращает использование «этого».

Рассматривать:

public void Invoke(int size) {
    _size = size;
}

без подчеркивания вы должны написать:

public void Invoke(int size) {
    this.size = size;
}

который потенциально вводит тонкую ошибку:

public void Invoke(int size) {
    size = size;    // urgh ... no this! 
}

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

Что касается

обычно используют венгерские обозначения

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

НЕ используйте венгерские обозначения

Оставляя мало места для двусмысленности :)

Северная Дакота
источник
Строго говоря, если вы следуете Руководству по проектированию структуры, в нем говорится, что переменные, передаваемые в публичные методы, должны быть также прописными, в дополнение к именам методов :)
Surgical Coder
Pzycoman ... не могли бы вы указать мне, где это заявляет. Беглый взгляд, и я не смог найти никаких ссылок на использование прописных в переменных, которые передаются в публичные методы. Но, например, на стр. 118 второго издания приведен пример, когда в публичных методах используются не прописные, а строчные буквы. "public void Write (значение uint);"
Дакота Норт
10
В случае столкновений имен я бы сказал, что this.sizeэто намного яснее, чем _size. Использование подчеркнутого имени не предотвращает скрытую ошибку, вы все равно можете назначить размер себе, хотя, надеюсь, ваш компилятор скажет вам.
edA-qa mort-ora-y
2
Конечно, вы всегда можете назначить что-то себе. Основное различие между this.sizeи _sizeявляется последовательностью. С тем this.size, что это необязательно. Например, если было вызвано другое закрытое поле name, this.nameв коде нет необходимости его использовать , я мог бы так же легко использовать его nameбез каких-либо конфликтов. Потому что thisможет использоваться иногда, а не в других случаях, поэтому использование thisуступает. С другой стороны, нет никакой двусмысленности с _...
Дакота Норт
2
Тьфу ... почему люди все еще используют подчеркивание в языках, которые обеспечивают лучший способ.
Rig
8

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

Ричард
источник
2
+1: выберите соглашение и придерживайтесь его. Все подойдет (кроме систем венгерских).
Donal Fellows
Последовательность не единственная вещь. Например, кто-то может выбрать согласованные соглашения об именах для своего собственного кода, но если это соглашение сильно отличается от других соглашений об именах, то при использовании других библиотек ... неизбежно будут противоречия. Например, если я решу использовать соглашения об именах свойств из C # в Java, я не буду согласен с тем, как код пишется во всех других системах. Я мог бы написать order.Size()(в отличие от order.getSize()), но так как другие библиотеки используют методы получения и установки, мой код не будет согласованным.
Дакота Норт
Очевидно, что за какими-то условностями, которые человек решит использовать, должна быть какая-то разумная мысль, но последовательность - это самое главное.
Ричард
@DakotahNorth - имеет смысл иметь стиль дома, но помимо этого, последовательность является ключевым фактором. Пока соглашение не слишком закулисное, оно может быть легко взято внешними / новыми разработчиками. Действительно, стоит опубликовать домашний стиль, чтобы убрать любую неопределенность.
cjmUK
7

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

Из MSDN:

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

Смотрите: http://msdn.microsoft.com/en-us/library/12a7a7h3.aspx

Здесь вы можете прочитать предупреждение о подчеркивании:

Имена элементов, начинающиеся с подчеркивания (_), не являются частью Спецификации общего языка (CLS), поэтому CLS-совместимый код не может использовать компонент, который определяет такие имена. Однако подчеркивание в любой другой позиции в имени элемента является CLS-совместимым.

Смотрите: http://msdn.microsoft.com/en-us/library/81ed9a62.aspx

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

Но, возможно, это не проблема в вашем случае, если вам не нужен CLS-компилируемый код.

PSUR
источник
4

Мне нравятся подчеркивания. На первый взгляд, вы знаете, что переменная является членом класса и частной.

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

Вы можете использовать ключевое слово "this", но _ короче для лучшей горизонтальной сканируемости. Описательные имена обычно желательны, но когда что-то является установленным соглашением, лучше иметь 1 символ. например, используя букву i в качестве индекса при циклическом просмотре массива. Поскольку существует установленное соглашение о том, что i является индексом, вы получаете преимущество сканируемости, не задумываясь о том, что означает «i».

mike30
источник
1

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

  • Проще установить (просто перейдите по умолчанию, даже я могу нажать Enter 20 раз и начать)
  • Ошибки обычно устраняются из настроек по умолчанию, часто это эзотерическая конфигурация, которую я настроил, которая выявляет дефект впервые
  • Поставщик цепочки инструментов, вероятно, знает об этом больше, чем я, поэтому они сделали это по какой-то причине. Кто я, чтобы решить, что эксперты не правы (я считаю их экспертами, потому что я купил их инструмент)
  • Вам никогда не придется отстаивать выбор поставщиков с помощью менеджера - «Это то, что они рекомендуют»
  • Новый парень не будет задавать вам вопросы «почему» и «так лучше» - когда каждый ответ «потому что они решили ...»

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

Имейте в виду, что каждое изменение имеет постоянную стоимость (реальную и скрытую). Чем меньше, тем ниже стоимость. Например - тот новый парень, которого я упомянул - без изменений означает, что он может прочитать их руководство. Переконфигурируйте - вы должны написать приложение, сохранить его вместе с другими материалами, удалить его и заставить его прочитать его после прочтения их руководства. Может быть, не проблема для магазина на 2 человека, но как насчет магазина на 100 человек?

mattnz
источник
1

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

Суффикс Label, RadioButton и т. Д. Для ваших элементов управления обычно также считается нормой. Часто для одной концепции существует несколько элементов управления (например, Label и TextBox), и этот суффикс весьма полезен. Истинная венгерская нотация давно была заброшена, потому что она была превращена в нечто, что не выражало ее первоначальное намерение, а именно контекст переменной, а не тип, размер и т. Д.

Чарльз Ламберт
источник
1

В моем случае использование верблюда и подчеркивания помогает с описательными (читай: длинными) именами переменных и завершением кода. Я не совсем уверен, как работает автозаполнение Visual Studio, но в QtCreator и, в меньшей степени, в Eclipse, можно напечатать, например,

sDI

и расширить его до

someDescriptiveIdentifier

Сохраняет немного ввода в случае, если у вас есть такие имена, как

someDescriptiveName, someOtherDescriptiveName, someOtherButNotTheSameDescriptiveName

который я склонен производить в «режиме описательного именования».

Используя подчеркивания, я могу определить, какое имя я хочу автозаполнить

someDescriptiveIdentifier

или же

_someDescriptiveClassMember

Надеюсь, мое объяснение достаточно ясно :)

Manjabes
источник