I keep forgetting that “in” guard keyword, v sweet : )
mmport80
mmport80
So far, it seems guard type checks are commonly used when an API will be external.
I wonder why we, who get our hands dirty with internals, don’t treat ourselves better and use type-constraint-style guards for better, more consistent documentation…
Sure it’s work, and I need to do it too.
Suspect it would be a v worthwhile habit to adopt…
1
dimitarvp
It is tedious alright. But I still try my best to use guards and limit what I receive even in my private functions.
Since Elixir is not statically typed and never will be – and since I want to use Elixir almost everywhere in my work – I compensate with guards and pattern-matching so as to catch errors as early as possible. Never again will I just catch the root of all exceptions (like many Java devs do) and just turn a blind eye to weak spots in the code.
BTW don’t forget about the relatively new defguard construct. It made my stricter code look cleaner.
4
Qqwy
TypeCheck Core Team
I know there are many people that only use guards in their public functions, but I use them in almost all functions when I want to make clear (to myself or co-workers in the future) what kind of datatype is expected somewhere.
The idea being that this is a weak form of ‘type checking’; I’d rather encounter a Function Clause Error while writing code with a clear diff between what was expected and what I provided, rather than an indecipherable error later on that happened because I passed something wrong inside.
I’ve heard the efficiency argument used to remove/reduce guards in private functions, but I think doing that from the get-go can be considered premature optimization.
2
dimitarvp
Absolutely. You are basically coding against a contract afterwards which makes things much clearer and more productive.
Yep. If we didn’t have that we might as well just code in vanilla Javascript. To me guards and pattern matching are a core value proposition of Elixir.
1