Паскаль или корпус Camel для кода С#?
Я спорил с моими коллегами о корпусе Паскаля (верхний верблюд) против нижнего CamelCasing. Они используются для снижения верблюжьей оболочки для всего, от имен таблиц в базах данных SQL до присвоения имени в коде С#, но мне больше нравится корпус Pascal, нижний корпус верблюда для переменных и корпус Pascal для свойств:
string firstName;
public string FirstName {
...
}
Но они используются для этого:
string _firstname;
public string firstName {
...
}
Я стараюсь идти в ногу со своим "стандартом", поэтому код выглядит одинаково, но мне это просто не нравится.
Я видел, что по крайней мере .NET Framework использует это соглашение, и именно так я пытаюсь сохранить свой код, например:
System.Console.WriteLine("string")
Что вы используете/предпочитаете и почему? Извините, если кто-то другой задал этот вопрос, но я искал и ничего не нашел.
Update:
Я привел пример метода, а не свойство, но он то же самое. Как я уже сказал в первом абзаце, мои коллеги используют соглашение Pascal для всех (переменные, методы, имена таблиц и т.д.).
Ответы
Ответ 1
Я использую то, что использует Framework, поскольку это де-факто лучшая практика. Однако, пока код в вашей компании последовательно, используя свой стиль, вам гораздо лучше привыкнуть к нему. Если у каждого разработчика есть свой собственный стандарт, тогда вообще нет стандарта.
Ответ 2
Ссылка на официальный рекомендации по дизайну может помочь. В частности, прочитайте раздел стили капитализации.
В великой схеме вещей Паскаль против Верблюда не имеет большого значения, и вы вряд ли убедите кого-либо вернуться к существующей кодовой базе, чтобы изменить случай имен. Что действительно важно, так это то, что вы хотите быть последовательным в пределах определенной базы кода.
Я просто счастлив, пока вы не используете венгерский язык.
Ответ 3
Вам нужно взглянуть на новый инструмент Microsoft, StyleCop для проверки исходного кода на С#.
Также следите за FxCop для проверки скомпилированных сборок .Net. FxCop фокусируется больше на деталях того, что делает код, а не на макете, но у него есть некоторые правила именования, связанные с общедоступными именами.
StyleCop определяет стандарт кодирования, который в настоящее время продвигается Microsoft как отраслевой стандарт. Он проверяет исходный код С# на стандарт.
StyleCop придерживается вашего стиля PascalCase.
Получение людей на StyleCop (или любой другой стандарт, если на то пошло) может быть трудным, это довольно затруднительно, и StyleCop довольно исчерпывающий. Но код должен соответствовать единому стандарту - и личный стандарт лучше, чем ни один, стандарт компании лучше, чем личный, и лучший отраслевой стандарт.
Гораздо легче убедить людей, когда начинается проект - формируется команда, и нет существующего кода для преобразования. И вы можете поместить инструменты (FxCop, StyleCop) на место, чтобы сломать сборку, если код не соответствует стандартам.
Вы должны использовать стандарт для языка и фреймворка - код SQL должен использовать стандарты SQL, а код С# должен использовать стандарты С#.
Ответ 4
Для общедоступных интерфейсов вы должны придерживаться шаблона MS.NET framework
руководящие принципы: "" Соглашения о капитализации".
Для незащищенных участников, то, что вы и ваши коллеги можете договориться.
Ответ 5
I (и моя команда) предпочитают резервировать начальные капиталы для имен классов.
Почему? Я думаю, что стандарты Java распространяются.
Ответ 6
С
Руководство разработчика .NET Framework
Соглашения о капитализации, Чувствительность к регистру:
Существуют руководящие принципы капитализации исключительно для упрощения идентификации читать и распознавать. Корпус не может быть используется как способ избежать имени столкновений между элементами библиотеки.
Не предполагайте, что все программирование языки чувствительны к регистру. Они есть не. Имена не могут отличаться в каждом случае в одиночку.
Ответ 7
Я только что нашел Стандарты кодирования для .Net.
Ответ 8
Паскаль должен использоваться для свойств. Что касается разновидностей имен, некоторые люди используют _ и некоторые poeple используют m_, а некоторые люди просто используют обычный старый верблюд. Я думаю, что до тех пор, пока вы будете здесь постоянными, это не имеет значения.
Ответ 9
Этот пример .NET, который вы опубликовали, является функцией. Принятым "стандартом" для методов/функций является закрытый верблюжый футляр (или Pascal, если вы хотите его назвать).
Я придерживаюсь случая верблюда, где могу. Это позволяет вам легко узнать разницу между переменной и методом.
Кроме того, я поклонник прикрепления подчеркивания перед локальными переменными класса. Например: _localVar
.
Ответ 10
Я предполагаю, что вам приходится мириться с тем, что говорит стандарт кодирования для вашего места работы, насколько бы вам это лично не нравилось. Возможно, однажды в будущем вы сможете диктовать свои собственные стандарты кодирования.
Лично мне нравятся базы данных для использования имен форм "fish_name", "tank_id" и т.д. для таблиц и полей, тогда как эквивалент кода модели базы данных будет "fishName" и "tankID". Мне также не нравится имя "_fooname", когда доступно "fooName". Но я должен повторить, что это субъективно, и у разных людей будут разные представления о том, что хорошо и плохо из-за их предыдущего опыта и образования.
Ответ 11
Собственно, на этом нет "стандартного" соглашения. Там где-то отредактировано Microsoft, и, как и в случае с любым другим соглашением о назначении именования, наверняка есть другой, опровергающий его, но вот что я понял, как "стандартное соглашение об использовании С#".
- PerWordCaps в именах типов (классы, перечисления), константы и свойства.
- camelCase для очень длинных локальных переменных и защищенных/закрытых переменных
- Нет ALL_CAPS когда-либо (ну, только в компиляторе определяется, но не в вашем коде)
- Кажется, что некоторые из системных классов используют подчеркнутые имена (_name) для частных переменных, но я предполагаю, что это происходит из исходного фона автора, поскольку большинство из них поступает прямо из С++. Также обратите внимание, что VB.NET не чувствителен к регистру, поэтому вы не сможете получить доступ к защищенным переменным, если вы расширили класс.
Собственно, FxCop будет применять некоторые из этих правил, но (AFAIK) игнорирует любое правописание, которое вы используете для локальных переменных.
Ответ 12
Мне нравятся соглашения о кодировании, изложенные в Aardvark'd project spec
Ответ 13
В тот день, когда я прекратил программирование - это когда Microsoft сделает CamelCase в С# стандартом. Поскольку у моей развитой логики есть много причин для PascalCase, в отличие от логики малыша, кто заботится только о более коротких именах или легче писать.
И BTW: CamelCasing поставляется в основном из стиля библиотеки С++ STD, родного старого языка, унаследованного от C. So Java, унаследованного от С++. Но С# - это совершенно новый язык - чистый и красивый, с новыми правилами. Oldfags должны программировать на Java или С++, люди нового поколения должны программировать на С# - и они никогда не должны взаимодействовать.
Рассмотрим этот пример:
1) PascalCase: list.Capacity.ToString();
2) CamelCase: list.capacity.toString();
В (1) у нас есть CAMEL CASE в долгий срок! означает listCapacityToString.
В (2) у нас есть ерунда: listcapacitytoString.
Вот как я читаю. И почему CamelCase нелогичен для itselt. Я могу убить для PascalCase, никогда не прикасаться к нему, дети любого возраста.
Microsoft - навсегда или пока они не будут использовать PascalCase.
Ответ 14
В зависимости от того, что вы предпочитаете, важно то, что важно, прежде всего, в соответствии с стандартом команды.
В приватном коде вы, однако, хотите, он не влияет на готовый продукт, вы указали свою переменную someVariable или SomeVariable.