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

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

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

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

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

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

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

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

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

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

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

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

Ссылка на официальный рекомендации по дизайну может помочь. В частности, прочтите раздел о Стили заглавных букв.

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

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

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

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

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

Мне нравятся соглашения о кодировании, изложенные в спецификации проекта Муравьед

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

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

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

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

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

Из Руководство разработчика .NET Framework Условные обозначения заглавных букв, чувствительность к регистру:

The capitalization guidelines exist solely to make identifiers easier to read and recognize. Casing cannot be used as a means of avoiding name collisions between library elements.

Do not assume that all programming languages are case-sensitive. They are not. Names cannot differ by case alone.

Я только что нашел Стандарты кодирования для .Net.

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

И, кстати, 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.

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

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

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