Почему мы не ставим префиксы Enums, абстрактные классы и структуры?


11

Сообщество C # настолько повсеместно использовало префикс «I» для обозначения интерфейса, что его знают даже самые неопытные программисты.

Почему же тогда мы не ставим префиксы перечислений, абстрактных классов или структур (возможно, с «E», «A» и «S» соответственно)?

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

Пожалуйста, обратите внимание, что я не защищаю это изменение, я просто пытаюсь понять, почему мы так не поступаем.

Этот поток отвечает, почему мы используем префикс «I», но не отвечает, почему мы не используем другие префиксы.


3
Я бы проголосовал за повторное закрытие, но ответ на SO stackoverflow.com/questions/111933/…
— Эйфорический

1
@Euphoric: этот вопрос гораздо более конкретен.
— Reinierpost


Перечень IMO следует избегать (заменять открытыми статическими членами только для чтения (шаблон enum)), абстрактные классы должны иметь суффикс «base», а структуры должны иметь нижний регистр в качестве соглашения об именах, но, поскольку .NET этого не делает, он просто запутывается, если вы делаете структуры строчными, так как это никогда не будет последовательным.
— Дейв Кузино,

Почему бы вам не использовать перечисления в пользу создания перечислений псевдо?
— Стивен

Ответы:


27

Смысл соглашения об именах для интерфейсов состоит в том, чтобы обеспечить быстрое, простое решение о том, как называть интерфейс, который реализует ваш класс. Если у вас есть Frobnicator, но вы должны объявить интерфейс для разъединения или по какой-либо другой причине, тогда решение назвать его не IFrobnicatorтребует осознанной мысли, и это хорошо.

Та же проблема не относится к другим конструкциям, которые вы называете. Перечисления и структуры полезны, но не обязательно находить второе , короткое, прозрачное, явно связанное имя в дополнение к самому имени. Следовательно, нет никакого давления, чтобы наложить «E» на имя перечисления или структуры.

(Абстрактные классы чем-то похожи на интерфейсы, так как вам нужно предоставить второй, конкретный класс, чтобы что-то сделать, поэтому они могли бы получить соглашение, начинающееся с 'A', но по какой-то причине они этого не сделали. Мне позволено строить догадки, я думаю, что «я», будучи особенно узким письмом, могло иметь к этому какое-то отношение.)


5
+1 Это ответ я бы написал. Я бы отметить, однако , что абстрактные классы уже имеет совершенно cromulent соглашения об именовании, где имя абстрактного класса AnimalBaseи различные вкусы AnimalGiraffe, и AnimalLionт.д.
— Binary беспокойного

Возможно, стоит упомянуть, что многие интерфейсы Java не используют «я», так Listкак они очень технически названы ArrayListи LinkedListявляются названиями реализаций. (C #, я полагаю, имеет IListкак интерфейс, так и Listсписок массивов)
— Katana314

Интересно, было бы полезно, когда Microsoft рекомендовала, чтобы переменные «изменяемых» структурных типов имели конкретный префикс, чтобы избежать путаницы в отношении того Point p = myPoints[3]; p.X += 3;, повлияет ли это myPoints[3].X. Оглядываясь назад, я бы предпочел, чтобы C # использовал var->fieldдля доступа var.fieldк полям классов и для доступа к структурным полям, но, очевидно, это не так. Тем не менее, казалось бы, на первый взгляд могут быть полезны средства их различения.
— суперкат

1

Я думаю, что он мало используется, потому что:

  • в большинстве случаев это не имеет большого значения, если это перечисление, абстрактный класс или структура
  • если это имеет значение, я могу, вероятно, увидеть его по использованию, а в противном случае выяснить довольно быстро
  • если я изменяю это как перечисление, абстрактный класс или структура, я также должен переименовать это
  • для людей, которые не знают конвенции, это чистый шум.
  • люди могут просто отклонить всю идею, потому что их учили не использовать венгерские обозначения. Были и есть люди, которые говорят, что вы не должны использовать нотацию Hungarion, не делая различий между Apps Hungarian и Systems Hungarian. Хорошее обсуждение можно найти в этом вопросе . Интересен не только первый ответ, но и отличные ответы и комментарии. От того же вопроса вытекает эта статья Джоэля Спольски (выделите пункт «Я Венгрия»)

короче говоря: в целом добавленная стоимость не составляет стоимость.

Из этого последнего пункта и некоторой интерпретации вы можете сделать вывод. Системы венгерские (префиксный тип) плохие и не должны использоваться. Приложения венгерские (вид префикса) он использует.

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

Я думаю, что люди заметили, что это имеет значение для интерфейсов чаще, и поэтому стало общим правилом для интерфейсов.


-1

Просто (надеюсь, применимо) мысль:

Существует очевидная тенденция к «кодированию для интерфейсов», а не к конкретным классам. «В наше время» кажется почти более выгодным иметь соглашение об именах для классов, например начинать их с «C», а не с буквы «I» для интерфейса.

Я только что закончил Java-проект, в котором все интерфейсы на самом деле назывались Model. Да, соглашение об именах интерфейсов заключалось в том, чтобы заканчивать имя на «Model» ..., а затем в «DataTransferObject / DTO» реализовать интерфейс как :

public interface SomethingModel{
}

public class Something implements SomethingModel{
    //lets not line up braces and make it hard to read
    //at least it saves one line
}

тогда как в C #

public interface ISomething{}

public class SomethingModel : ISomething
{
   //i can read this
}

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.