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

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

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

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

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

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

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

Что касается

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

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

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

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 гласят:

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

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

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

В 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-компилируемый код.

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

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

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

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

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

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

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

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

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

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

sDI

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

someDescriptiveIdentifier

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

someDescriptiveName, someOtherDescriptiveName, someOtherButNotTheSameDescriptiveName

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

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

someDescriptiveIdentifier

или же

_someDescriptiveClassMember

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