1. Резонно, но дискуссия немного не о стандартности нотации, а о ее полезности («а что было бы, если бы ЭТА нотация была стандартной?»)
2. Хороший пример :) +1 в сторону «I»
Я и сам ярый сторонник нотации I, просто стало интересно — это сила привычки и нелюбви к джаве (хаха, мы не в джаве, у нас есть «I»!) или такой подход несет определенные объективные выгоды?
1. Согласен в виду их преобладания
2. :)
3. Спорно, но пропущу
4. Где это вы видели делегаты как члены класса? Делегат это вполне себе тип, который наследуется от MulticastDelegate и объявляется с помощью ключевого слова delegate. По хорошему каждый делегат объявляется в отдельном файле, как и классы, и, соответственно, Конвенция DEventHandler была бы вполне ничего ;) Хотя здесь есть выход — все делегаты и так заканчиваются на Handler.
5. Не скажите, в некоторых местах знать, что в метод передается абстрактный класс, так же важно, как знать, что передается интерфейс или конкретный класс. Так что вполне себе нотация — AController
6. Одно из правил, которому я неизменно следую — Structures are evil :) Хотя здесь SPoint смотрелось бы вполне ничего.
Итого из удобных мест, где можно использовать такую же нотацию, выделяем:
1. Перечисления
2. Абстрактные классы (Можно дописывать суффикс Base)
3. Структуры
Почему в стандартной нотации эти элементы не выделяются? :)
Я понимаю, что это общепринято, вопрос в том, разумно ли это. Т.е. нравится ли нам стандартная нотация потому, что это хорошая нотация, или потому, что это _стандартная_ нотация?
Если бы стандартной нотацией был вариант, взятый из Java, то интерфейсы отображались бы цельной группой над или под группой классов.
Касательно наследования вижу как минимум такой вариант: класс всегда идет первым, остальные перечисленные — интерфейсы ввиду отсутствия множественного наследования в языке C#.
Вполне себе вариант, но мне мой вариант удобнее тем, что сразу можно отмечать время прихода-ухода на часиках: из-за совмещения учебы и работы приходится в середине дня пропадать достаточно часто.
А насчет бумаги — на любителя :) Мне ручкой черкануть быстрее и приятнее, чем вбить что-то в систему )
2. Хороший пример :) +1 в сторону «I»
Я и сам ярый сторонник нотации I, просто стало интересно — это сила привычки и нелюбви к джаве (хаха, мы не в джаве, у нас есть «I»!) или такой подход несет определенные объективные выгоды?
2. :)
3. Спорно, но пропущу
4. Где это вы видели делегаты как члены класса? Делегат это вполне себе тип, который наследуется от MulticastDelegate и объявляется с помощью ключевого слова delegate. По хорошему каждый делегат объявляется в отдельном файле, как и классы, и, соответственно, Конвенция DEventHandler была бы вполне ничего ;) Хотя здесь есть выход — все делегаты и так заканчиваются на Handler.
5. Не скажите, в некоторых местах знать, что в метод передается абстрактный класс, так же важно, как знать, что передается интерфейс или конкретный класс. Так что вполне себе нотация — AController
6. Одно из правил, которому я неизменно следую — Structures are evil :) Хотя здесь SPoint смотрелось бы вполне ничего.
Итого из удобных мест, где можно использовать такую же нотацию, выделяем:
1. Перечисления
2. Абстрактные классы (Можно дописывать суффикс Base)
3. Структуры
Почему в стандартной нотации эти элементы не выделяются? :)
1. классы
2. интерфейсы
3. перечисления
4. делегаты
Еще можно отдельно выделить абстрактные классы. Так почему же мы не выделяем их, соответственно, как C, I, E, D, A? :)
Касательно наследования вижу как минимум такой вариант: класс всегда идет первым, остальные перечисленные — интерфейсы ввиду отсутствия множественного наследования в языке C#.
www.caffeinatedcoder.com/should-we-change-the-way-we-name-interfaces-in-net/
С другой стороны, если была другая, _удобная_, система для тайм-трекинга (а не ужасный MSP), я бы тоже писал сразу туда.
А насчет бумаги — на любителя :) Мне ручкой черкануть быстрее и приятнее, чем вбить что-то в систему )