Simple Ways of Reducing the Cognitive Load in Code • Hacker News Board

Re: Simple Ways of Reducing the Cognitive Load in Code

#51

Post by jorgeleo » Tue, Jun 28, 2016, 1:33 PM UTC

"How can a new developer just memorize all that stuff? “Code Complete“, the greatest exponent in this matter, is 960 pages long!"

First... do not memorize, but internalize, understand why they work, and when to apply which one. Use them to solve the problem of your code been read in 6 month by a serial killer that know your address.

Second... 960 pages. If you really want to advance the craft, if you really want to become a better developer, then you don't measure by the number of pages (what a sacrifice, I have to read), you measure by the amount of gold advice on the book. 960 pages is a lot of gold.

Third... If you read the whole blog and understood the value in following the Cliff notes to the Cliff notes that this post is, then you should be looking forward to read the 960 pages.

Re: Simple Ways of Reducing the Cognitive Load in Code

#52

Post by sevensor » Tue, Jun 28, 2016, 1:35 PM UTC

a3n wrote: post #6

iamleppert wrote: post #5

"Use names to convey purpose. Don't take advantage of language features to look cool." I can't say enough about this. Please write code that is easy to read and understand, not the most compact code, and not the most "decorated" code, or "pretty" code or neat because it uses that giant list expression or ridiculous map statement thats an entire paragraph long. Similarly what bugs me is when I receive a pull request w…

This isn't new, it has always been thus.

Indeed, and every piece of advice about coding style is sometimes wrong.

Re: Simple Ways of Reducing the Cognitive Load in Code

#53

Post by Sindisil » Tue, Jun 28, 2016, 1:36 PM UTC

majewsky wrote: post #4

I really like the advice from "Perl Best Practices" to code in paragraphs. Sometimes, a large function cannot be broken up usefully, because a lot of state needs to be shared between the different parts, or because the parts don't have a meaning outside of the very specific algorithm. In that case, code in paragraphs: Split the function body into multiple steps, put a blank line between these and, most importantly, a…

Situations like this are exactly where nested functions can be helpful.

I've always thought that it was a shame that C didn't have them.

Sometimes I almost wish that Algol flavored languages like Pascal anf Modula 2 would have won out for systems programming, instead of C and the languages it inspired.

Actually, GNU C supports nested functions, and a new round if standardization is just starting up, so maybe there's a chance?

Re: Simple Ways of Reducing the Cognitive Load in Code

#54

Post by phaed » Tue, Jun 28, 2016, 1:42 PM UTC

jorgeleo wrote: post #51

"How can a new developer just memorize all that stuff? “Code Complete“, the greatest exponent in this matter, is 960 pages long!" First... do not memorize, but internalize, understand why they work, and when to apply which one. Use them to solve the problem of your code been read in 6 month by a serial killer that know your address. Second... 960 pages. If you really want to advance the craft, if you really want to b…

Was about to come here to say this. This stuff was all written down decades ago.

Re: Simple Ways of Reducing the Cognitive Load in Code

#55

Post by coredog64 » Tue, Jun 28, 2016, 1:43 PM UTC

criddell wrote: post #20

tigershark wrote: post #9

Earlier quoted context omitted.

I completely disagree, every method can be split in private methods. In that way you don't need awful and unhelpful comments in the middle because you can understand what it does simply from the method name.

> you can understand what it does simply from the method name That can be tough sometimes. How do you handle the case where you've created a function just to package some block of code that would otherwise be repeated 40 times? You end up with function names like add_to_list_when_cromulent() or even worse rebuild_stats_helper() Or you have the situation where every time you do action A, it usually needs to be followe…

I see this all the time in our PRs:

   UtilHelper.processItems(List items) : List

Re: Simple Ways of Reducing the Cognitive Load in Code

#56

Post by andy_ppp » Tue, Jun 28, 2016, 1:44 PM UTC

Or rather more simply - do code reviews and decide on which of these things you want to include and teach everyone about:

a) the agreed way

b) other code they haven't worked on

in the process. Finally if you know someone else will be reviewing your code you'll produce better code in the first place.

Re: Simple Ways of Reducing the Cognitive Load in Code

#57

Post by phaed » Tue, Jun 28, 2016, 1:49 PM UTC

TickleSteve wrote: post #8

...and another: Use of whitespace (vertical and horizontal) to group and associate code with related parts. Its a trick borrowed from graphic design, but negative-space works really nicely.

Sounds like you need to split your methods/files into smaller single-purpose chunks.

Re: Simple Ways of Reducing the Cognitive Load in Code

#58

Post by honkhonkpants » Tue, Jun 28, 2016, 1:50 PM UTC

jboy wrote: post #14

This article is a good start, but I found it much too light on detail. Each section ended just when I was ready for it to dive into details! For example, in the final section "Make it easy to digest": > Using prefixes in names is a great way to add meaning to them. It’s a practice that used to be popular, and I think misuse is the reason it hasn’t kept up. Prefix systems like hungarian notation were initially meant t…

is_emtpy and make_empty are just going to irritate every C++ programmer in the business, since all the STL containers use empty and clear.

Re: Simple Ways of Reducing the Cognitive Load in Code

#59

Post by Jtsummers » Tue, Jun 28, 2016, 1:50 PM UTC

rimantas wrote: post #29

edejong wrote: post #24

Earlier quoted context omitted.

I'd go even further and say that newcomers to teams are often the most able to pinpoint essential flaws in the development process.

Except often the things pinpointed are not flaws just different from that they are used to.

Then those differences can or ought to be documented. Having fresh eyes on something is good for discovering unwritten processes, rules, etc. If you're doing X because Y, but you never wrote down Y. A new person enters and sees X but doesn't see it's utility (is it better, faster, gives you more robust systems), they may attempt to remove that from the process or tool chain. They may be right, they may be wrong. Because they don't know Y and perhaps no one else in the office does either, at this point.

Document the tools you use, why you use them (even if it's just: we were familiar with T1 so we chose it over T2, that's not a bad reason unless T1 has some major flaws or limitations). Document the processes and provide rationales as best you can.

This is my viewpoint, at least, as someone who's done a lot of work on the maintenance end of software development. I don't know why in 1984 something was done. I find a particularly gnarly bit of code or process and I want to fix it. Turns out they had a good reason (most of the time), but it's outdated because X. Or it's still relevant, but non-obvious until you get to a certain level of familiarity that only happens for the original developer or a maintainer on the project for 20 years.

Re: Simple Ways of Reducing the Cognitive Load in Code

#60

Post by lr4444lr » Tue, Jun 28, 2016, 1:50 PM UTC

webscalist wrote: post #48

iamleppert wrote: post #5

"Use names to convey purpose. Don't take advantage of language features to look cool." I can't say enough about this. Please write code that is easy to read and understand, not the most compact code, and not the most "decorated" code, or "pretty" code or neat because it uses that giant list expression or ridiculous map statement thats an entire paragraph long. Similarly what bugs me is when I receive a pull request w…

Unreadable to you could mean readable to others. Sometimes you have to learn different paradigms and ways to express computer program.

Also, there's an unstated reality here that the person who sets the standards is a senior person (in the company, in his career, in the industry) and may just be letting personal judgment and past success - good in its time, but not necessarily timeless - override his judgment about a legitimately new and better way of doing something. This is tech after all: progress is valuable, and objectivity is hard.