To those who consider themselves heavy users of guards, could you share your rules of thumb?
When do you or don’t you use guards?
How about errors resulting from guards?
How do you think about them for different types of functions?
2 Likes
My rule of thumb is to use them when I need them. Or what do you mean?
And what do you mean by “errors from guards”? If something raises in a guard, it is considered as if the whole guard is false.
My rule of thumb is to use them when I need them. Or what do you mean?
I like guards, because they constrain the types of arguments, and force me to think about cases when they are not.
Somehow, it seems that using them for every function might be overkill.
On the flip side, the more you use them the more helpful Dialyzer checks will be, due to the constraints guards put on your functions…
Plus documentation - as opposed to type specs, if they go out of sync with your code, you will be forced to update them to keep things working…
I.e. perhaps there is no such thing as overkill when using guards…
To flip the question around: when do you need them?
And what do you mean by “errors from guards”?
For example, if I have something like,
def id(s) when is_binary(s), do: s
def id(s), do: nil
would you rather return nil or :error or {:error, "Argument is not a String"}.
I suppose it depends on the specific function, eh? Doubt there’s an idiomatic guard / type error?
Well, Guards are so much more than only checking for the type of an argument. I do usually only check for the type in public functions and in my private functions I do simply assume “everything is correct”.
It depends. But usually I do use an error-tuple or I crash. Also the case you drafted is not an error from a guard, its simply an unmatched function head. An error in a guard is the following:
def foo(a) when is_binary(a) && a + 1 <= 0, do: :unreachable
As this will raise. But that is “gulped” by the runtime and the whole guard is considered “unmatched” and the next function head is tested.
1 Like
I do usually only check for the type in public functions and in my private functions I do simply assume “everything is correct”
Aha, OK, so you have a public / private rule of thumb
I never thought about it that way before, that perhaps is a good way to go about ‘guarding’ functions
Well, for those typeguards, yes. But as I said, there is so much more in guards than only checking for types.
1 Like
when you have a chance, pls elaborate
I use guards in two cases:
- To help with pattern-matching when I have multiple functions. Usually these functions are then ‘complete’ (as opposed to ‘partial’ functions).
- To constrain the input types of the functions, especially when they are part of the public API of whatever it is I am writing.
2 Likes
Ahh… So you also have the public / private split. V good.
You can use guards to check if arbitrary conditions hold (well, nearly arbitrary)
def wordy_age(age) when age in 0..2, do: :baby
def wordy_age(age) when age in 3..6, do: :preschooler
...
def wordy_age(age) when age > 100, do: :methusalem
2 Likes
You can use them as a complement to a patternmatch (edit: qqwy already named that, example:)
defp get_task(%{:type => a} = element, socket) when a in ["exclusiveGateway","parallelGateway"],
do: get_tasks_after_element(element.id, socket)
3 Likes
I keep forgetting that “in” guard keyword, v sweet : )
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 Like
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 Likes
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 Likes
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 Like
