Рубрика «рефакторинг» - 13

В первой части был написан лексер. Далее будет рассмотрена разработка парсера.

Парсер

Парсер будет реализован по алгоритму сортировочной станции, так как он достаточно прост и не нуждается в рекурсии. Сам алгоритм таков:

В начале даются пустой выходной поток и пустой стек. Начнём читать токены из входного потока по очереди.

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

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

Прикинем, какие тесты могут понадобиться для начала.

  • При получении пустого списка, возвращается пустой список.
  • При получении списка с одним числом, возвращается список с этим числом.
  • При получении [1 + 2], возвращается [1 2 +].
  • При получении [1 + 2 + 3], возвращается [1 2 + 3 +], так как оператор + является лево ассоциативным.
  • При получении [1 * 2 + 3], возвращается [1 2 * 3 +].
  • При получении [1 + 2 * 3], возвращается [1 2 3 * +], так как оператор * имеет больший приоритет.

Со скобками и ошибками разберёмся позднее. Итак, напишем первый тест из списка.

TEST_CLASS(ParserTests) {
public:
    TEST_METHOD(Should_return_empty_list_when_put_empty_list) {
        Tokens tokens = Parser::Parse({});
        Assert::IsTrue(tokens.empty());
    }
};

Читать полностью »

Введение

Пишем простой интерпретатор на C++ с помощью TDD, часть 1
Многие C++ программисты слышали про разработку через тестирование. Но почти все материалы по данной теме касаются более высокоуровневых языков и сосредоточены больше на общей теории, чем на практике. Итак, в данной статье я попробую привести пример пошаговой разработки через тестирование небольшого проекта на C++. А именно, как можно предположить из названия, простого интерпретатора математических выражений. Такой проект также является неплохой code kata, так как на его выполнение затрачивается не более часа (если не писать параллельно статью об этом).

Архитектура

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

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

  • Вычислять значение математического выражения, состоящего из чисел с плавающий точкой и математических операторов (-+/*).
  • Учёт приоритета операторов.
  • Учёт скобок.
  • Унарные плюс и минус.
  • Вычисление нескольких выражений, разделённых точкой с запятой (;).
  • Встроенные константы (pi, e).
  • Создание собственных констант с помощью оператора присваивания (=).
  • Встроенные функции с переменным числом аргументов.
  • Задание новых функций.

В данной статье будет реализация только первых трёх пунктов. Сам проект концептуально будет состоять из четырёх частей:

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

Инструментарий

Программа будет писаться в Visual Studio 2013 с установленным Visual C++ Compiler Nov 2013 CTP. Тесты будут на основе встроенного в студию тестового фреймворка для C++ проектов CppUnitTestFramework. Он предоставляет минимальную поддержку для написания модульных тестов (по сравнению с Boost.Test, или CppUTest), но, с другой стороны, хорошо интегрирован в среду разработки.

Итак, создадим новый проект типа «Native Unit Test Project» и удостоверимся, что всё компилируется.
Читать полностью »

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

Если вы хоть немного разделяете мои ощущения, то нам есть о чём поговорить. Дело в том, что со временем что-то внутри меня начало подсказывать, что рефакторить всё подряд, везде и всё время — не самая лучшая идея. Поймите меня правильно, код должен быть хорошим (а лучше бы ему быть идеальным), но в условиях суровой реальности не всегда разумно постоянно заниматься улучшением кода. Я вывел для себя несколько правил о своевременности рефакторинга. Если у меня начинают чесаться руки что-нибудь улучшить, то я оглядываюсь на эти правила и начинаю думать: «А действительно ли сейчас тот момент, когда нужно нарефакторить?». Давайте порассуждаем о том, в каких же случаях рефакторинг уместен, а в каких — не очень.Читать полностью »

Рабочий код != Хороший код
Когда я слышу фразу “Работает — не трогай”, мне хочется превратиться в большое зеленое существо и крушить все вокруг! Тот факт, что код работает, еще не значит что он хорош. В идеале, “код работает” — это только первая стадия, черновик, начало работы. Для большинства же, если код выполняет текущую бизнес-задачу — закоммитим и забудем.

Рабочий код написать не так уж сложно — нужно иметь немного мозгов и знать синтаксис языка. Для того, чтобы написать хороший код, нужно приложить куда больше усилий, однако, именно качество кода выделяет профессионалов среди огромного количества обычных кодеров. Под катом несколько субъективных советов о том, как писать хороший код.
Читать полностью »

Всё, что вы хотели узнать о рефакторинге, но боялись спросить Господа, рад представить вам свой новый проект — Refactoring.guru.

Сайт представляет собой каталог запахов грязного кода и, собственно, самих приёмов рефакторинга. В двух словах — это как книга Мартина Фаулера, но лучше. А именно:

  • Весь контент доступен на русском языке. Я старался делать описания как можно более живыми, чтобы избавиться от чувства унылости и скуки, которое возникает при чтении любой переводной книги о рефакторинге.
  • Все примеры подаются на Java и PHP. Другие языки обязательно будут добавляться со временем, но я пока затрудняюсь решить, каким будет следующий, можете предлагать в комментах.
  • Всё везде перелинковано. Рефакторинги сгруппированы по предназначениям и связям.

Супер-мега-фишка, которой я очень горжусь — интерактивные примеры с объяснениями (внизу страницы). Такими примерами пока что покрыты первые две главы, но я работаю над тем, чтобы добавить их и в остальные главы.

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

Буду рад всем отзывам и пожеланиям! (а также лайкам и твитам)

Читать полностью »

Есть немало книг, описывающих особенности и специфику конкретных БД.
Значительно меньше «программно-независимых» изданий, которые рассказывают об общих правилах и законах проектирования баз, принципах построения, нарушение которых может привести в дальнейшем к серьёзным ошибкам и проблемам. Где рассмотрена вся методологическая цепочка от постановки задачи до итогового анализа уровня целостности данных для каждого приложения.

Мы сейчас обсуждаем возможность издать на русском языке книгу Database Design for Mere Mortals: A Hands-On Guide to Relational Database Design и хотели бы включить в эту дискуссию «коллективный разум».

Уважаемые читатели! Пожалуйста, оцените это издание по пятибалльной шкале. Насколько оно раскрывает тему? Будет ли оно полезно разработчикам БД — лично вам, или, может быть, вашим менее опытным коллегам, которые смогут избежать ошибок проектирования?
Комментарии своей оценки, как всегда, приветствуются.
Читать полностью »

В октябре 2014 года впервые в Россию с мастер-классом приезжает .Net-гуру – Дино Эспозито.
Дино Эспозито является автором многих книг по .Net-программированию, техническим евангелистом разработки под Android и на Kotlin в JetBrains, а также членом команды, которая ведет WURFL, базу данных с информацией о мобильных устройствах, используемую компаниями Google и Facebook.

Предлагаем вам познакомиться с переводом одной из статей Дино «Проблемы с кодом? Помогите команде писать лучший код».
Читать полностью »

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

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

Luxoft Training приглашает Вас на мастер-классы одного из лучших тренеров в области архитектуры и разработки ПО – Евгения Кривошеева!
Читать полностью »

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

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

Если не хоите ходить по моим граблям, добро пожаловать под кат.Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js