Стиль кода для частных методов в C #

Question

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

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

Answer 1

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

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

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

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

Answer 2

Это на самом деле не лучше и не хуже. Это просто соглашение.

Answer 3

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

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

Answer 4

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

public class MyClass
{
    private int _property;

    public int Property
    {
        get { return _property; }
    }

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

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

Answer 5

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

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

Answer 6

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

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

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

Answer 7

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

Вы можете принять собственное соглашение, особенно для 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) {
    ...
}

Answer 8

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