Чистый код. Создание, анализ и рефакторинг - [17]
Имена accountAddress и customerAddress хорошо подходят для экземпляров класса Address, но для классов такой выбор неудачен. Address — вот хорошее имя класса. Если потребуется подчеркнуть различия между MAC-адресами, адресами портов и веб-адресами, я подумаю об использовании имен PostalAddress, MAC и URI. Полученные имена становятся более точными, а это, собственно, и является главной целью всего присваивания имен.
Несколько слов напоследок
Основные трудности с выбором хороших имен обусловлены необходимостью хороших описательных навыков и единого культурного фона. Это вопрос преподавания, а не вопрос техники, экономики или управления. В результате многие специалисты, работающие в этой области, так и не научились хорошо справляться с этой задачей.
Люди также опасаются переименований из страха возражений со стороны других разработчиков. Мы не разделяем эти опасения, а изменение имен (в лучшую сторону) вызывает у нас только благодарность. Большей частью мы не запоминаем имена классов и методов. Современные инструменты берут на себя подобные мелочи, а мы следим за тем, чтобы программный код читался как абзацы и предложения или хотя бы как таблицы и структуры данных (предложение не всегда является лучшим способом отображения данных). Возможно, своими переименованиями — как и любыми другими усовершенствованиями кода — вы кого-то удивите. Пусть это вас не останавливает.
Последуйте этим правилам и посмотрите, не станет ли ваш код более удобочитаемым. Если вы занимаетесь сопровождением чужого кода, попробуйте решить проблемы средствами рефакторинга. Это даст немедленный результат и продолжит приносить плоды в долгосрочной перспективе.
Глава 3. Функции
На заре эпохи программирования системы строились из программ, функций и подпрограмм. До наших дней дожили только функции. Они образуют первый уровень структуризации в любой программе, и их грамотная запись является основной темой этой главы.
Рассмотрим код в листинге 3.1. В FitNesse[10] трудно найти длинную функцию, но после некоторых поисков мне это все же удалось. Функция не только длинна, но она содержит повторяющиеся фрагменты кода, множество загадочных строк, а также странные и неочевидные типы данных и функции API. Попробуйте разобраться в ней за три минуты. Посмотрим, что вам удастся понять.
>public static String testableHtml(
> PageData pageData,
> boolean includeSuiteSetup
>) throws Exception {
> WikiPage wikiPage = pageData.getWikiPage();
> StringBuffer buffer = new StringBuffer();
> if (pageData.hasAttribute("Test")) {
> if (includeSuiteSetup) {
> WikiPage suiteSetup =
> PageCrawlerImpl.getInheritedPage(
> SuiteResponder.SUITE_SETUP_NAME, wikiPage
> );
> if (suiteSetup != null) {
> WikiPagePath pagePath =
> suiteSetup.getPageCrawler().getFullPath(suiteSetup);
> String pagePathName = PathParser.render(pagePath);
> buffer.append("!include -setup .")
> .append(pagePathName)
> .append("\n");
> }
> }
> WikiPage setup =
> PageCrawlerImpl.getInheritedPage("SetUp", wikiPage);
> if (setup != null) {
> WikiPagePath setupPath =
> wikiPage.getPageCrawler().getFullPath(setup);
> String setupPathName = PathParser.render(setupPath);"
> buffer.append("!include -setup .")
> .append(setupPathName)
> .append("\n");
> }
> }
> buffer.append(pageData.getContent());
> if (pageData.hasAttribute("Test")) {
> WikiPage teardown =
> PageCrawlerImpl.getInheritedPage("TearDown", wikiPage);
> if (teardown != null) {
> WikiPagePath tearDownPath =
> wikiPage.getPageCrawler().getFullPath(teardown);
> String tearDownPathName = PathParser.render(tearDownPath);
> buffer.append("\n")
> .append("!include -teardown .")
> .append(tearDownPathName)
> .append("\n");
> }
> if (includeSuiteSetup) {
> WikiPage suiteTeardown =
> PageCrawlerImpl.getInheritedPage(
> SuiteResponder.SUITE_TEARDOWN_NAME,
> wikiPage
> );
> if (suiteTeardown != null) {
> WikiPagePath pagePath =
> suiteTeardown.getPageCrawler().getFullPath (suiteTeardown);
> String pagePathName = PathParser.render(pagePath);
> buffer.append("!include -teardown .")
> .append(pagePathName)
> .append("\n");
> }
> }
> }
> pageData.setContent(buffer.toString());
> return pageData.getHtml();
>}
Удалось ли вам разобраться с функцией за три минуты? Вероятно, нет. В ней происходит слишком много всего, и притом на разных уровнях абстракции. Загадочные строки и непонятные вызовы функций смешиваются в конструкциях if двойной вложенности, к тому же зависящих от состояния флагов.
Но после выделения нескольких методов, переименований и небольшой реструктуризации мне удалось представить смысл этой функции в девяти строках листинга 3.2. Посмотрим, удастся ли вам разобраться в ней за следующие три минуты.
>public static String renderPageWithSetupsAndTeardowns(
