Кто-нибудь еще считает наименование классов и методов одной из самых сложных частей в программировании? [закрыто]

275

Поэтому я работаю над этим классом, который должен запрашивать справочную документацию у поставщика через веб-сервис. Я стараюсь , чтобы назвать его DocumentRetriever, VendorDocRequester, DocGetter, но они просто не кажутся правильными. Я полчаса перебирал словарь dictionary.com, пытаясь найти подходящее слово.

Начинать программирование с дурных имен - все равно, что иметь очень плохой день с утра, остальная часть дня уходит вниз. Чувствуй меня?

Haoest
источник
2
Зачем вам нужен класс, когда вам явно нужна только функция? Обязательно проверьте steve-yegge.blogspot.com/2006/03/… для глагола как проблемы с именем класса.
user51568
Или двигаться вперед и рефакторинг, когда вы, наконец, знаете, как это должно называться.
Эстебан Арайя
16
Что вы называете ?: методы : использовать глаголы , такие как get, set, save и т. Д. Классы и переменные : использовать существительные , такие как документы, пользователь, контекст и т. Д. Интерфейсы : использовать прилагательные , такие как печатные, клонируемые, повторяемые и т. Д. После прочтения этой темы мне нравится предложение Спольски для классов и переменных (в нем используются существительные) и предложение TravisO для методов (в нем используются глаголы). Также не создавайте объекты, заканчивающиеся на «er» .
Даниэль Гасулл
5
«В компьютерной науке есть две серьезные проблемы: аннулирование кэша, соглашения об именах и переполнение без вывода сообщений».
Каракури
6
@karakuri Версия, которую я услышал: «В компьютерных науках есть две серьезные проблемы: именование и смещение на 1 ошибку».
Haoest

Ответы:

121

То, что вы делаете сейчас, хорошо, и я настоятельно рекомендую вам придерживаться вашего текущего синтаксиса:

контекст + глагол + как

Я использую этот метод для присвоения имен функциям / методам, хранимым в SQL процессам и т. Д. Придерживаясь этого синтаксиса, ваши панели Intellisense / кода будут намного более аккуратными. Поэтому вы хотите EmployeeGetByID () EmployeeAdd (), EmployeeDeleteByID (). Когда вы используете более грамматически правильный синтаксис, такой как GetEmployee (), AddEmployee (), вы увидите, что это становится действительно грязным, если у вас есть несколько Gets в одном классе, поскольку несвязанные вещи будут сгруппированы вместе.

Я похож на именование файлов с датами, вы хотите сказать, что 2009-01-07.log не 1-7-2009.log, потому что после того, как у вас их много, порядок становится совершенно бесполезным.

