How to reduce the cognitive load of your code • Hacker News Board

Re: How to reduce the cognitive load of your code

#161

Post by hibikir » Tue, Mar 29, 2016, 6:27 PM UTC

msluyter wrote: post #75

norswap wrote: post #59

Like often with this kind of article it barely scratches the surface. "null != variable" will confuse people is downright silly. People confused by this won't have an inkling of what any non-hello-world program does. The rest has some validity, but it focuses on syntax and programming in the very small. It might take a bit of effort, but I can make sense of a tangled function (that's not an excuse to code sloppily th…

Re: "null != variable": I don't think it's necessarily confusing, it's just that usually we tend to think of the elements we're working with (variables, objects, functions, etc...) as taking on values, and so linguistically, we ask "is my thing null?" Not, "is nullness something that applies to my thing?" Hence "thing operation value" is arguably cognitively cheaper than "value operation thing." So you could argue th…

The example you show is just a bad workaround though: Your real problem there is that you have code that deals with input that can be null, but whose job is not just to get rid of the nullability. Keeping around fields that could be null and looking for ways to do it safely is like forcing everyone to wear radiations suits because you refuse to have laws about where you can keep nuclear materials.

This is why in modern Java, or in Scala, we have Option types (and in old school java, Nullable annotations), which makes trickery like that unnecessary.

Re: How to reduce the cognitive load of your code

#162

Post by Retric » Tue, Mar 29, 2016, 6:41 PM UTC

ergothus wrote: post #152

hbt wrote: post #27

