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.

  • Congratulations! You might not have realized it, but you have designed and implemented a programming language. And now you see why language design is hard ;-) Aug 25, 2014 at 17:34

4 Answers 4


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.

  • I would also add that configuration for this sort of thing is the wrong answer. You are hitting a screw with a hammer. What you need is a screwdriver. There is nothing wrong with capturing business requirements in code. You just have to choose the right code. Aug 25, 2014 at 13:22
  • Most of the time, you wouldn't want external config for all your business objects but there are certain scenarios where it is desirable. E.g. complex data factories with a large number of data feeds.
    – Robbie Dee
    Aug 25, 2014 at 14:50

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)

        RuleFor(p => p.Body)

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

  • This raises an interesting point about the provenance of the data. If the application is creating the object then this sort of approach is perfect. But if the source is third party data, you'd probably want some sort of pre-validation or constructor checks.
    – Robbie Dee
    Aug 25, 2014 at 14:28

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.

  • Yes, if we suddenly decide surnames can be 30 rather than 20 characters, it seems a bit daft to have to code round this sort of thing every time...
    – Robbie Dee
    Aug 25, 2014 at 14:29
  • @RobbieDee Whether you need them in a separate config file depends I think on how often the requirements change and when. If it is only during development, then I don't think you need one. But if they are going to change once it is live, then there is an obvious advantage of being able to change them without having to recompile and deploy a new version of the app. And obviously if you do keep them in code, the actual parameters like length of a field should be constants declared at the top of the code (or like in C you would have them in the header file) so they are easy to find and change.
    – HamHamJ
    Aug 25, 2014 at 14:35
  • Also - the source of the data as I mentioned elsewhere...
    – Robbie Dee
    Aug 25, 2014 at 14:41

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.