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

Закрыто . Этот вопрос основан на мнении . В настоящее время он не принимает ответы.

Хотите улучшить этот вопрос? Обновите вопрос, чтобы ответить на него фактами и цитатами, отредактировав этот пост .

Закрыто 6 лет назад .

Я смотрю видео на C # о переменных. Автор объявляет переменную внутри метода и называет ее так: string MyName = "James";

Мой вопрос: какое соглашение рекомендуется .Net Framework. Это корпус Паскаля, как в приведенном выше примере, или верблюжий?

c# coding-standards variables conventions

— Кейзер
источник

Проблема с этим вопросом, о которой вы не знали, так что это не ваша вина, заключается в том, что на самом деле не существует канонического соглашения для C #. Есть общие соглашения; к сожалению, больше, чем один, но вам будет довольно сложно получить здесь ответ, который не является чистым мнением. Извините, голосование закрыто; Мое предложение: потратьте некоторое время на чтение кода в популярных репозиториях github и codeplex, чтобы увидеть, какие соглашения они используют, поскольку люди, которые пишут большинство популярных, являются опытными в отрасли людьми и настолько же каноническими, что и обычное, как вы найдете.

— Джимми Хоффа

Соглашения об именах из MSDN - msdn.microsoft.com/en-us/library/xzf533w0(v=vs.71).aspx

— Юсубов

@Yusubov Они описывают наименование открытых частей библиотек, а не локальных переменных.

— svick

Ответы:

Я не думаю, что есть что-то вроде «официальной» конвенции. Насколько я знаю, многие опытные разработчики C # считают хорошей практикой следующее:

PascalCase for public member variables (string MyName = "James")

camelCase for local variables (string myName = "James")

_leadingUnderscore for private member variables (string _myName = "James")

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

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

— glaed
источник

+1 Это близко к стилю, который я видел. Я полагаю, что это, как правило, взято из стиля, используемого в примерах MSDN. Обычно я вижу, как получают недвижимость, получают PascalCaseместные жители и получают camelCaseчастные члены _leadingUnderscore.

— KChaloux

Вы имеете в виду поля или свойства, когда говорите переменные-члены?

— Kaser

Delphi разработчики , как правило , к параметрам имя функции / метода, предваряя их с «а»: (aParameter: string). Я понимаю, что параметры по сути являются локальными переменными, особенно когда они передаются по значению, но часто очень полезно «увидеть», что переменная фактически передается в качестве параметра. Есть ли такое соглашение в C #?

— Марьян Венема

И еще один: член поля. Дельфийцы ставят им префикс «F». Я видел C # код, объявляющие их с подчеркиванием: private string _SomeString. Вы бы сказали, что это конвенция? (Просто погружаю мои пальцы в C # и задаюсь вопросом об этом материале).

— Марьян Венема

Это неточно. Существуют опубликованные соглашения об именах для публичных участников (и публичных классов и т. Д.).

— svick

Соглашения об именах .Net Framework ( v4.5 , v1.1 ) об этом не говорят. Они не определяют стандарт для именования локальных переменных. Вы должны будете принять решение о присвоении им имен.

Я лично использую camelCase и устраняю неоднозначность переменных-членов по именам параметров thisпри необходимости. Но ведущие подчеркивания (то есть _memberVariable) также действительны.

— Роберт Харви
источник

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

— Синатр