Если вы используете модификатор частного доступа, если он избыточен?

Question

Учитывая, что эти два примера эквивалентны, что, по вашему мнению, предпочтительнее?

Без явного модификатора

public class MyClass 
{ 

    string name = "james"; 

    public string Name { 
     get { return name; } 
     set { name = value; } 
    } 

    void SomeMethod() { ... } 

} 

С явного модификатора

public class MyClass 
{ 

    private string name = "james"; 

    public string Name { 
     get { return name; } 
     set { name = value; } 
    } 

    private void SomeMethod() { ... } 

} 

---

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

Answer 1

Я думаю, что объяснение частной информации помогает в удобочитаемости. Это не позволит программисту интерпретировать свою видимость по-разному.

Answer 2

Я всегда предпочитаю быть явным, даже если он является избыточным. Это обеспечивает встроенные комментарии к коду и может быть полезным для следующего парня, особенно если он нооб. :-)

Answer 3

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

Answer 4

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

Answer 5

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

Кроме того, когда вы говорите о различных типах структур, они могут иметь разные возможности по умолчанию. Без явных модификаторов ownus читает читателю, какая структура имеет значение по умолчанию. Например. в C# структурные поля по умолчанию равны public, поля классов по умолчанию - private, а определения классов по умолчанию - internal.

Answer 6

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

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

Answer 7

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

Answer 8

Отмечая это как личное, он ясно указывает, что он преднамерен, вместо того, чтобы «я на самом деле не думал об этом, поэтому я не знаю, будет ли это лучше, чем что-то еще. "; поэтому мне нравится делать это явным. Однако я не стал бы религиозным.

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

Проясните ... сделать его явным ;-p

Answer 9

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

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

Единственный случай, который я вижу, это вызывает проблемы, если вы исходите из фона VB .NET. Но, эй, я пришел из фона VB .NET, и я до сих пор знаю, что видимость по умолчанию в C#.

В VB .NET, с другой стороны, я почти всегда включаю его, потому что значения по умолчанию довольно глупы; по умолчанию для Sub или Function используется Friend, а не Private.

Answer 10

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

Answer 11

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

Мне нравится явное объявление моего намерения при кодировании. И то, и другое, потому что объявления для меня видны, когда я возвращаюсь и смотрю на него, и потому, что на самом деле мышление и написание слова «частный», когда я пишу метод, заставляет меня думать немного больше о том, что я имею в виду делать.

Answer 12

Мне нравится быть супер-явным обычно. Я пойду для указания «частного» всегда. Однако есть и другая причина: программисты, выходящие из языков программирования, где видимость по умолчанию NOT приватная, но общедоступная, например PHP.

Answer 13

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

Я забочусь о том, что публичные и частные так похожи, длина 6-7 символов, синяя, начиная с «р», поэтому гораздо сложнее указать открытый метод между 10 явными частными, чем между 10, у которых нет доступа атрибут.

Кроме того, это преимущество, так как ленивые люди в вашей команде имеют тенденцию сохранять запись модификатора и сделать метод приватным, что на самом деле хорошо. В противном случае вы получите все, что угодно.

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

Кроме того, мне обычно нравится, когда код прост и понятен в математическом математике, когда код явственен, чтобы сохранить незнание будущего кодера. Это способ VB, а не C# ...

Answer 14

Сначала я спрошу, существует ли предыдущее соглашение/стандарт кода, используемое командой. Если есть, вы должны следовать за ним.

Если вам нужно определить соглашение, я буду настаивать на явном способе.

Мои причины ?;

• Мне нравится сохранять одну и ту же структуру (я имею в виду модификатор a.-access, b.-return-type/type, c.-name).
• Я не хочу (и я не ожидаю других) помнить все модификаторы по умолчанию (which are here).
• Не все языки имеют одинаковые правила.
• И почему-то я думаю, что это как-то заставляет разработчика мыслить и быть более сознательным в области действия переменной/метода и изложения этих. Если у вас есть опыт, это, вероятно, не применимо, но если вы новичок или работаете с людьми с меньшим опытом, я считаю, что это полезно.