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) :-/
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.
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.
majaha | 18 hours ago
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”)The version from December even has em-dashes.
mdr | 14 hours ago
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.
mccd | 12 hours ago
Time to flip the "spam" flag to true.
pyj | 20 hours ago
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.
markerz | 14 hours ago
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.
olliej | 19 hours ago
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):-/orib | 21 hours ago
No, I generally don't. Do you have any real examples?
markerz | 14 hours ago
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.
icholy | 20 hours ago
Are you asking the author for examples that you've encountered?
orib | 20 hours ago
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 seenint flaga lot in, but that's used pretty much exclusively for bit-sets of flags with names. I also don't see much difference betweenbool enabledandbool isEnabled.icholy | 20 hours ago
I've seen examples like this and much worse. If you haven't then you should consider yourself lucky.
pyj | 19 hours ago
e_terekhin | 19 hours ago
bool flagis a classichcs | 17 hours ago
bool isFlagThinkChaos | 16 hours ago
bool toBeOrNotToBeFlag