Какова наилучшая практика для именования частных и статических частных методов в C#?

Question

Я пытаюсь выяснить, какой самый умный способ назвать частные методы и частные статические методы в C#.

Справочная информация: Я знаю, что лучшей практикой для частных участников является подчеркивание-префикс + camelcase. Вы можете спорить со мной, но поверьте мне, я видел достаточно кода от хардкорных профессионалов, которые следуют этому соглашению, это квалифицированный отраслевой стандарт.

Я также знаю, что паскаль является отраслевым стандартом для общественных методов. Но я видел комбинацию имени стиля теста (то есть метод method_must_return_false_occasionally) для случая pascal, camelcase и underscore-prefix + camelcase для частных и частных статических методов.

Но каков стиль лучшей практики для частного и частного статического метода именования в C#?

Если есть определенные стили, которые используются из частных методов, а не другие, я могу понять это, просто объясните.

Спасибо за чтение.

Answer 1

Отъезд от Microsoft Naming Guidelines и Брэда Аврама Style Guide

Они говорят, что все методы должны быть PascalCase

public void DoWork() {} 
private void StillDoWork() {} 
private static void ContinueToDoWork() {} 

Answer 2

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

Answer 3

naming guidelines для разработки библиотеки классов .NET не различает публичное и личное использование и рекомендует Pascal случай для статических методов.

EDIT: Моя личная практика заключается в использовании корпуса Pascal для методов и свойств, верблюжьей оболочки для полей, параметров и локальных переменных. При обращении к членам экземпляра из класса я использую this., чтобы отличать от членов класса и параметров, когда это необходимо. Я понятия не имею, квалифицируюсь ли я как «хардкор-профессионал», но мне платят. :-)

EDIT 2: После написания этого изначально я сменил работу. Стандарт кодирования, который мы придерживаемся, отличается от моих личных чувств, и мы префикс частных полей с подчеркиваниями. Я также начал использовать ReSharper, и наши стандарты (как правило) соответствуют правилам по умолчанию. Я нахожу, что могу спокойно жить с подчеркиваниями. Я использую только this, когда это абсолютно необходимо, так как оно не соответствует нашим стандартам кода. Консистенция превосходит личные предпочтения.

Answer 4

Один из вариантов заключается в использовании инструмента, который принуждает вас быть последовательным, например, style cop (если вы используете reSharper, есть плагин для стиля копа на codeplex). Большинство инструментов, по-видимому, применяют («предлагаю») рекомендации Microsoft, так как вы проведете несколько тестов для получения одобрения платформы MS.

Answer 5

Каждое место, в котором я работал, всегда делало это по-другому.

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

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

Я бы начал рассматривать различные проекты с открытым исходным кодом и подобные проекты, и вы увидите множество различных схем.

Я также видел, как подчеркивают деловые вопросы camelCase и Pascal, разделяющие коммуны, а иногда и команды - вот что я думаю о схеме кодирования.

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

Другим фактором, который я хотел бы учитывать, является сложность кода в терминах OO, если это простой проект или сложный дизайн OO с использованием шаблонов mutliple или вы используете некоторые IOC, а затем запускаете «всплеск» на разных типах стандартного кодирования, а затем посмотрите на то, что физически выглядит код, когда вы его используете, - выглядите хорошо с вами и командой или выглядят уродливо.

Answer 6

weird_underscore_naming соглашение обычно ограничен испытаниями, потому что он делает их более читаемыми и является тем, что сильно поощряется BDD. Помните, что в то время как метод описывает в короткие сроки то, что он делает (DepositMoney), тесты должны описывать, что они делают, то есть Negative_deposits_must_be_caught