Что делает модификатор "private"?

Это для вас (и будущих сопровождающих), а не для компилятора.

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

Это могло быть из-за моего фона Java, где по умолчанию был «пакет» (примерно эквивалент «внутреннего» в C#), и поэтому разница всегда беспокоила меня. Я считаю, что ясность предпочтительнее.

Я также сейчас использую ReSharper, который по умолчанию является явным, поэтому он только подтверждает и усиливает мою предвзятость :)

Для симметрии и соответствия стилям кодирования, которые любят, чтобы все было явным (лично мне это нравится ...)

Некоторые стили кодирования рекомендуют ставить сначала все «общедоступные» элементы, а затем «частные» элементы. Без ключевого слова "private" вы не смогли бы этого сделать.

Обновление: я не заметил здесь тега «C#», поэтому мой ответ больше относится к C++, чем к C#.

Для полноты. А некоторые люди на самом деле предпочитают явно указывать в своем коде модификаторы доступа для своих методов.

Фактически, если класс или структура не объявлены с модификатором доступа, по умолчанию используется значение internal.

Так что, если вы хотите сделать его приватным, используйте приватный.

Модификатор private объясняет намерение.

Закрытая переменная-член не предназначена для прямого управления вне класса. Методы доступа get / set могут быть созданы или не созданы для переменной.

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

Модификатор private (и ему подобные) может быть полезным способом написания самодокументированного кода.

Использование private явно сигнализирует о вашем намерении и оставляет подсказки для других, кто поддержит ваш код;)

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

Из раздела 3.5.1 Спецификация языка C# 3.0 (msdn)

Depending on the context in which a member declaration takes place, only certain types of declared accessibility are permitted. Furthermore, when a member declaration does not include any access modifiers, the context in which the declaration takes place determines the default declared accessibility.

• Namespaces implicitly have public declared accessibility. No access modifiers are allowed on namespace declarations.
• Types declared in compilation units or namespaces can have public or internal declared accessibility and default to internal declared accessibility.
• Class members can have any of the five kinds of declared accessibility and default to private declared accessibility. (Note that a type declared as a member of a class can have any of the five kinds of declared accessibility, whereas a type declared as a member of a namespace can have only public or internal declared accessibility.)
• Struct members can have public, internal, or private declared accessibility and default to private declared accessibility because structs are implicitly sealed. Struct members introduced in a struct (that is, not inherited by that struct) cannot have protected or protected internal declared accessibility. (Note that a type declared as a member of a struct can have public, internal, or private declared accessibility, whereas a type declared as a member of a namespace can have only public or internal declared accessibility.)
• Interface members implicitly have public declared accessibility. No access modifiers are allowed on interface member declarations.
• Enumeration members implicitly have public declared accessibility. No access modifiers are allowed on enumeration member declarations.

Я обычно оставляю личное, но считаю его полезным для выстраивания кода:

private   int    x;
public    string y;
protected float  z;

ПРОТИВ:

int x;

public    string y;
protected float  z;

Как указал Джон Скит в своей книге C# в деталях, в C# есть одно место, где для достижения эффекта требуется ключевое слово private.

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

public bool CanAccessTheMissileCodes
{
    get { return canAccessTheMissileCodes; }
    private set { canAccessTheMissileCodes = value; }
}

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

Как сказал Роберт Полсон в своем ответе, модификатор private используется не только для членов, но и для типы. Это становится важным, потому что по умолчанию для типов используется internal, из которого может произойти непреднамеренная утечка, если вы используете Внутренние элементы.

Здесь есть определенная дезинформация:

"The default access modifier is not private but internal"

Ну, это зависит от того, о чем вы говорите. Для членов типа это закрыто. Для самих типов верхнего уровня это внутреннее.

"Private is only the default for methods on a type"

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

"Actually, if the class or struct is not declared with an access modifier it defaults to internal"

Только для типов верхнего уровня. Для вложенных типов он частный.

За исключением ограничения доступа к свойствам для одной части, но не для другой, значение по умолчанию в основном всегда «настолько ограничительно, насколько это возможно».

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

Эрик Липперт придерживается явной формы, и я тоже начинаю склоняться к ней.

См. http://csharpindepth.com/viewnote.aspx?noteid=54 для получения более подробной информации.