Стоит ли использовать модификатор частного доступа, если он избыточен?
Учитывая, что эти два примера эквивалентны, что, по вашему мнению, предпочтительнее?
Без явного модификатора
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() { ... }
}
Я всегда использовал последний, но недавно я начал перенимать первый стиль. Частное является избыточным, поскольку это модификатор доступа по умолчанию, так что не имеет смысла его исключать?
Ответы 14
Я думаю, что ясность изложения частного помогает в удобочитаемости. Это не позволит программисту иначе интерпретировать его видимость.
Так что ... компилятор все равно его удалит. И эти несколько букв ничего не стоят!
Это чрезвычайно полезно, если в вашей команде есть разработчики, которые изучают C# после многих лет программирования на Java. Несмотря на то, что я знаю лучше, мой инстинкт - по умолчанию использовать значения по умолчанию для Java.
сколько времени нужно, чтобы ввести pri и нажать пробел в VS? То есть ... мы говорим о миллисекундах;) .. Читаемость> все
@jonnii. ya в спецификации указано, что, но, как сказал Джеймс, в java по умолчанию защищено, поэтому новые программисты, пришедшие с java, могут не знать. или просто новичков в этом вопросе.
Не говоря уже о новичках - явное почти всегда лучше. Не заставляй меня думать. :) +1 к этому ответу.
Модификатор доступа по умолчанию в Java - «default», а не «protected». Хотя «по умолчанию» может быть похоже на «защищенный» или «закрытый», я уверен, что есть небольшая разница.
Кроме того, после быстрого поиска в Google выяснилось, что модификатор доступа по умолчанию для C# является «внутренним», а не «частным».
@Dalin: закрытый для членов типов (включая вложенные типы) и внутренний для типов верхнего уровня.
StyleCop заставляет вас всегда явно указывать видимость. Просто привычка помогла мне случайно не перестать быть видимым для публики.
Модификатор доступа по умолчанию в Java фактически является «частным пакетом». Член отображается как общедоступный для других классов в том же пакете, но как частный для других пакетов и подклассов. Подробнее здесь: java.sun.com/docs/books/tutorial/java/javaOO/accesscontrol.h tml
@Will Eddins, сам факт того, что вы могли отключить видимость «случайно», показывает, что участникам не обязательно быть публичными. Если бы это было так, вы бы уже использовали их в контексте, который требовал, чтобы они были общедоступными. Вот почему лучше всего опустить видимость, чтобы вещи не были видны до тех пор, пока они не будут необходимость.
Я всегда предпочитаю быть откровенным, даже если это избыточно. Это предоставляет встроенные комментарии к коду и может быть полезно следующему парню, особенно если он новичок. :-)
вы правы, но поскольку вы хотите, чтобы ваш код был понятен для всех, я думаю, вы должны включить, вы никогда не знаете, когда, если кто-то этого не знает
Лично я предпочитаю модификатор private - мне нравится ясность. Для полей он также подчеркивает, что это переменная-член, а не переменная функции (в противном случае единственная разница - это местоположение - это нормально, если люди могут делать отступы правильно, но в противном случае может сбивать с толку).
Всегда используйте явную форму. Если по какой-либо причине исходное предположение изменится, код с явным обозначением доступа не сломается, тогда как неявный оттенок легко сломается.
Кроме того, когда вы говорите о разных типах структур, они могут иметь разные возможности доступа по умолчанию. Без явных модификаторов читатель должен знать, какая структура имеет какое значение по умолчанию. Например. в C# поля структуры по умолчанию равны public, поля класса по умолчанию - private, а определения классов по умолчанию - internal.
Насколько я понимаю, участники всегда имели «внутреннюю» доступность, если не указано иное. Если это правда, потребуется модификатор «private», чтобы гарантировать, что эти члены действительно являются частными.
Независимо от того, прав я в вышеизложенном или нет, оставление модификатора на месте повысит читаемость кода в случае, если другой разработчик позже изменит этот класс и заинтересован в доступности. Надеюсь это поможет!
Члены являются «частными», если не указано иное. Типы (или, по крайней мере, внешние типы) по умолчанию являются внутренними; и снова другое для вложенных классов. Смотрите - есть уже 3 сценария, которые нужно запомнить - стоит сделать это явным ;-p
Вам не нужно запоминать три сценария. Все, что вам нужно помнить, это то, что по умолчанию все имеет наименьшую возможную видимость. Внешний тип не может быть частным; если бы это было так, ничто не могло бы получить к нему доступ. Внутренний тип может является частным, поскольку к нему может получить доступ его внешний тип, и поэтому частный является его видимостью по умолчанию. Видимости по умолчанию в C# совершенно логичны, и поэтому нет стоит сделать явным.
Члены имеют внутреннюю (Friend) видимость по умолчанию в VB .NET. Правила VB .NET в основном требуют, чтобы вы сделали видимость явной, потому что в них нет очевидной логики. Правила C# имеют одно простое логическое правило (см. Предыдущий комментарий), и можно безопасно оставить значения по умолчанию, если вам не нужно их менять.
Я все время иду на откровенное. По крайней мере, это более ясно демонстрирует ваше намерение. Если я хочу что-то личное, я так и скажу. Явный ввод модификатора гарантирует, что я думаю об этом, а не просто оставляю вещи частными, потому что это быстрее. Что длинный список участников лучше выстраивается :)
Если пометить его как частное, станет ясно, что это сделано намеренно, а не «Я на самом деле не думал об этом, поэтому не знаю, было бы лучше что-то другое»; так что мне нравится делать это явным. Однако я бы не стал религиозным по этому поводу.
Также - это предотвращает необходимость запоминания правил ... члены по умолчанию являются частными, (внешние) типы по умолчанию являются внутренними; вложенные типы по умолчанию являются частными ...
Сделайте это ясным ... сделайте это явным ;-p
Но правила легко запомнить. Вы можете переформулировать их как «Все как можно меньше видно». Или «Все является частным, если только этого не может быть» (внешние типы не могут быть, потому что тогда их ничто не может использовать). Нет ничего сложного в том, чтобы запомнить значения по умолчанию.
Я всегда опускаю его по двум причинам: чтобы уменьшить визуальный беспорядок и по умолчанию делать правильные вещи.
В C# по умолчанию используется наименьшая возможная видимость. Член класса (поле, метод, свойство) по умолчанию является частным. По умолчанию используется внутренний класс. По умолчанию вложенный класс является частным.
Таким образом, если вы опустите свою видимость, кроме тех, где она вам нужна, вы автоматически будете использовать наименьшую возможную видимость, что в любом случае является правильным способом.
Если вам нужно что-то, чтобы более было видно, добавьте модификатор. Это позволяет легко увидеть элементы, которые отличаются от видимости по умолчанию.
(К сожалению, это правило справедливо только для C#. В VB .NET и F# значения по умолчанию совершенно разные и определенно не «возможна наименьшая видимость» в большинстве случаев.)
Я всегда явно указываю видимость. Я предпочитаю не позволять компилятору угадывать мои намерения.
Я постоянно занимаюсь разработкой на C# около 7 лет, и пока я не прочитал этот раздел, я не знал, какой модификатор доступа по умолчанию. Я знал, что он существует, но никогда не использовал его.
Мне нравится явно заявлять о своих намерениях во время написания кода. И потому, что объявления есть для меня, когда я возвращаюсь и смотрю на них, и потому, что на самом деле размышление и ввод слова "частный" при написании метода заставляет меня немного больше думать о том, что я имею в виду. делать.
«Я занимаюсь разработкой C# на постоянной основе около 7 лет, и пока я не прочитал эту тему, я не знал, какой модификатор доступа используется по умолчанию». -> Это требует немного смелости, чтобы признать :)
Обычно я люблю быть очень откровенным. Я всегда буду указывать "частный". Однако есть и другая причина: программисты, пришедшие с языков программирования, где по умолчанию видимость НЕТ является закрытой, но общедоступной, например PHP.
Да, в конечном итоге они (программисты PHP) создадут кучу закрытых членов, которые им действительно нужны, это открытый модификатор, а реализованный класс не тестируется извне.
Похоже, что мы единственные, но лично Я поддерживаю, давайте удалим приватную кампанию.
Меня беспокоит то, что общедоступный и частный настолько похожи, длина 6-7 символов, синий цвет, начинается с 'p', поэтому гораздо сложнее указать общедоступный метод между 10 явными частными, чем между 10, у которых нет атрибута доступа.
Кроме того, это преимущество, поскольку ленивые люди в вашей команде, как правило, не пишут модификатор и не делают метод закрытым, что на самом деле хорошо. В противном случае вы получите все публично.
Я обычно предпочитаю явное, а не неявное, но это важнее в языковых угловых случаях (хитрые читы), чем в широко распространенной функции. Я считаю, что здесь важнее длительная ремонтопригодность.
Кроме того, мне обычно нравится, когда код прост и понятен в стиле математический, а когда код является явным, чтобы сохранить невежество будущего кодера. Это путь VB, а не C# ...
Мы должны создать группу поддержки!
пусть ваш редактор раскрасит их по-разному, если они вам не нравятся, синим цветом
Не все редакторы могут раскрашивать разные модификаторы в разные цвета. Однако некоторые надстройки (например, CodeRush) могут отображать для них разные символы.
Я нахожусь в том же лагере, хотя не возражаю, если используется личное. Моя основная причина в том, что строки кода C# обычно очень длинные (начальный отступ, длинные имена типов и т. д.). Удаление частного делает его короче. А блок частных участников выглядит так же лаконично, как и традиционная программа C.
Короче элегантнее. Людям, которым нужен явный беспорядок, такой как «частный», лишние скобки и ненужные операторы, следует выучить язык.
Согласовано. На мой взгляд, «частные» модификаторы увеличивают соотношение «шум / сигнал» при просмотре кода.
+1 Я всегда люблю писать как можно меньше, поэтому все лишнее опущу. Я думаю, что это улучшает читаемость, делая его менее загроможденным и позволяя отображать больше кода на экране.
Верно, потому что они имеют доступ модификатор. Зачем добавлять модификатор, если на самом деле это не модифицированный?
Сначала я спрошу, есть ли предыдущее соглашение / стандарт кода о том, что команда использует. Если есть, следите за ним.
Если вам нужно определить соглашение, я буду настаивать на явном способе.
Мои причины ?;
- Мне нравится сохранять ту же структуру (я имею в виду модификатор доступа, b.-return-type / type, c.-name).
- Я не хочу (и не ожидаю, что другие) запоминают все модификаторы по умолчанию (которые здесь).
- Не все языки имеют одинаковые правила.
- И почему-то я думаю, что это каким-то образом заставляет разработчика задуматься и более осознанно относиться к области действия переменной / метода и их описанию. Если у вас есть опыт, это, вероятно, не применимо, но если вы новичок или работаете с людьми с меньшим опытом, я думаю, что это полезно.
В спецификации C# довольно ясно, что модификатор по умолчанию для классов является частным. Это также часто задаваемый вопрос в интервью.