[C#] Паскаль или корпус Camel для кода C #?


Answers

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

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

Я просто счастлив, пока вы не используете венгерский язык.

Question

Я спорил с моими коллегами о корпусе Паскаля (верхний верблюд) против более низкого CamelCasing . Они используются для снижения верблюжьей оболочки для всего, от имен таблиц в SQL-базах до присвоения наименованию в коде C #, но мне больше нравится корпус Pascal, нижний корпус верблюда для переменных и корпус Pascal для свойств:

string firstName;
public string FirstName {
...
}

Но они привыкли к этому:

string _firstname;
public string firstName {
...
}

Я стараюсь идти в ногу со своим «стандартом», поэтому код выглядит одинаково, но мне это не нравится.

Я видел, что по крайней мере .NET Framework использует это соглашение, и именно так я пытаюсь сохранить свой код, например:

System.Console.WriteLine("string")

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

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




Из .NET Framework Руководство разработчика Соглашения о капитализации , чувствительность к регистру:

Руководства по капитализации существуют исключительно для упрощения чтения и распознавания идентификаторов. Корпус не может использоваться как средство избежать столкновений имен между элементами библиотеки.

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




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

  1. PerWordCaps в именах типов (классы, перечисления), константы и свойства.
  2. camelCase для действительно длинных локальных переменных и защищенных / частных переменных
  3. Нет ALL_CAPS когда-либо (ну, только в компиляторе определяет, но не в вашем коде)
  4. Кажется, что некоторые из системных классов используют подчеркнутые имена (_name) для частных переменных, но, я думаю, это происходит из исходного текста автора, поскольку большинство из них вышло прямо из C ++. Также обратите внимание, что VB.NET не чувствителен к регистру, поэтому вы не сможете получить доступ к защищенным переменным, если вы расширили класс.

Фактически, FxCop будет применять некоторые из этих правил, но (AFAIK) он игнорирует любое правописание, которое вы используете для локальных переменных.




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




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




Для общедоступных интерфейсов вы должны придерживаться руководящих принципов проектирования MS .NET: « Соглашения о капитализации ».

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




Этот пример .NET, который вы опубликовали, является функцией. Принятый «стандарт» для методов / функций - это ограниченный верблюжий случай (или Pascal, если вы хотите его назвать).

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

Кроме того, я поклонник прикрепления подчеркивания перед локальными переменными класса. Например: _localVar .