Корпус Pascal или корпус Camel для кода C#?

Question

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

string firstName; 
public string FirstName { 
... 
} 

Но они используются к этому:

string _firstname; 
public string firstName { 
... 
} 

Я стараюсь не отставать от своих «стандарт», так что код выглядит так же, но я просто не нравится.

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

System.Console.WriteLine("string") 

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

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

Answer 1

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

Answer 2

I (и моя команда) предпочитают резервировать начальные капиталы для имен классов.

Почему? Я думаю, что стандарты Java распространяются.

Answer 3

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

Answer 4

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

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

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

Answer 5

Для общедоступных интерфейсов вы должны придерживаться шаблона MS .NET framework : «Capitalization Conventions».

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

Answer 6

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

Лично мне нравятся базы данных, которые используют имена форм «fish_name», «tank_id» и т. Д. Для таблиц и полей, тогда как эквивалент кода модели базы данных будет «fishName» и «tankID».Мне также не нравится имя «_fooname», когда доступно «fooName». Но я должен повторить, что это субъективно, и у разных людей будут разные представления о том, что хорошо и плохо из-за их предыдущего опыта и образования.

Answer 7

Ссылка для официальной информации design guidelines может помочь. В частности, прочтите раздел на странице Capitalization styles.

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

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

Answer 8

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

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

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

Answer 9

мне нравятся правила кодирования, изложенные в Aardvark'd проекта спецификации

Answer 10

Вы должны взглянуть на новый инструмент Microsoft, StyleCop для проверки исходного кода C#. Также следите за FxCop для проверки скомпилированных сборок .Net. FxCop фокусируется больше на деталях того, что делает код, а не на макете, но в нем есть некоторые правила именования, связанные с общедоступными именами.

StyleCop определяет стандарт кодирования, который в настоящее время продвигается Microsoft как отраслевой стандарт. Он проверяет исходный код C# на стандарт. StyleCop придерживается вашего стиля PascalCase.

Получение людей на StyleCop (или любой другой стандарт в этом отношении) может быть трудным, это довольно сложное препятствие, а StyleCop довольно исчерпывающий. Но код должен соответствовать единому стандарту - и личный стандарт лучше, чем ни один, стандарт компании лучше, чем личный, и лучший отраслевой стандарт.

Гораздо проще убедить людей, когда начинается проект - команда формируется, и нет существующего кода для преобразования. И вы можете поместить инструменты (FxCop, StyleCop) на место, чтобы сломать сборку, если код не соответствует стандартам.

Вы должны использовать стандарт для языка и фреймворка - код SQL должен использовать стандарты SQL, а код C# должен использовать стандарты C#.

Answer 11

С разработчика .NET Framework Руководство Capitalization Conventions, чувствительность к регистру:

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

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

Answer 12

Я только что нашел Coding Standards for .Net.

Answer 13

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

И BTW: CamelCasing поставляется в основном из стиля библиотеки C++ STD, родного старого языка, унаследованного от C. Так Java, унаследованного от C++. Но C# - это совершенно новый язык - чистый и красивый, с новыми правилами. Oldfags должны программировать на Java или C++, люди нового поколения должны программировать на C# - и они никогда не должны взаимодействовать.

Рассмотрите этот пример: 1) PascalCase: list.Capacity.ToString(); 2) CamelCase: list.capacity.toString();

В (1) у нас есть CAMEL CASE в долгий срок! означает listCapacityToString. В (2) у нас есть ерунда: listcapacitytoString.

Thats, как я читаю. И почему CamelCase нелогичен для itselt. Я могу убить для PascalCase, никогда не прикасаться к нему, дети любого возраста.

Microsoft - навсегда или пока они не используют PascalCase.

Answer 14

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