Сокращенное соглашение об именах для типов

Question

Я разрабатываю фреймворк, и некоторые объекты имеют действительно длинные имена. Мне это не очень нравится, но я тоже не люблю аббревиатуры. Я пытаюсь придумать более короткое имя для «EventModelSocket», по сути, обертку вокруг класса сокетов .Net, который реализует различные события, и методы для отправки файлов, объектов и т. Д. Некоторые из объектов имеют действительно длинные имена из-за этого например, «EventModelSocketObjectReceivedEventArgs».

Я перепробовал все, от тезауруса до словаря и часами сидел здесь.

Когда вы сталкиваетесь с такими ситуациями, как лучше всего назвать что-то?

Answer 1

Вставьте некоторые из них в пространство имен.

Например:

EventModelSocketObjectReceivedEventArgs

становится

EventModel.Sockets.ReceivedEventArgs

Answer 2

Ну, а длинные имена чем-то мешают?

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

• используйте var в C # 3.0 - это сэкономит половину ширины

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

  using Fred = Namespace.VeryLongNameThatIsBeingAnnoying;

Answer 3

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

Answer 4

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

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

Answer 5

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

Я из "палки с длинным именем", люди.

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

Answer 6

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

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

Answer 7

Некоторые критические замечания по поводу вашего имени ...

Почему в вашем компоненте есть слово «модель», а не немного избыточно.

Поскольку ваш компонент, похоже, является центром обмена сообщениями, почему бы не включить Сообщение в его названии. Как насчет MessageSender.

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

Если вы хотите получить хороший пример этого, взгляните на библиотеки Java или .Net.

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

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

MessageSender кажется ИМХО подводит итог цели вашего компонента. Кажется странным, что ваша вещь, которая отправляет «файлы» и «события», не включает эти два описательных слова. Материал, который вы используете в своих именах, является излишним, и IMHO не соответствует вашему описанию компонента.

Answer 8

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

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

Answer 9

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