Почему мы не ставим префиксы 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.