Writing good code: how to reduce the cognitive load of your code
1–10 of 187 posts
Re: Writing good code: how to reduce the cognitive load of your code
#2I don't understand the first example.
if (null != variable)
If this was JavaScript, this check includes undefined too. Not sure why it didn't use triple equal.
If this was just talking about placing a constant value to be compared before a more complicated expression, I really don't see a convincing argument for either. Does switching the order reduce the cognitive load that much?
Re: Writing good code: how to reduce the cognitive load of your code
#3I like code that reads like a Dick & Jane book ("See Dick. See Jane. See Dick run. See Jane run.").
However, it appears to be trendy to write insanely difficult to read code. To use the analogy, Shakespearean code. Instead of one line of code doing one thing the developers will write a ton of functionality into one line of code by using fluent and method chaining. As someone reviewing the code I have to keep this mental stack of what the code is doing and it just becomes too much to process.
It's a personal opinion, but I had to share.
Re: Writing good code: how to reduce the cognitive load of your code
#4I don't understand the first example. if (null != variable) If this was C, it should be NULL, and it is almost always better to just write `if (variable)` to check for NULL pointers instead. If this was JavaScript, this check includes undefined too. Not sure why it didn't use triple equal. If this was just talking about placing a constant value to be compared before a more complicated expression, I really don't see a…
"If this was C, it should be NULL, and it is almost always better to just write `if (variable)` to check for NULL pointers instead."
Imagine that it was this instead:
if (5 != variable)
Re: Writing good code: how to reduce the cognitive load of your code
#5I don't understand the first example. if (null != variable) If this was C, it should be NULL, and it is almost always better to just write `if (variable)` to check for NULL pointers instead. If this was JavaScript, this check includes undefined too. Not sure why it didn't use triple equal. If this was just talking about placing a constant value to be compared before a more complicated expression, I really don't see a…
To paraphrase the comment above that line, they say its purpose is to avoid accidental assignment. That's not an issue with "not equals" though, but that may just be their point.
As for whether it's more readable, I'm skeptical: It may save you going through some of the condition, but I believe getting used to it would make you more likely to overlook parts of the condition. Plus, the way it reads is the opposite of how you'd say what it does in English.
F̶i̶n̶a̶l̶l̶y̶,̶ ̶o̶b̶s̶c̶u̶r̶e̶ ̶a̶r̶c̶h̶i̶t̶e̶c̶t̶u̶r̶e̶s̶ ̶m̶a̶y̶ ̶d̶e̶f̶i̶n̶e̶ ̶a̶ ̶n̶o̶n̶-̶z̶e̶r̶o̶ ̶N̶U̶L̶L̶ (see to3m's reply). Using NULL makes it easier to find null pointer checks and conveys semantics (pointer vs integer).
Re: Writing good code: how to reduce the cognitive load of your code
#6The same holds true with APIs: too many concepts make a hard to understand API.
Re: Writing good code: how to reduce the cognitive load of your code
#7Writing good technical articles: if a part is probably the most important part, put it first (or nearly first) in the doc & don't waste the readers time congratulating them for spending 2 minutes reading.
Re: Writing good code: how to reduce the cognitive load of your code
#8Some good previous discussion: Simple Ways of Reducing the Cognitive Load in Code
https://news.ycombinator.com/item?id=11992684
My comment there is still relevant here:
I've noticed recently that especially in online discussions, the term "cognitive load" is used as a catch-all excuse to rag on code that someone doesn't like. It appears to be a thought-terminating cliché.
There's definitely room to talk about objective metrics for code simplicity, which are ultimately what many of these "cognitive load" arguments are about. But cognitive load seems to misrepresent the problem; I think it's hard to prove/justify/qualify without some scientific evidence over a large population sample.
With that said, the article presented fine tips, but they seem to be stock software engineering tips for readable code.
Re: Writing good code: how to reduce the cognitive load of your code
#9I don't understand the first example. if (null != variable) If this was C, it should be NULL, and it is almost always better to just write `if (variable)` to check for NULL pointers instead. If this was JavaScript, this check includes undefined too. Not sure why it didn't use triple equal. If this was just talking about placing a constant value to be compared before a more complicated expression, I really don't see a…
The article says:
// This was useful in C to avoid accidentally
// typing variable = null. These days it will
// confuse most people, with little benefit.
Re: Writing good code: how to reduce the cognitive load of your code
#10I don't understand the first example. if (null != variable) If this was C, it should be NULL, and it is almost always better to just write `if (variable)` to check for NULL pointers instead. If this was JavaScript, this check includes undefined too. Not sure why it didn't use triple equal. If this was just talking about placing a constant value to be compared before a more complicated expression, I really don't see a…
> almost always better to just write `if (variable)`
Close enough works for horseshoes but not for C. It has to work 100% of the time to be acceptable (int variable = 0;)