Может кто-нибудь объяснить мне соглашение о кодировании в C #?


14

Недавно я начал работать с Unity3D и в основном писал сценарии на C #. Поскольку я обычно программирую на Java, различия не так уж и велики, но я все же сослался на ускоренный курс, чтобы убедиться, что я на правильном пути.

Тем не менее, мое самое большое любопытство к C # заключается в том, что он использует заглавные буквы в именах своих методов (например, Java: getPrime()C #: GetPrime()aka: Pascal Case?). Есть ли для этого веская причина? На странице ускоренного курса я понимаю, что, по-видимому, это соглашение для .Net, и я никак не могу его изменить, но мне любопытно услышать, почему это было сделано в отличие от обычного (относительного?) Случая с верблюдом. что, скажем, Java использует.

Примечание: я понимаю, что у языков есть свои собственные соглашения о кодировании (все методы Python строчные, что также применимо в этом вопросе), но я так и не понял, почему это не формализовано в стандарт.


18
Я действительно не думаю, что вы можете посмотреть на camelCaseи PascalCaseи underscore_caseсказать, что один из них нормальный (даже относительно нормальный), а другие нет. Как сказал @dasblinkenlight, это произвольный выбор. Единственное, что заставляет вас думать, что соглашение C # необычно, это то, что вы «обычно программируете на Java» и, таким образом, привыкли к произвольному выбору, сделанному для Java.
— Carson63000

Используйте JavaScript вместо .. для Unity3D :)
— Lipis

@Lipis Почему - кроме личного вкуса? ;-)
— выходной

@AedonEtLIRA совершенно личное ... неважно :) Наслаждайтесь Unity независимо от того, на каком языке ... вы в конечном итоге будете использовать ...
— Lipis

@Lipis Пока все отлично. Тонны наворотов, и я еще не уронил деньги на это. Но я предпочитаю структурированный стиль C # (c / c ++) и java.
— выходной

Ответы:


27

Соглашения об именах представляют собой произвольный выбор их издателя. В самом языке нет ничего, что могло бы запретить вам называть ваши методы так, как вы это делаете в Java: если первый символ - это буква / подчеркивание, а все остальные символы - это буквы, цифры или подчеркивание, C # не собирается жаловаться. Однако библиотеки классов, поставляемые с .NET, следуют соглашению, которое Microsoft приняла внутренне. Microsoft также опубликовала эти рекомендации , чтобы другие могли также принять их для своих собственных библиотек классов. Несмотря на то, что вы выбираете следовать или игнорировать указания Microsoft, знакомство с вашим кодом со стороны других пользователей может пройти быстрее, если вы будете следовать тем же правилам именования.


Однако обычно существует какое-то обоснование соглашения, и когда я читаю «Есть ли для этого веские причины?» Я понимаю это как вопрос о том, ПОЧЕМУ НЕ ЧТО.
— Гринольдман

Паскаль для открытых / внутренних / статических членов и всех методов. Верблюд для частного. Это помогает различить область действия токена во время его сканирования. thisКлючевое слово делает то же самое. Выбор стиля практичен, даже если он может казаться чуждым
— Gusdor

23

Возможно, из-за влияния Паскаля / Дельфи. Создатель C # и Delphi в конце концов был одним и тем же человеком (Андерс Хейлсберг).

Соглашения по кодированию Delphi в целом совпадают с C # в этом аспекте; см. http://www.econos.de/delphi/cs.html#ObjectPascal_Procedures или http://wiki.delphi-jedi.org/index.php?title=Style_Guide#Method_Naming - совпадение?


4
+1 для этого, потому что он дает то, что может быть реальной причиной, почему этот конкретный произвольный выбор был сделан для C #.
— Максимус Минимус

4

В дополнение к другим полученным ответам наличие верблюжьего падежа для методов означает, что они могут конфликтовать с именами для закрытых членов, параметров и переменных метода, которые используют верблюжий падеж для своих имен. В Java (и C # 1.0) это не очень распространено, поскольку использование делегатов неудобно и редко. В современном C # это не совсем обычное явление , но это также не неслыханно.


1
Подчеркивание не следует использовать в C # частных полях (см blogs.msdn.com/b/brada/archive/2005/01/26/361363.aspx , например), но это спорно и часто.
— Дженс

1
полагаться на регистр для различения языковых конструкций - это действительно плохая идея, независимо от того, позволяет ли язык вам это делать или нет.
— gbjbaanb

4
@Telastyn это заявление довольно шокирует. Большая часть библиотеки классов .NET использует это соглашение.
— MattDavey

1
@ Данк, как же вдруг мой съезд? Я просто передавал комментарий, у меня нет мнения по этому вопросу в любом случае :)
— MattDavey

2
@MarjanVenema: не знаю, о чем вы говорите, но C # весьма чувствителен к регистру, и вы, конечно же, можете столкнуться между членами в аналогичном корпусе. Это становится забавным и увлекательным, когда у вас есть реальные языки, нечувствительные к регистру, такие как VB.NET, с которыми вы работаете на уровне библиотеки.
— Уайетт Барнетт
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.