Live data from Hacker News

Writing good code: how to reduce the cognitive load of your code

chrismm.com

121–130 of 187 posts

Re: Writing good code: how to reduce the cognitive load of your code

#121
This (arguably nice) post covers a small number of the points made in the book The Art of Readable Code: Simple and Practical Techniques for Writing Better Code[1]

I can recommend this to every programmer, even experienced ones, because even if they might know most of the things mentioned, it is presented in a very approachable, structured way and I think it always helpful, never boring and a diverting, easy read.

It also tackles these issues of "Gurus say" and "Everybody knows..." and tries hard to refrain from subjective matters, clearing up a few misunderstandings and old habits.

1: https://www.amazon.com/Art-Readable-Code-Practical-Technique...

Re: Writing good code: how to reduce the cognitive load of your code

#122

Whenever I read articles like this and the ensuing discussion that follows, I'm reminded of this quote from Dijkstra: Don't blame me for the fact that competent programming, as I view it as an intellectual possibility, will be too difficult for "the average programmer" — you must not fall into the trap of rejecting a surgical technique because it is beyond the capabilities of the barber in his shop around the corner.…

Functional programming is inscrutable by most. Berkeley uses LISP as a flunk out class to weed out freshman.

I find it odd that given in the physical world people require different shoe sizes for different feet that in the intellectual world people believe one size fits all, or that there is ultimately a single style of code that is comprehensible. Do you really believe our brains are all the same?

The functional programming crowd will always play a minor roll in human programming and not because as you suggest, you are all superior.

But rather it has to do with how brains differ. In fact I think the very real, emotional, visceral reaction people have to functional programming is key. People who love it, love it. Everyone else is completely demotivated by it. Lost in sets of parenthesis as the say. There is little middle ground. The very emotional reaction people have speaks volumes about how the brain views programming.

Spoken language changes every day because people use words differently due to brains being different. This vexes those who are compulsive about adhering to fixed definitions and grammar rules because of some imagined ideal. The same is playing out in software. We will always be creating new languages and tweaking them and there are there will be those who believe in an imaginary ideal of what readable code is.

Ultimately I think software writing needs to mature to where written language has matured: editors. Code review has some semblance as does paired programming. But editing is far more involved. Editors can reject entire writings.

So why do we need editors in the first place? Because in order to have happy consistency a set of rules is not enough. I comes down to style: a word here, a name change there. It may not seem like much but in fact it is.

Given a language is Turing complete, meaning it can exercise the full capability of the CPU and computer, then the choice of language and style is about the human condition, a condition which is as varied as the people in it.

If one cannot write code that ones finds usable then one needs to keep searching in earnest for a better style. However, once you have a style you can appreciate your own code from years ago then it is a matter of arbitrary standards when interacting with others. You have to draw the line somewhere but lets not pretend for a second that a single writing style is ideal for everyone, or even most. Its arbitrary because without any standards you have an unmanageable chaos.

Re: Writing good code: how to reduce the cognitive load of your code

#123
post #121

This (arguably nice) post covers a small number of the points made in the book The Art of Readable Code: Simple and Practical Techniques for Writing Better Code [1] I can recommend this to every programmer, even experienced ones, because even if they might know most of the things mentioned, it is presented in a very approachable, structured way and I think it always helpful, never boring and a diverting, easy read. I…

IMO, all the points comes from 2 basic rules: 1 KISS (keep it simple and stupid) 2 DRY (don't repeat yourself)

KISS being higher priority than DRY.

Re: Writing good code: how to reduce the cognitive load of your code

#124

I expected some science, however it's just subjective rules backed by nothing substantial.

That's because no one even knows how to start doing "science" in this direction. When you read the code there are so many different things influencing your understanding that it's hard to impossible to even list them all. And if you take a look at some of the things that might influence your understanding you'll notice that most of them are very hard to impossible to measure. From the top of my head, things which may…

"That's because no one even knows how to start doing "science" in this direction."

No true, there is an entire field of usability science. It is all still limited to experimental learnings as opposed to theoretical deterministic knowns.

Currently usability testing is only be applied to end users. There is no reason task analysis and the Jakob Neilson's 10 heuristic rules of basic usability cannot be applied to software itself. I apply the science of usability to written software.

Re: Writing good code: how to reduce the cognitive load of your code

#125

I expected some science, however it's just subjective rules backed by nothing substantial.

That's because no one even knows how to start doing "science" in this direction. When you read the code there are so many different things influencing your understanding that it's hard to impossible to even list them all. And if you take a look at some of the things that might influence your understanding you'll notice that most of them are very hard to impossible to measure. From the top of my head, things which may…

Science is hard, especially if done properly. The least they could do is to spit teams in two groups, based on whether they use a technique or not (e.g. unit testing, using OOP) and see if it makes any difference. It's far from perfect, but better than nothing.

> That's because no one even knows how to start doing "science" in this direction.

I suspect the reason almost no one do SW science is that nobody really cares. Most people just repeat some dogmas they like, e.g. they say: "you broke liskov substitution principle, that's bad" without any proof.

I guess people just like flamewars (who doesn't :)

Re: Writing good code: how to reduce the cognitive load of your code

#126
post #124

Earlier quoted context omitted.

That's because no one even knows how to start doing "science" in this direction. When you read the code there are so many different things influencing your understanding that it's hard to impossible to even list them all. And if you take a look at some of the things that might influence your understanding you'll notice that most of them are very hard to impossible to measure. From the top of my head, things which may…

"That's because no one even knows how to start doing "science" in this direction." No true, there is an entire field of usability science. It is all still limited to experimental learnings as opposed to theoretical deterministic knowns. Currently usability testing is only be applied to end users. There is no reason task analysis and the Jakob Neilson's 10 heuristic rules of basic usability cannot be applied to softwa…

Yes, but how many "usability studies" are done for writing software? I've seen onle a few and people write articles like this without any proofs daily.

Re: Writing good code: how to reduce the cognitive load of your code

#127
post #109

Earlier quoted context omitted.

I also don't understand this, nothing wrong about Yoda conditions and I don't understand the 'cognitive load' argument since the condition is just as readable. And: Visual Studio 2015 does not warn in the case of "if (a = 5)", not even at the highest warning level, only the VS2015 static code analyser catches this.

What is wrong with Yoda conditions? The very name is giving you a hint: they will feel natural only to Yoda. To humans, they will feel as they're written backwards.

Hey, germans are humans too!

Re: Writing good code: how to reduce the cognitive load of your code

#128
post #73

Earlier quoted context omitted.

I would argue that by using CONSTANT == variable, you are reducing the cognitive load of the compiler, but increasing the cognitive load of the human reading the code (who has to mentally flip the expression around). I think the original article intended to say the same thing.

Compilers don't have cognitive loads.

Ask C++ compilers when they have to chew through Boost ;)

Re: Writing good code: how to reduce the cognitive load of your code

#130
Stone Soup: all you need to code well are just these few little pebbles of wisdom. Oh plus 15 years of learning how to apply them intelligently in any given situation, and subject to any given constraint. At which point you don't really need my advice.

These articles are addictive but I suspect reading Code Complete one page a day might be more useful and ultimately more enjoyable.

Post reply on HN