There are so many similarities between writing code and writing English. - Thinking of paragraphs as functions with one purpose - keeping sentences short to reduce load on working memory and increase comprehension - create visual breaks to help the reader by grouping common stuff together as mini-functions - reduce intimidation factor of reading by removing convoluted stuff - remove cognitive noise (dead code, unnece…

I agree with everything you said. As an old Perl guy, I found it hilarious that Perl has a reputation for illegibility, while I find it easier to read than most Java, because in Perl I can express my intent, and in Java it's buried in the noise. One cognitive problem I've not yet found a good solution to: So I have a high level routine to, say, sort the items in a display. Said sorting has some cascading effects, so…

One approach that can help is to name things based on what the functions actually do.

  validateSortDisplayedItems
  {
   validation Logic
   ...
   sortDisplayedItems(); //Actually sorts items.
  }

This can be harder to maintain, but really long names end up a useful code smell.

Re: How to reduce the cognitive load of your code

#163

Post by jimjimjim » Tue, Mar 29, 2016, 6:46 PM UTC

one programming style that i think makes things worse is the "how many calls can i make on a single line" programming style.

  MyObjecter.GetObjectRelatativeThingy(ThingyHolder.WhatsMything(IndexKeeper.Get(), OtherWhatsIt.BuildOther( MoonCheese.Intensify(true)))

It's probably a result of the letterbox effect of widescreen monitors and IDEs with horizontal toolbars and status bars.

Is there anything wrong with expanding the idea of 'one purpose per function' into 'one purpose per line' and split it all up into multiple lines with temp vars inbetween.

this gives you benefits of:

- short lines and simple ideas

- easier to set break points

- allows for adding logging between calls.

- allows for setting debug watches on the temp vars

- the compiler tidies any temp vars away so there shouldn't be any extra copying.

Re: How to reduce the cognitive load of your code

#164

Post by sklogic » Tue, Mar 29, 2016, 6:47 PM UTC

The best way to minimise the cognitive load is to always use DSLs.

Re: How to reduce the cognitive load of your code

#165

Post by ergothus » Tue, Mar 29, 2016, 6:48 PM UTC

Retric wrote: post #162

ergothus wrote: post #152

Earlier quoted context omitted.

I agree with everything you said. As an old Perl guy, I found it hilarious that Perl has a reputation for illegibility, while I find it easier to read than most Java, because in Perl I can express my intent, and in Java it's buried in the noise. One cognitive problem I've not yet found a good solution to: So I have a high level routine to, say, sort the items in a display. Said sorting has some cascading effects, so…

One approach that can help is to name things based on what the functions actually do. validateSortDisplayedItems { validation Logic ... sortDisplayedItems(); //Actually sorts items. } This can be harder to maintain, but really long names end up a useful code smell.

I find it a bit...incorrect.

I mean, your above code LIES. If I call validateSortDisplayedItems, I don't validate, I validate AND sort. Plus, what do you do if you have "validateItems" and "sortItems", and then one function that calls them each in turn? call it "validateAndSortItems"? Yuck.

Re: How to reduce the cognitive load of your code

#166

Post by yekim » Tue, Mar 29, 2016, 7:00 PM UTC

ergothus wrote: post #152

hbt wrote: post #27

There are so many similarities between writing code and writing English. - Thinking of paragraphs as functions with one purpose - keeping sentences short to reduce load on working memory and increase comprehension - create visual breaks to help the reader by grouping common stuff together as mini-functions - reduce intimidation factor of reading by removing convoluted stuff - remove cognitive noise (dead code, unnece…

I agree with everything you said. As an old Perl guy, I found it hilarious that Perl has a reputation for illegibility, while I find it easier to read than most Java, because in Perl I can express my intent, and in Java it's buried in the noise. One cognitive problem I've not yet found a good solution to: So I have a high level routine to, say, sort the items in a display. Said sorting has some cascading effects, so…

Wrt Perl being readable / legible; I think most find Perl hard to read because there are 3-4 different ways to do the same thing. And many of the more "advanced" ways of doing things rely on short, terse single characters that act essentially like magic and behave differently in different situations. At least this is what I remember as I climbed the Perl ladder.

Contrast this with say, Python, where readability is highly valued and they have a one-way-to-do-certain things mentality, like sorts for example, means code is generally easier to grok, debug, and extend.

Thus, readability becomes especially important when you have to deal with someone else's big ball o' mud and you need to fix a high stress, high visibility, lines down issue at one in the morning because the original programmer is long gone, didn't leave any comments in their code, and decided to play "look at me, I'm so clever with how I use this operator", but forgot to account for a certain scenario that manufacturing decided to roll out the other day without telling anyone. Can I get an amen?

Re: How to reduce the cognitive load of your code

#167

Post by [deleted] » Tue, Mar 29, 2016, 7:00 PM UTC

norswap wrote: post #59

Like often with this kind of article it barely scratches the surface. "null != variable" will confuse people is downright silly. People confused by this won't have an inkling of what any non-hello-world program does. The rest has some validity, but it focuses on syntax and programming in the very small. It might take a bit of effort, but I can make sense of a tangled function (that's not an excuse to code sloppily th…

[deleted]

Re: How to reduce the cognitive load of your code

#168

Post by mreiland » Tue, Mar 29, 2016, 7:02 PM UTC

mmebane wrote: post #40

gahahaha wrote: post #22

Earlier quoted context omitted.

Because productive developers write more code or because productive developers write worse code?

Perhaps being a "productive" programmer requires understanding the requirements well enough to quickly write working code, then moving on to the next problem. Personally, I usually find that it takes two refactorings/rewrites to go from initial working code to something that I honestly believe is understandable/maintainable, and I don't always have time to do that.

It's more subtle than that. People act as if developers are all a clean slate, which isn't true.

developers have personalities with differing values. That super productive developer may just not value the flexibility of the code due to his personality coupled with that developers personal experience.

That developer will absolutely shine in some environments and be abysmal in others since there are absolutely environments where flexibility isn't an overriding concern.

As you get more experience you learn to be more explicit about your decisions, but you'll still have your preferences and your defaults and it takes a certain threshold for you to move away from said preferences and defaults.

Re: How to reduce the cognitive load of your code

#169

Post by rileymat2 » Tue, Mar 29, 2016, 7:06 PM UTC

kilink wrote: post #154

njharman wrote: post #63

Earlier quoted context omitted.

yeah, I'm not even sure what's suppose to be confusing? That the "constant" comes first, before the comparison operator?

For me it's not that it's confusing, it's annoying to read because it indicates that the programmer didn't actually take the time to learn the language, and is instead writing it as C/PHP something else where expressions in if statements don't need to be explicitly boolean (the examples in the article are Java). If they wrote that, what else do they not understand about the language?

What if it is 0 but not null? I write in a few different languages throughout a typical week. It is nice to have some explicit statements when juggling between them. I know them very well, but it is still tricky when going back and forth.

Re: How to reduce the cognitive load of your code

#170

Post by mreiland » Tue, Mar 29, 2016, 7:20 PM UTC

the_af wrote: post #137

lostcolony wrote: post #130

Earlier quoted context omitted.

I think you're reading too much into 'confusing'. It won't leave someone without understanding; it -may- cause them to momentarily pause, going "WTF?...uh...probably does ~this~. But why would someone do things this way?" That's still delaying them, that's still distracting them, that's still putting up an obstacle. Not one a future maintainer can't overcome, but -why do it-? That's the point.

It seems like a reading micro-optimization to me, though. Surely most of the delays in understanding code lie in things other than "Yoda" conditionals. I'm going to guess complexity elsewhere in the code (even conceptual difficulties, such as "what is the purpose of this at all?") dwarf minor details like how one writes conditionals. If so, what is the point of this piece of advice?

> It seems like a reading micro-optimization to me, though.

It's a "reading micro-optimization" in the same way that not littering your code with comments is a "reading micro-optimization".

It makes you pause and interrupts your flow of thought as you contemplate something not directly related to what you were modeling in your head 2 seconds ago.