Lesson #1 from the real world
Often, it can be tempting to let a single variable have multiple functions.
Such as letting the absence (or null value) denote some boolean decision.
An example of such could be for a uid field on an object denoting feedback.
Here, the initial attempt to model the object could be to let the absence of the field denote whether the user wants notification about feedback received.
However, this makes it hard for another developer to enter developments on the project.
If she is tasked with adding reminders for feedback, she will be in trouble: Who is the user, and what is the notification state of the said user?
The uid field on the feedback object is optional (nullable), and the comment says that absence means that the user does not wish to receive notifications.
Now the field has one more meaning: If defined, there will be sent a reminder, and the requester will be notified about new feedback. Otherwise, no notification and no reminders are sent.
Instead, allow multiple fields. Avoid conflating diverse meanings into the same field and keep side effects to single fields to a minimum. This enables faster engineering onboarding.
Please remember always to have compassion for other programmers and becurious about lessons.An obvious point for one programmer might be an epiphany for another.
Over and out Mads