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.
I do, and honestly I find it pretty great even when I’m accessing it directly via psql or other db system. It just make the field clear on what it is without needing to investigate further what is it type.
I (and my team) also use it for all variables and functions, except for guards since the documentation says that guards should start with is_. I haven’t had any issues with serialization and API creation since we use Ash so renaming it for some API (GraphQL in our case) is pretty straightforward.
But at the end of the day, I would say that the most important thing is to define a guideline for the and stick with it (and make your team stick with it as-well), one of the worst things you can do for your project IMO is have code (and DB schemas) that is written in vastly different ways without any thought in making things standard, very easy to make a mess.
I prefer guidelines being as broadly shared as possible so per project guidelines are a no-go in my book. After all; what if your company acquires a code base? Would it not be great when it shares the same guideline as your current code bases, and all the code in public repos?
Therefor: I prefer the official Elixir guidelines and formatter. Even when I sometimes disagree (e.g. with formatting)
Based on the Enum module, I’d say it seems idiomatic to end boolean functions with a question mark. As noted earlier, Ecto changesets have a valid? key, and it seems reasonable to indicate boolean keys on a struct. Don’t forget to add typespecs to explicitly document what’s expected.
My hot take is that boolean fields in a database table are almost always a way to create pain for your future self and anyone who comes along after you. The classic example is an is_admin column in a user table. When you inevitably need to support more roles, you’ll need to figure out whether to use an Ecto.Enum field, a role association, or some other strategy.
Another example is would be status. Instead of using an is_completed boolean column, you’d have more flexibility with Ecto.Enum. We could talk about Event Sourcing, but that’s probably beyond the scope of this thread.
Booleans can definitely be the right choice sometimes, though often they are better served by a timestamp (unless you have extensive audit trailing). deleted_at is a classic example. In short, they are good when you have a enumerable status but there is the “elevated” deleted status that you don’t want to live alongside the primary one and you want to remember what the last primary status was when it was deleted (though ya, events could fix this). Actual booleans can be good for when something may get toggle on and off often. But ya, beyond the scope of this thread.
Yeah, good call out. I should have mentioned that while I do use a ? suffix for my boolean database columns, they are also rare. Not really meant for a state that is expected to change but instead to store essentially a static property of the thing
I had considered this, but from what I could tell, Postgres requires quotation marks when referencing non-standard column names. So I’m gonna stick with @dimitarvp on this one and stick with lowercase letters and underscores only.
