Developing configuration syntax - best practise/rules/methods?

Question

I am currently developing a small application, which checks if provided data meets certain requirements. The requirements are actually a long list, and might be changing, so I defined a syntax which allows me to state all of the requirements briefly and in a seperate file.

Now the overall requirements for the application have changed, and I need to change my configuration syntax. Which leeds me to wonder if there is methodoloy or best practise for developing such syntaxes. Currently what I do is

• I think about the requirements and come up with an initial syntax,
• start configuring the first few items and see how it works.
• If I come upon something that does not work well or not at all with the current syntax, I change the syntax, if possible in a backward compatible way.

This somehow works for me, but it feels a bit like fishing in troubled water. Also I feel it does not nessessarly lead to the most concise and easy to understand/use syntax.

So I was wondering what other people do, especially if there is a better approach to this.

Answer 1

My experience is that it isn't worth spending too much time on perfecting a syntax for expressing requirements.

The requirements will change again, and very probably in ways that you didn't anticipate, so it's unlikely that you will hit on the perfect solution in any reasonable time frame. It is usually easier to just keep around the old parsing code as a fallback to call when dealing with legacy data, even a series of such fallbacks if necessary. It looks kind of ugly, but backwards compatibility is ugly, and I consider it OK if the code reflects that, as long as each alternative parsing strategy is reasonably nice on its own.

Answer 2

Most languages have some sort of validation library available to you. In C#, for example, I've used FluentValidation, which allows you to specify your business rules with a fluent API.

public class Post
{
    public string Title;
    public string Body;
    public DateTime CreatedAt;
}

And the validator:

public class PostValidator : BaseValidator<Post>
{
    public PostValidator()
    {
        RuleFor(p => p.Title)
            .NotEmpty()
            .Length(1,50);

        RuleFor(p => p.Body)
            .NotEmpty();
    }
}

Something like this is recommended, especially since many of these validation libraries are unit testable.

Answer 3

This seems like the sort of situation where XML would work well. You can start with basic tags for things like being required, or being a given length, etc; and if later you get new requirements that need a new kind of constraint, you just add a tag and code to check for that tag.

Answer 4

I used a utility program many years ago which did a similar thing. Given a flat file, it could parse each record and check each column met certain requirements.

The basic blocks were types, ranges and values.

Types were very basic ones such as:

• String
• Int
• Float
• Date

For some of these columns, ranges could be defined. For example, you could say that for a certain column, values 101-999 were valid values.

For more complex columns, you could define the valid values. E.g. for gender you might have:

• M
• F
• U

Simple but effective. We used it for all kinds of data files.