Более короткое соглашение о присвоении имен для типов

Ну, длинные имена повреждают что-то?

(редактирование) две других мысли:

• использовать var в C# 3.0 - это сохранит половину ширины

• если Вы используете тип многократно в файле, рассматриваете псевдоним типа, если это является раздражающим Вы:

  using Fred = Namespace.VeryLongNameThatIsBeingAnnoying;

Я просто предложил бы использовать самое краткое именование, которое описывает объект. Если EventModelSocketObjectReceivedEventArgs делает это, идут дальше. Мои 2 цента.

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

Инструменты, которые мы имеем сегодня, делают это настолько легким с автозавершением и т.п.. Из-за этого я использую полные слова в именах переменной теперь, и я думаю, что это - хороший способ пойти.

Не удаляйте гласные или что-то сумасшедшее как этот.

Я - с "палкой с длинным именем" люди.

Одна мысль - то, что, если имена являются настолько неловкими, возможно, некоторый более глубокий пересмотр прежнего мнения системы необходим.

Если необходимо пройти так много усилия найти альтернативное имя, у Вас уже есть корректное имя. Имена объекта/метода/свойства должны быть сам документирование. Если они не описывают свою точную цель, они неверно называются. Нет ничего неправильно с длинными именами, если они дают самое ясное понимание цели того объекта.

В этом возрасте intellisense и больших мониторов там действительно не оправдание не быть максимально описательным в именовании.

Я для одного использования длинное имя. С выводом intellisense имени не настолько важно, если Вы не используете 15-дюймовый монитор.

Если бы я должен был уменьшить имя, то я мог бы пойти с EvtMdlSck, просто делают работу короче, но все еще понятый. Даже при том, что это не мое предпочтение.

В целом я верю в имена классов, которые точно описывают их функцию, и это, нормально иметь длинные имена. Если бы Вы думаете, что имена действительно становятся длинными, что я предложил бы, находит понятие, которое известно Вашей команде программистов и сокращению это. Таким образом, если "Сокеты Модели событий" являются понятием, о котором все знают, затем сократите их до EMS. Если у Вас есть пакет, который является полностью о Сокетах Модели событий, затем сокращают их до EMS во всех классах, внутренних к тому пакету. Они вводят, здесь должен удостовериться, что имя полностью для любого, кто не мог бы быть знаком с понятием и сокращенный ни для кого, кто.

Некоторые критические замечания на Вашем именовании...

Почему Ваш компонент имеет слово "моделью" на ее имя - разве, который не немного избыточен.

Так как Ваш компонент, кажется, обменивающийся сообщениями какой-то концентратор, почему бы не включать сообщение в его имя. Что относительно MessageSender.

Для решения проблемы, я создал бы интерфейс и данный его родовое название как MessageSender и реализация, которая является, где Вы включаете технологию в имени как RandomFailingSocketMessageSender.

Если Вы хотите добраться, хороший пример этого смотрят на библиотеки .NET или Java..

от Java. интерфейс - класс/реализации... Карта - HashMap, LinkedHashMap. Список - LinkedList

Детали относительно технологии или используемой платформы, например, слова как "Сокет" или возможно использовать изобретенный пример "MQSeries" не должны быть частью имени интерфейса вообще.

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