I do also name my database columns with a trailing ?, it does mean needing to quote the field when writing SQL by hand (like in psql).
jswanner
3
sodapopcan
dimitarvp
Nefcairon
frankdugan3
Specifically for functions, doesn’t specify variables/fields. That distinction is even in the poll.
0
Nefcairon
frankdugan3
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. 
1
thiagomajesk
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.
0
frankdugan3
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.
2
dimitarvp
Exactly. Hence you either have pre-commit GIT hook that runs your code through your own extra rules / linters, or just don’t bother at all because you’re only going to accumulate confusion and make your code error-prone with time.
Yeah, more or less this. I am well-aware that Ecto can help with the :source option for each field but I’ve only used it when I worked with legacy databases where the fields were confusingly named i.e. mid for match_id (football DB), rid (request_id), uwhen (inserted_at_utc of sorts) and the like.
I am not going to reach for Ecto’s name-overriding facilities due to some OCD that screams in my head that is_admin should really be admin?. Meh.
TL;DR your code and DB schema should be boring and predictable. Don’t act clever and keep your OCD away from both – or you and others are going to pay the price sooner or later.
1