Stop Naming Your Variables "Flag": The Art of Boolean Prefixes
13 points by typesanitizer
13 points by typesanitizer
Didn't think I'd be that guy, but doesn't this article smell kinda LLM-y?
The fancy quote marks. The kinda mushy prose. The endless bullet points.
Headings like Context Matters (The “Boolean Trap”)
Naming isn’t about style. It’s about empathy.
Definitely smells that way. There's also a noticeable stylistic shift when you compare the recent posts on that site compared to the archive going back to the pre-LLM era. The short sentences , whatever this overused construct is 'That friction is where bugs get introduced" and a dozen more.
Pangram also agrees, but then I don't hold that up to much. I'm getting sick of this shit, and I'm also getting sick of second guessing every other online encounter to consider if I'm actually reading the words of, or talking to a real person.
It's not even that the advice itself is bad or good or whatever, I'd just far rather read the thoughts of an actual person, mistakes and meandering lines of thought and all.
These days, there's also the social engineering aspect to consider, there are some very real and nefarious reasons why an actor might wish to eg build up a reputation, profile and background for a persona.
Renaming things is incredibly powerful in learning a codebase.
I'd say this applies when tossed into code no one left knows or remembers, or onto an evolving project where naming has deteriorated as the problem and solution space changed changed. It's a small win just making code require less effort to read. Tool supported renaming is useful, quick and often safe, but I've cut myself before on sharp edges like auto-serialization.
If you need to rename variables to understand the code, consider committing your renames. Likely, other people also struggle, and it only takes one person to agree for your efforts to get merged. As long as the code trends towards improvement, you're good.
I have the same philosophy for code comments and reorganizing functions.
A better option is to just stop using booleans for flags outside of cases where it very basic usage, ie setEnabled(bool), isEnabled() or similar.
This was one of the first bits of advice I was given by my first manager (though I can’t recall whether it was before or after I started getting paid).
Every time I come across functions with a boolean flag that is of the obvious yes/no form, or even worse (and the reason to prefer enums even for values where true/false might make sense in isolation) is functions with multiple boolean arguments.
The annoying thing for me in C++ is that you ideally want to use scoped enums, but those don’t have an implicit int conversion (which is the reason you’re using them) but they also don’t have a way to specify an explicit boolean conversion, so you can’t do if (someBooleanLikeEnum) :-/
You inherit a codebase and find this:
No, I generally don't. Do you have any real examples?
Are you asking the author for examples that you've encountered?
I'm confused how you could come to that conclusion. The code is obviously a contrived example, and I don't think it reflects reality.
I've read a lot of code, and don't think I've seen anyone name their variable bool flag. I've seen int flag a lot in, but that's used pretty much exclusively for bit-sets of flags with names. I also don't see much difference between bool enabled and bool isEnabled.
bool flag is a classic
I agree. I have seen bad code, but nothing like this. Maybe I'm lucky or maybe it's the world I'm in? Worst case, someone right-clicks the name and refactors it as a small PR that I'd instantly approve and merge.