🛡️ Project: Implementing a Strict Configuration File Validator

This project will guide you through building a simple but powerful linter/validator for a custom INI-style configuration file. It's a perfect real-world example of how the declarative power of the uCalc.Transformer can solve complex validation problems more safely and readably than manual string parsing or traditional Regular Expressions.

The Goal

We'll create a validator that scans a configuration file and reports whether it adheres to a strict set of structural rules.

The Configuration File Format

Our linter will analyze a simple INI-style format with sections (e.g., [Server]), key-value pairs (Host = db1), and comments (lines starting with ;).

Example config.ini:

; Main server settings[Server]Host = main_serverPort = 8080

The Validation Rules

Our validator must enforce the following rules:

1. The file must contain exactly one [Server] section.
2. The [Server] section must contain exactly one Host key.
3. The [Server] section must contain at least one Port key.
4. Lines starting with ; are comments and should be ignored.

The Strategy: Declarative Validation

Instead of writing complex, imperative code to loop through lines and maintain state, we will use the Transformer to define our rules declaratively.

• Hierarchical Parsing: We'll use a parent Rule to find the [Server] section and a LocalTransformer to validate the keys only within that section.
• Occurrence Constraints: We'll use the Minimum and Maximum properties on our rules to enforce the "exactly one" and "at least one" constraints.
• Ignoring Comments: A simple SkipOver rule will make comments invisible to our validation logic.

Step-by-Step Implementation

Step 1: Configure the Transformer

First, we create a Transformer instance. Since INI files are multi-line, we must disable StatementSensitive to allow patterns to match across newlines. We also add a rule to ignore comments.

csharp
using (var validator = new uCalc.Transformer()) {
validator.DefaultRuleSet.StatementSensitive = false;
validator.SkipOver(";{line}");
// ... rules go here ...
}


Step 2: Validate the [Server] Section

We define a Pattern to find the [Server] section. We then chain the Minimum(1) and Maximum(1) methods to enforce that it must appear exactly once.

### Step 3: Validate Keys within the SectionThis is where the hierarchy comes in. We get the [LocalTransformer](/Reference/uCalcBase/Rule/LocalTransformer) for our `serverRule`. Any rules defined on this local transformer will only run on the text captured by the `{body}` variable of the parent rule.```csharp
var local_t = serverRule.LocalTransformer;

// Rule for 'Host' key (must be exactly one)
var hostRule = local_t.Pattern("Host = {@Alpha}")
    .SetMinimum(1)
    .SetMaximum(1);

// Rule for 'Port' key (must be at least one)
var portRule = local_t.Pattern("Port = {@Number}")
    .SetMinimum(1);
```### Step 4: Run the ValidationWith all rules defined, we call [Find()](/Reference/uCalcBase/Transformer/Find) on the transformer. After it runs, we can inspect the [Matches().Count()](/Reference/uCalcBase/Matches/Count) for each rule. Because of our `Minimum` and `Maximum` constraints, a rule's match count will be `0` if its validation condition was not met, making the check simple.---## ⚖️ Why uCalc? (Comparative Analysis)Without uCalc, you would write imperative code:1.  Read the file line by line.2.  Use `string.StartsWith()` to check for comments or sections.3.  Use `string.Split('=')` to parse key-value pairs.4.  Maintain manual counters and boolean flags (`foundServerSection`, `hostCount`, etc.) to track state.This approach is brittle, hard to read, and difficult to maintain. uCalc's declarative model is superior because you simply **describe the rules of a valid file**, and the engine handles the complex state management and validation logic for you.