Я только что узнал, что для частных методов использовать UpperFirstLetterPascalCase() для обычных методов. Я сам себе считаю, что это полностью противоречит правилам именования полей и переменных частного экземпляра, и мне также трудно читать/отлаживать.
Я хотел бы спросить, почему использование первой верхней буквы для методов может быть лучшим выбором, чем первый нижний doThis()? Просто из любопытства...
Это не лучше или хуже. Это просто конвенция.
Все имена методов в С# начинаются с буквы верхнего регистра по соглашению. Все имена свойств также делают это. Только частные поля, локальные переменные и параметры для методов начинаются с строчной буквы (AFAIR).
Это конвенция, в которой просят "почему", немного неуместны. Вероятно, это похоже на вопрос: "Почему конвенция кодирования Java предпочитает строчные буквы для всего, кроме классов?" - ответы на такие вопросы обычно "Потому что кто-то когда-то решил, что было бы неплохо сделать это", Остальное - это просто история или конвенция, и вы либо следуете за ней, либо нет (в этом случае вы делаете жизнь людей, читающих ваш код сложнее).
ETA: Как уже говорилось в комментарии (imho), ответ на вопрос "почему?" обычно приводит к тому, что дизайнеры языка (или люди, придумывающие конвенцию) считают быть важными аспектами, которые должны быть охвачены конвенцией. В Java это явно случай визуального различения классов (PascalCase), переменных/полей (camelCase) и свойств (get ~()/set ~()). Для .NET явно необходимо было сразу рассказать классы и интерфейсы друг от друга (что я считаю довольно приятным) и визуально различать свойства (PascalCase) и поле (camelCase).
Обычно в таких сценариях все вещи, которые изначально не считаются важными для конвенции, не имеют очевидной очевидности.
Таково соглашение об именах для .NET, и это соглашение, согласно которому все стандартные библиотеки .NET следуют. Нет ничего, что требовало бы от вас следовать этому соглашению в вашем собственном коде, но обычно лучше следовать стандартам языка, на котором вы работаете. Лично я предпочитаю lowerCamelCase для UpperCamelCase, но я по-прежнему использую рекомендуемый стиль .NET при написании в С#.
Частные членские переменные обычно обозначаются первой буквой нижнего и нижнего регистра, например. _privateMember. Частные методы следуют тем же соглашениям, что и общедоступные методы.
Одна разница, о которой я мог думать, заключается в том, что она различает локальные переменные делегата и методы, хотя это, вероятно, не намерение. В современных IDE обычно бывает легко узнать, является ли вызов публичным или приватным, в любом случае. Я принимаю соглашения об именах для свойств, полей и переменных, так это то, что они позволяют различать разные формы одного и того же "свойства" следующим образом:
public class MyClass
{
private int _property;
public int Property
{
get { return _property; }
}
public MyClass(int property)
{
_property = property;
}
}
С помощью методов вы не имеете ту же двусмысленность, в которой вы хотели бы использовать одно и то же имя для разных форм одной и той же концепции (кроме перегрузок, для которых не требуется различать оболочки).
Я действительно думаю, что вам следует выбирать соглашения об именах в соответствии с вашими предпочтениями/антипатиями, независимо от того, как это делают другие люди (если, конечно, парень, оплачивающий чек, не говорит иначе).
Важным материалом является: как только вы выбираете соглашение, придерживайтесь его!
Главное, что вы получаете от этого соглашения, - это способность легко отличать вызовы методов от переменной-члена и доступа к параметрам.
Как отмечали другие, это не обязательно лучше - это просто компромисс, который разработчики .NET выбрали и застряли: упростить определение того, к чему вы обращаетесь, а не упрощать доступность уровня, к которому вы обращаетесь.
Свойства делают это особенно ценным, что может объяснить, почему он укоренился в мире .NET. Возможность определить разницу между доступом к объекту и доступом к переменной элемента может иметь решающее значение. Атрибуты доступа к ресурсам могут вычислять или проверять значения и вызывать связанную переменную-член по ошибке (или наоборот) создает тонкие ошибки.
Я хотел бы отметить, что, хотя да, PascalCase - это соглашение в .NET для частных и общедоступных методов, поскольку мы говорим о частных методах здесь, я не вижу никаких вред в выборе того, что выглядит лучше для вас. Я имею в виду, у вас есть точка зрения, что, кажется, есть заслуга в дифференциации частных публичных методов. Пока то, что вы подвергаете клиенту (если вы разрабатываете библиотеку), согласуется с конвенцией, вы золотой. Просто поработайте с любыми членами команды, как вы собираетесь делать что-то внутри.
Я пытаюсь просмотреть всю подпись метода при чтении кода. Если я не вижу модификатора доступа (public, protected, internal, protected internal), тогда я могу считать его private (хотя я пытаюсь быть явным в отношении модификаторов доступа).
Вы можете принять свою собственную конвенцию, особенно - для методов private.
В одном случае я могу думать о том, где соглашение полезно: при использовании Синтаксис преобразования неявных методов в С#. Рассмотрим этот класс, Test:
public class Test {
public event EventHandler MyEvent;
}
Если я создаю частный метод для обработки MyEvent и добавлю обработчик, используя синтаксис преобразования группы неявных методов С#, имя нижнего регистра может быть путано с полем или переменной:
Test test = new Test();
test.MyEvent += myEventHandler;
private void myEventHandler(object sender, EventArgs e) {
...
}