The Cost of Scattered Validation Logic | The frustrated developer

Was expecting it to reference parse, don’t validate but now seems like the author might be one of today’s lucky 10000 (if they read lemmy comments)

I’m always fighting to get people to start thinking about areas of responsibility and consistency across codebases, since the natural tendency is to just add whatever functionality you think you need wherever you happen to be working at the time. I mostly work in C# but at least it has nullable annotations these days. I don’t think null guards are really that bad though, at least when you have a language that lets you do it smoothly, like Kotlin and Typescript. Like the author said, it mostly gets real bad when you let responsibilities get all muddy.

I recently made a lua framework that constructs callable tables to be used as functions that take a table as a dictionary of named argument. The function declares a schema of parameters with associated required/default/optional policies that put their respective values through a transform and validation pipeline. A similar pipeline can also be put on the result to make explicit guarantees. Can also configure whether argument errors/violations should throw or return results,error shape

The wrapped function recieves a table of processed arguments in a known state, while keeping that noise separate from the business logic. Also configurable at runtime with introspection, and param pipelines are immutable so they can be composed.

If that sounds like it introduces a lot of overhead, you’re right! But 1) it’s Lua and 2) omg is it so worth it when used properly. The UX is great; the callsite ergonomics, maintainability, and self-documenting nature is always what I felt was missing. Ships with & plays pretty well with type annotations too.

Anyways, that all makes it really convenient to know what’s responsible for what, and encourages pretty safe designs.