Стиль кода для закрытых методов в [закрытом] C#

По соглашению, все имена методов в C # начинаются с заглавной буквы. Все имена свойств тоже. Только частные поля, локальные переменные и параметры методов начинаются со строчной буквы (AFAIR).

Это соглашение, поэтому вопрос «почему» неуместен. Вероятно, это похоже на вопрос: «Почему соглашение о кодировании Java предпочитает строчные буквы для всего, кроме классов?» - ответы на такие вопросы обычно таковы: «Потому что кто-то где-то однажды решил, что это будет хорошей идеей» . Остальное - просто история - или соглашение, и вы либо следуете ему, либо нет (в этом случае вы усложняете жизнь людям, читающим ваш код).

ETA: Как уже было сказано в комментарии, (imho) ответ на вопрос «почему?» Обычно приводит к тому, что разработчики языка (или люди, придумывающие соглашение) считали важными аспектами для подпадать под действие конвенции. В Java это явно случай визуального различения классов (PascalCase), переменных / полей (camelCase) и свойств (get ~ () / set ~ ()). Очевидно, что для .NET существовала необходимость в немедленном различении классов и интерфейсов (что я тоже считаю неплохим) и в визуальном различении доступа к свойствам (PascalCase) и полям (camelCase).

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

Таково соглашение об именовании для .NET, и именно этому соглашению следуют все стандартные библиотеки .NET. Ничто не обязывает вас следовать этому соглашению в собственном коде, но обычно лучше следовать стандартам языка, на котором вы работаете. Лично я предпочитаю lowerCamelCase, а не UpperCamelCase, но при написании на C# я все равно использую рекомендуемый стиль .NET.

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

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

public class MyClass
{
    private int _property;

    public int Property
    {
        get { return _property; }
    }

    public MyClass(int property)
    {
        _property = property;
    }
}

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

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

Важный момент: как только вы выберете соглашение, придерживайтесь его!

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

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

Свойства делают это особенно ценным, что может объяснить, почему он пустил корни в мире .NET. Возможность отличить доступ к свойству и доступ к переменной-члену может иметь решающее значение. Средства доступа к свойствам могут вычислять или проверять значения, а ошибочный вызов связанной переменной-члена (или наоборот) создает небольшие ошибки.

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

Однако вы можете принять собственное соглашение - особенно для частных методов.

Я могу вспомнить один случай, когда это соглашение будет полезно: при использовании синтаксиса неявного преобразования группы методов C # . Рассмотрим этот класс, Test :

public class Test {
    public event EventHandler MyEvent;
}

Если я создам частный метод для обработки MyEvent и добавлю обработчик с использованием синтаксиса неявного преобразования группы методов C #, имя метода в нижнем регистре можно спутать с поле или переменная:

Test test = new Test();
test.MyEvent += myEventHandler;

private void myEventHandler(object sender, EventArgs e) {
    ...
}

Я просто хотел бы отметить, что хотя да, PascalCase - это соглашение в .NET для частных и публичных методов, учитывая, что мы здесь говорим о частных методах, я не вижу никакого вреда в выборе того, что выглядит лучше для вас. Я имею в виду, что вы правы в том, что различие между приватными и публичными методами имеет смысл. До тех пор, пока то, что вы показываете клиенту (если вы разрабатываете библиотеку), соответствует соглашению, вы в полном порядке. Просто договоритесь с членами команды, как вы собираетесь делать это внутри команды.