I see some people adopt this convention when naming fields or variables where the value is a boolean. I personally see this as an antipattern, curious what the group here thinks. E.g.
online? = user.status == :online
Should a boolean variable or field be named with a trailing question mark?
nope, only functions that return bool values should end with ?
I think it would help to explain why you see it as an anti-pattern. I personally really like it for variables, not so much for fields because it can cause issues with serialization (even though thanks to LiveView/OTP I haven’t had to work on a project that has a web API in a quite a while).
Perhaps I’m reading too much into your use of “should” here but my answer is that there is no “should” about it, it’s a question of style on a per-project basis.
It honestly does not matter, if your functions get so long that a ? suffix on variables inside them actually matters then you have much bigger problems to worry about, and you should address those first.
As for function suffixes, why not. It helps express intent a little bit.
IMO it’s a nice pattern that the language allows. You go to other languages codebases and you can always notice patterns like is_active all the time.
For values I would say I use it half the time, however I always use this pattern for functions, really helps to distinct them between simple functions and bang functions.
In that case I still don’t like any of the poll options, lol. No, it’s not an idiom and no, it’s not an anti-pattern. There is certainly no harm in it beyond personal preference. I personally really like the extra clarity and avoiding is_, has_ etc. And I don’t have an example off the top off my head but there are times where it’s awkward to come up with the correct English prefix or the correct one reads strangely. If I think of one I’ll post back.
For those who responded with “yes,” I have a question for you: Would you name your boolean database columns with a trailing question mark as well? I’m just curious to know the extent to which you would keep this naming convention in your apps.
PS.: I’m thinking in terms of keeping consistency with Ecto schemas (you can always specify the column source, but the mismatch might not be desirable)
Absolutely not, DB booleans will always be is_this_or_that on my watch. I have zero desire fighting with edge cases. Sticking to good old alpha-numeric strings for these things.
Notably you can have your cake and eat it too if you want by naming the database column via the is_ pattern and the Ecto schema via ? by using the source option.
I’m still undecided, but I lean toward the trailing ? for variables/fields. It should certainly be consistent within a project, that’s for sure.
Rather than being a convention, it would be better IMO if there was compiler support for guaranteeing that a trailing ? is always a boolean, whether function, variable, field etc. Similar to the checks on _ never being referenced or referencing non-existent struct fields. Obviously, that’s too much of a breaking change, will probably never happen. Could be something a tool like Credo detects, though.
Ok, my thread necromancy skills seem to be on point
It seems quite silly, but I caught myself wondering about this more times than I’m willing to admit, and it’s great to see I’m not alone (thanks OP for creating the poll BTW).
One thing is true: the docs make it very clear that this particular convention is about function names. So I wonder if the trend of using variables with trailing marks comes mainly from Ecto - the changeset.valid? is the one example that always gets a mention.
Although I’ve done it both ways, my current perception is that following this convention for fields/ variables can get tricky because of external data mismatch (as @dimitarvp and @jswanner noted). Ecto does make this a little easier for us, but still. I think you can only guarantee 100% consistency if you follow this convention for function names.
I think the gravitation toward the trailing ? is the desire to be able to know just by looking at the variable name that it’s a simple boolean, therefore requiring no further inspection to learn the variants. Reminds me a little bit of conventions like Hungarian Notation, which further reminds me of a similar problem: No compiler guarantees of the convention means the convention can lie to you about the data type.