TravisO
источник
29
Я предпочитаю выводить контекст из имени типа при именовании методов ... class EmployeeRepository {void Add (Employee employee); void Get (int id); void GetAll (); void GetAll (Action <FilterCriteria> filter); } Что вы думаете?
Вьяс Бхаргава
5
Также помогает, если у вас есть стандартный список «домашних» глаголов. Так что всегда есть Get, а не Load / Read / Retrieve / Select / Find .... и т. Д.
Мертвый аккаунт
2
Ричард, вы правы в сценариях ООП, мой ответ немного отступил и был скорее общим предложением по кодированию. Я думаю, что технически это относится больше к языкам без ООП. Employee.Add () и Employee.GetByID () будут лучшим использованием в ООП.
TravisO
6
Мне нравится эффект Intellisense вашего предложения, но я предпочитаю подход, который немного более грамотный. Поэтому я бы предпочел Employee.SetSupervisor (), а не Employee.SupervisorSet (), потому что он читает (больше похоже на естественный английский.
Мэтью Маравильяс
12
Но @TravisO, это не очень хорошо звучит на английском языке. Вы не получаете работника, вы получаете работника. Что делать, если у вас есть более сложные действия с прилагательными, такими как InvalidateObsoleteQueries? QueriesInvalidateObsoleteтрудно читать и не имеет смысла. Кроме того, в C #, особенно с Resharper, алфавитный порядок не имеет значения. Если вы начинаете набирать «эй», Resharper даст вам GetEmployee, SetEmployeeи даже PopulateInactiveEmployeesList.
Илья Коган
54

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

  • тебе это не нужно
  • это слишком много
Toon Krijthe
источник
13
Или это слишком мало.
user51568
4
Спасибо, это на самом деле было актуально для меня.
Haoest
52

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

Для функций и для одноэлементных классов я тщательно исследую функцию, чтобы увидеть, является ли ее основная функция преобразованием одного вида вещи в другой тип вещи. Я использую этот термин очень свободно, но вы обнаружите, что ОГРОМНОЕ количество написанных вами функций, по сути, принимает что-то в одной форме и производит что-то в другой форме.

В вашем случае это звучит так, как будто ваш класс превращает URL в документ. Немного странно думать об этом таким образом, но совершенно правильно, и когда вы начнете искать этот паттерн, вы увидите его повсюду.

Когда я нахожу этот шаблон, я всегда называю функцию x Fromy .

Поскольку ваша функция преобразует URL в документ, я бы назвал его

DocumentFromUrl

Эта модель замечательно распространена. Например:

atoi -> IntFromString
GetWindowWidth -> WidthInPixelsFromHwnd // or DxFromWnd if you like Hungarian
CreateProcess -> ProcessFromCommandLine

Вы также можете использовать, UrlToDocumentесли вам удобнее с этим заказом. Говорите ли вы x Fromy или y Tox , вероятно, дело вкуса, но я предпочитаю Fromпорядок, потому что таким образом начало имени функции уже говорит вам, какой тип она возвращает.

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

Джоэл Спольски
источник
Хорошее напоминание о том, что в языках ООП имена классов не всегда должны быть существительными, но иногда они могут быть «словесными». Поэтому практикующие ООП часто бывают сбиты с толку (как человек, задающий вопрос), поскольку слишком много подчеркивают, что занятия должны быть «вещью» в реальном мире.
Рэй
7
XFromY-Convetion в основном повторяет то, что находится в возвращаемом типе и списке параметров: Foo fooFromBar (Bar bar). Это зависит от вас, если вы называете эту последовательность или переизбыток.
Лена Шиммель
«В вашем случае это звучит так, как будто ваш класс превращает URL в документ». С каких это пор классы должны «делать» что-то, а не представлять понятия?
user51568
6
@ Брайан: это только избыточно в одном месте ... в декларации. Везде, где вы его используете, приятно иметь небольшое напоминание о типах данных. Делает код более читабельным, не возвращаясь к объявлению.
Джоэл Спольски
3
@ stefan- В некоторых языках, таких как C # и Java, весь код должен быть инкапсулирован в класс, в отличие от C ++. Функции не являются первоклассными гражданами в этих языках, если вы хотите модульный код. Поэтому иногда вы получаете класс, который может «делать» такие вещи, как функция.
Ray
31

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

Брэд Баркер
источник
3
Очень хорошая мысль, правда.
Камило Мартин
27

Тема 1:

function programming_job(){
    while (i make classes){
         Give each class a name quickly; always fairly long and descriptive.
         Implement and test each class to see what they really are. 
         while (not satisfied){
            Re-visit each class and make small adjustments 
         }
    }
}

Тема 2:

while(true){
      if (any code smells bad){
           rework, rename until at least somewhat better
      }
}

Там нет Thread.sleep (...) нигде здесь.

krosenvold
источник
24

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

Для вашего класса я бы предложил VendorHelpDocRequester.

кодироватьjavaforfood
источник
1
> VendorHelpDocRequester Хороший. Я на самом деле гуглил Requestor, а не Requester, оба, кажется, являются законными английскими словами.
Haoest
1
Я сделал это один или два раза :)
willcodejavaforfood
1
Наличие глагола в названии класса всегда звучит неправильно для меня. Плюс это всегда приводит к некоторому дублированию в использовании (то есть:) VendorHelpDocRequester.request(). Я бы предпочел только форму множественного числа, такую ​​как `VendorHelpDocs.request () '
Эдсон Медина
19

В книге Code Complete Стивом Макконнеллом есть хорошая глава по именованию переменных / классов / функций / ...

Эмиль Врейдагс
источник
это одна из моих любимых книг, очень рекомендую
willcodejavaforfood
2
+1 для тех, кто когда-либо упоминал код завершения!
Ричард Эв
15

Я думаю, что это побочный эффект.

Это не фактическое наименование, это сложно. Трудно то, что процесс именования заставляет вас столкнуться с ужасным фактом, что вы понятия не имеете, что, черт возьми, вы делаете.

Nosredna
источник
12

Я на самом деле только что услышал эту цитату вчера, через блог Signal vs. Noise на 37Signals, и я, безусловно, согласен с этим:

«В информатике есть только две сложные вещи: аннулирование кэша и присвоение имен». - Фил Карлтон

Джонатан Шустер
источник
simonwillison.net/2007/Jul/5/hard привел меня к tbray.org/ongoing/When/200x/2005/12/23/UPI, который привел меня на karlton.hamilton.com и далее на karlton.hamilton.com/quotes /showallquotes.cgi , который не включает цитату! (Но я узнаю № 5 по Scrum.)
Дэрил Спитцер
1
«Две сложные вещи в области компьютерных наук: аннулирование кэша, присвоение имен и ошибки« один на один ».»
Дэн Лугг
7

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

JW.
источник
6

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

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

Даниэль Шаффер
источник
6

В прошлом месяце я просто писал о соглашениях об именах: http://caseysoftware.com/blog/useful-naming-conventions

Суть этого:

verbAdjectiveNounStructure - со структурой и прилагательным в качестве необязательных частей

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

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

Структура не является обязательным , потому что это уникальный для ситуации. Экран распечатки может запросить список или массив. Одной из основных функций, используемых в списке проектов для web2project, является просто getProjectList. Он не изменяет базовые данные, а только представление данных.

Эти прилагательные являются чем - то совершенно другое. Они используются как модификаторы существительного. Нечто столь простое, как getOpenProjects, может быть легко реализовано с помощью getProjects и параметра switch, но это имеет тенденцию генерировать методы, которые требуют некоторого понимания базовых данных и / или структуры объекта ... не обязательно того, что вы хотите поощрять. Имея более явные и конкретные функции, вы можете полностью обернуть и скрыть реализацию из кода, использующего его. Разве это не один из пунктов ОО?

CaseySoftware
источник
4

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

Рассмотрим макет вашего приложения сейчас:

  • Приложение
    • VendorDocRequester (чтение из веб-службы и предоставление данных)
    • VendorDocViewer (используйте реквестер для предоставления документации поставщика)

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

  • Приложение
    • VendorDocs
      • Модель
        • Документ (простой объект, который содержит данные)
        • WebServiceConsumer (разбираться с мелочами в веб-сервисе)
      • контроллер
        • DatabaseAdapter (обрабатывает персистентность, используя ORM или другой метод)
        • WebServiceAdapter (используйте Consumer для захвата документа и помещения его в базу данных)
      • Посмотреть
        • HelpViewer (используйте DBAdapter, чтобы выплюнуть документацию)

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

Еще одно очень важное предложение: сделайте себе одолжение и возьмите копию Head First Design Patterns. Это фантастическая, легко читаемая книга, которая поможет вам организовать ваше приложение и написать лучший код. Оценив шаблоны проектирования, вы поймете, что многие проблемы, с которыми вы сталкиваетесь, уже решены, и вы сможете включить эти решения в свой код.

Майк Гриффит
источник
4

Лео Броди в своей книге «Мышление вперед» писал, что самой трудной задачей для программиста было хорошо назвать вещи, и заявил, что наиболее важным инструментом программирования является тезаурус.

Попробуйте использовать тезаурус по адресу http://thesaurus.reference.com/ .

Кроме того, никогда не используйте венгерскую нотацию, избегайте аббревиатур и будьте последовательны.

С наилучшими пожеланиями.

Роб Уильямс
источник
1
+1 с пометкой, что вы не должны использовать то, что называется системной венгерской; Приложение венгерский может быть полезным иногда, особенно на языке программирования без хорошей системы ввода.
user51568
Я никогда не слышал о системе и приложении венгерской нотации, но ни одна из них не является хорошей идеей в любой среде - вы всегда должны называть, основываясь на том, ЧТО, а не КАК, и венгерский полностью о том, как.
Роб Уильямс
@RobWilliams Я думаю, что они имели в виду статью Джоэла Спольски
Алоис Махдал
1
@RobWilliams Кроме того, вы уверены, что «я никогда не слышал о X против Y, но ни одна из них не является хорошей идеей ...» ...? :)
Алоис Махдал
4

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

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

Долго: как
правило, часто не стоит слишком долго думать о названии перед внедрением. Если вы реализуете свой класс, называя его «Foo» или «Dsnfdkgx», при реализации вы видите, как вы должны были его назвать.

Особенно с Java + Eclipse, переименование вещей не представляет никакой проблемы, поскольку оно тщательно обрабатывает все ссылки во всех классах, предупреждает вас о конфликтах имен и т. Д. И пока класс еще не находится в репозитории контроля версий, я не буду Не думаю, что что-то не так с переименованием в 5 раз.

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

Лена Шиммель
источник
3

Почему бы не HelpDocumentServiceClient вроде «полный рот» или HelpDocumentClient ... не важно, что это поставщик, дело в том, что это клиент веб-службы, которая имеет дело с документами справки.

И да, назвать это сложно.

JoshBerke
источник
3

У этого класса есть только одно разумное имя:

HelpRequest

Не позволяйте деталям реализации отвлекать вас от смысла.

Ангус Глашер
источник
Полтора года спустя я собирался предложить HelpLibraryдля класса, но это по крайней мере так же хорошо. Сначала стоит прочитать ответы!
Джефф Стерн
2

Инвестируйте в хороший инструмент рефакторинга!

TGnat
источник
ржунимагу. Иногда рефакторинг - не лучший вариант (большие проекты на C ++), но я, конечно, прибегал к нему раньше. Иногда мне просто нужно что-то сделать, а имена приходят ко мне позже.
Стив С
2

Я придерживаюсь основ: VerbNoun (аргументы). Примеры: GetDoc (docID).

Нет необходимости фантазировать. Это будет легко понять через год, будь то вы или кто-то еще.

LJ.
источник
Хотя это хорошо читается, оно плохо организовано, потому что оно задом наперед. Лучше сказать DocGet (), потому что, когда вы также создаете DocAdd () DocRemove () и т. Д., Все они появляются вместе в списке. Ваш метод действительно показывает, насколько уродливым становится, когда у вас есть десятки Gets или еще много чего.
TravisO
Отличное предложение, TravisO.
Джон Смок
Я бы не использовал глагол для класса.
willcodejavaforfood
2

Мне все равно, как долго имя метода или класса будет таким же описательным и в правильной библиотеке. Давно прошли те дни, когда вы должны помнить, где находится каждая часть API.

Intelisense существует для всех основных языков. Поэтому при использовании стороннего API я предпочитаю использовать его intelisense для документации, а не «фактическую» документацию.

Имея это в виду, я в порядке, чтобы создать имя метода, такого как

StevesPostOnMethodNamesBeingLongOrShort

Долго - ну и что. Кто не использует 24-дюймовые экраны в эти дни!

Стив
источник
1

Я должен согласиться, что присвоение имен - это искусство. Это становится немного легче, если ваш класс следует определенной «схеме спада» (фабрика и т. Д.).

Otávio Décio
источник
1

Это одна из причин иметь стандарт кодирования. Наличие стандарта, как правило, помогает придумывать имена, когда это необходимо. Это помогает освободить ваш разум, чтобы использовать его для других более интересных вещей! (-:

Я бы порекомендовал прочитать соответствующую главу Стив Макконнелла Code Complete ( ссылка Amazon ), в которой приведены несколько правил, чтобы помочь удобочитаемости и даже удобству обслуживания.

НТН

веселит,

обкрадывать

Роб Уэллс
источник
1

Нет, отладка - самая сложная вещь для меня! :-)

Рагу S
источник
отладка обычно сводится к постановке правильного вопроса. Это игра с числами, в которой вам нужно угадать число от 1 до 1000. Если ваше предположение слишком низкое или высокое, консоль скажет вам об этом, и у вас есть только 10 попыток. Чем ты занимаешься?
Haoest
1

DocumentFetcher? Трудно сказать без контекста.

Это может помочь вести себя как математик и заимствовать / придумывать лексикон для своего домена по ходу дела: выбирайте короткие простые слова, которые предлагают концепцию, не произнося ее каждый раз. Слишком часто я вижу длинные латинские фразы, которые превращаются в аббревиатуры, поэтому вам все равно нужен словарь для аббревиатур .

Дариус Бэкон
источник
1

Язык, который вы используете для описания проблемы, это язык, который вы должны использовать для переменных, методов, объектов, классов и т. Д. В общем, существительные соответствуют объектам, а глаголы - методам соответствия. Если вам не хватает слов для описания проблемы, вам также не хватает полного понимания (спецификации) проблемы.

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

Если сомневаешься, спи на нем и выбери первое наиболее очевидное имя на следующее утро :-)

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

Павел.

Кстати: Document.fetch () довольно очевиден.

Пол У Гомер
источник
1

Я обнаружил, что у меня больше всего проблем с локальными переменными. Например, я хочу создать объект типа DocGetter. Так что я знаю, что это DocGetter. Почему мне нужно дать ему другое имя? Я обычно заканчиваю тем, что даю ему имя вроде dg (для DocGetter) или temp или что-то такое же неописательное.

Джейсон Бейкер
источник
1

Не забывайте, что шаблоны проектирования (не только GoF) являются хорошим способом предоставления общего словаря, и их имена следует использовать всякий раз, когда вы подходите к ситуации. Это даже поможет новичкам, знакомым с номенклатурой, быстро понять архитектуру. Этот класс, над которым вы работаете, должен действовать как Прокси или даже Фасад?

Herrmann
источник
1

Разве документация поставщика не должна быть объектом? Я имею в виду, что это материально, а не просто как антропоморфизация части вашей программы. Таким образом, у вас может быть VendorDocumentationкласс с конструктором, который извлекает информацию. Я думаю, что если имя класса содержит глагол, часто что-то идет не так.

Сванте
источник
1

Я определенно чувствую тебя. И я чувствую твою боль. Каждое имя, о котором я думаю, просто кажется мне чепухой. Все это кажется настолько общим, и я хочу в конечном итоге научиться придавать немного чуткости и креативности моим именам, чтобы они действительно отражали то, что они описывают.

Одно из предложений, которое у меня есть, - обратиться к тезаурусу. У Word есть хороший пример, как и у Mac OS X. Это действительно может помочь мне выкинуть голову из облаков и дать мне хорошее начальное место, а также вдохновение.

Джон Галлахер
источник
0

Если имя будет объяснено программисту-непрофессионалу, то, вероятно, нет необходимости его менять.

dreamlax
источник