3 ms·
Separate types for each model id is an extremely tedious way of avoiding bugs that can easily be prevented by a single test.
by abujazar 1y ago
Separate types for each model id is an extremely tedious way of avoiding bugs that can easily be prevented by a single test.
- mcapodici 1y agoThere are other benefits over a test. The compiler tests the type is correct wherever you use it. It is also documentation. Still have tests! But types are great. But sadly, in practice I don't often use a type per ID type because it is not idiomatic to code bases I work on. It's a project of its own to move a code base to be like that if it wasn't in the outset. Also most programming languages don't make it ergonomic.
- dilap 1y agoPersonally I like it, and it catches bugs right away, especially when there are multiple possible ids, e.g. func AddMessage(u UserId, m MessageId) If it's just func AddMessage(userId, messageId string) it's very easy to accidentally call as AddMessage(messageId, userId) and then best-case you are wasting time figuring out a test failure, and worst case trying to figure out the bug IRL. V.S. an instant compile error. I have seen errors like this many times, both written by myself and others. I think it's great to use the type system to eliminate this class of error! (Especially in languages like Go that make it very low-friction to define the newtype.) Another benefit if you're working with any sort of static data system is it makes it very easy to validate the data -- e.g. just recursively scan for instances of FooId and make sure they are actually foo, instead of having to write custom logic or schema for everywhere a FooId might occur.
- Warwolt 1y agoTypes give you static proof where tests only give partial inductive evidence. I cannot _fathom_ why people would prefer tests over types where types do the job, outside anything but sheer ignorance.