This is a follow up from my Why NOT write a parser? post. In this post I will take you through deriving actions from the abstract syntax tree.

This is a follow up from my Why NOT write a parser? post. In this post I will take you through creating the parser using TDD.

This is a follow up from my Why NOT write a parser? post. In this post I will take you through creating the parser.

This is a follow up from my Why NOT write a parser? post. In this post I will take you through designing the parser.

This is a follow up from my Why NOT write a parser? post. In this post I will take you through creating a lexical analyser.

While working on my Lexical Analyser post, I started thinking about the fact that I was going to show some essentially completed code, and related unit tests. In that post, I am repeating a pattern I have used before, but not copy-pasting from any other project. Just glibly producing a fully formed and fully tested class might not be as useful as showing how I arrived at the class and its unit tests.

This is a follow up from my Why NOT write a parser? post. In this post I will take you through creating a dot net core library and unit test library to hold the parser code. Future posts will fill out the projects.

Building a parser is one of those hard problems that you think twice about before attempting, but I think it’s good to have the know-how in your toolkit because now and then, they do make sense. This is particularly true if you are thinking like a library author¹.

Some years ago I came across a library called ApprovalTests.NET, and it has become a vital tool in all of my .NET test libraries.

In .NET I’ve used a useful technique many times before to avoid having to manually hook things together, by scanning for types in an assembly.

Some time ago I built a validation mechanism into a WPF application. We had literally hundreds of fields that need validation, and they could be displayed in various combinations. This was a WPF application using the MVVM pattern, and screens were composed from reusable components that could be put together in different combinations, and it was common for a component to be part of multiple windows. I didn’t want the validations to get in the way of the freedom of composition¹.

As a developer, the two things I care about the most are: