Чому ми не префіксуємо «Енуми», «Абстрактні класи» та «Конструкти»?

Спільнота C # настільки всюди використовувала префікс "Я" для позначення інтерфейсу, що навіть найдосвідченіші програмісти знають ним користуватися.

Чому ж тоді ми не префіксуємо перерахунків, абстрактних класів чи структур (можливо, з "E", "A" та "S" відповідно)?

Наприклад, якби ми позначили всі абстрактні класи клавішею "A", це дало б цінну інформацію про цей тип, яка, хоча це можна зробити висновок, не відразу очевидно.

Зверніть увагу, що я не виступаю за цю зміну, я просто намагаюся зрозуміти, чому ми не робимо так.

Цей потік відповідає, чому ми використовуємо префікс "Я", але не відповідає, чому ми не використовуємо інші префікси.

Сенс угоди про іменування інтерфейсів полягає в тому, щоб швидко і без мозкових рішень про те, як викликати інтерфейс, який реалізує ваш клас, швидко. Якщо у вас є Frobnicator, але вам потрібно оголосити інтерфейс для роз'єднання або з будь-якої причини, тоді рішення про його виклик не IFrobnicatorпотребує свідомої думки, і це добре.

Ця ж проблема не стосується інших конструкцій, яких ви називаєте. Переліки та структури корисні, але не потрібно шукати другого , короткого, прозорого, очевидно спорідненого імені, крім самого імені. Таким чином, не існує тиску, щоб натиснути "Е" на ім'я перерахунку або структури.

(Абстрактні класи дещо схожі на інтерфейси, оскільки вам потрібно надати другий, конкретний клас, щоб щось зробити, тому вони, можливо, придбали конвенцію починати з «А», але з будь-якої причини вони цього не зробили. Якщо Мені дозволено міркувати, я вважаю, що "я" є особливо вузьким листом, можливо, щось із цим пов'язане.)

Я думаю, що він використовується не так багато, тому що:

• більшу частину часу це не має великого значення, якщо це перелік, абстрактний клас чи структура
• якщо це так, я, мабуть, бачу це з використання, а в іншому випадку це досить швидко дізнаюся
• якщо я зміню його як enum, абстрактний клас чи структура, я також мушу перейменувати його
• для людей, які не знають конвенції, це чистий шум.
• люди можуть просто відкинути всю ідею, оскільки їх навчили не використовувати угорські позначення. Були і досі є люди, які кажуть, що не слід використовувати позначення угорщини, не роблячи різниці між програмами Угорська та Системи Угорською. Приємну дискусію можна знайти в цьому запитанні ТА . Не просто перша відповідь цікава, але є чудові відповіді та коментарі. З цього ж питання походить ця стаття Джоела Спольського (прокрутка до абзацу "Я Угорщина")

коротше: загалом додана вартість не досягає витрат.

З цього останнього пункту і деякої інтерпретації ви могли б зробити висновок. Угорські системи (тип префікса) погані, і їх не слід використовувати. Угорські програми (вид префікса) використовують його.

Зважаючи на це ваше запитання, я вважаю, що запропоноване вами позначення є формою угорської програми, і якщо ви вважаєте, що додана вартість збільшує витрати і ви послідовно впроваджуєте її у своїй кодовій базі, це просто добре. Але оскільки ви повинні розглядати це на основі кожного проекту, це не повинно бути загальним правилом.

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

Просто (сподіваємось, застосовна) думка:

Існує очевидна тенденція до «кодування інтерфейсів», а не до конкретних класів. "Сьогодні" майже вигідніше скласти конвенцію іменування для класів, як, наприклад, починати їх з "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
}

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