Writing good code: how to reduce the cognitive load of your code • Hacker News Board

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

#101

Post by dragonwriter » Wed, Mar 08, 2017, 5:24 AM UTC

JustSomeNobody wrote: post #91

mrlyc wrote: post #47

When I write code, I keep the target audience in mind. That target audience is a maintenance programmer doing their first programming job.

What's a maintenance programmer? Sounds pretty derogatory.

A "maintenance programmer" is a programmer whose job is maintaining a system (bug fixes and adaptation to relatively minor environmental changes) that is viewed as complete and basically static, either without major new development expected or with major new development done by separate teams in as-needed projects. Often, maintenance programmers are employed by the organization owning the system, while new development is done by contracted teams.

It is a particularly common role in government and other enterprise shops, particularly those that still use a pre-Agile, civil-engineering-metaphor approach to software development.

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

#102

Post by pmarreck » Wed, Mar 08, 2017, 5:32 AM UTC

The largest improvement you can make to reduce the cognitive load of your code is to move to a functional language with immutable data and optionally static typing. Empirical data about bug tendencies by language http://macbeth.cs.ucdavis.edu/lang_study.pdf is IMHO indirect evidence of cognitive load issues.

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

#103

Post by Terr_ » Wed, Mar 08, 2017, 5:35 AM UTC

rb808 wrote: post #66

Swizec wrote: post #29

Earlier quoted context omitted.

I love chaining, but one verb per line. Instead of something like Me.getFish.skin.debone.flour.salt.fry.eat It would be something like Me.getFish .skin .debone .flour .salt .fry .eat I find this more readable than doing it without chaining like this: fish = Me.getFish fish.skin fish.debone fish.flour fish.salt fish.fry Me.eat(fish)

personally I prefer without chaining, makes much more sense as its what I've always seen until the last ~5 years. The other part you didn't mention is that you have to amend all the functions like getFish, skin etc to return the object which I think makes their signature unnecessarily less clear.

Yeah, just because something looks like chaining doesn't mean it's really repeated calls on the same object. Even with some static-checking of types, it could also be a copy of the object.

While blocky, the repeated thing.do() format is explicit about what object is being operated on.

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

#104

Post by mattkrause » Wed, Mar 08, 2017, 5:45 AM UTC

onion2k wrote: post #97

psyc wrote: post #89

Earlier quoted context omitted.

This 'reason' is as old as C, and it's always seemed to me like tying bells to your shoelaces because it would be bad if you forgot to tie them and tripped. I.e. the 'solution' is orthogonal to the problem. If you can train yourself to put the constant first, you can train yourself to use the right operator. And you can test your code.

If you can train yourself to put the constant first, you can train yourself to use the right operator. Ideally, of course. But pragmatically mistakes happen. The point is that there's no cost - so why not use an explicit order and the right operator? And you can test your code. A lot of developers don't, or they only test for simple success cases that wouldn't catch this class of bug. It's scary.

You also have a tireless automated assistant who can check for this: the compiler.

Clang warns about this by default:

  warning: using the result of an assignment as a condition  without parentheses. 
  note: place parentheses around the assignment to silence this warning. 
  note: use '==' to turn this assignment into an equality comparison. "

gcc gives you similar warnings with -Wall or -Wparentheses:

  warning: suggest parentheses around assignment used as truth value [-Wparentheses]

Why not stick with the more natural phrasing and let the machine handle the tedious work?

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

#105

Post by brobinson » Wed, Mar 08, 2017, 5:52 AM UTC

jmcomets wrote: post #46

pugworthy wrote: post #22

Earlier quoted context omitted.

You'll also find that some experienced programmers specifically turn 1 line into 5. It's the beginner that tries to create the 1 liner because they think it's genius.

One-liners are bad if they are obscure and experienced programmers know that. However I wouldn't go as far as say that experienced programmers don't use one-liners at all. As usual in programming, it's all about balancing clarity/conciseness. For example, I find this much clearer as a one-liner (Python): validated_items = filter(is_validated, items) rather than validated_items = [] for item in items: if is_validated(…

Ruby version is a pretty clear one-liner:

    validated_items = items.select { |item| is_validated?(item) }

Though I'd expect a check for validation to be an instance method, so it'd probably look like:

    validated_items = items.select(&:validated?)

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

#106

Post by myFathersFace » Wed, Mar 08, 2017, 5:54 AM UTC

ser0 wrote: post #18

Sometimes I find myself writing in reviews for less experienced developers the comment: this is clever but not clear. I think as developers we get too enthralled in the problem solving and forget that in the long run we are more like journalists noting business rules at a snap-shot in time, which a future maintainer of our software must act as historian/archaeologist in order to understand. What's funny is that often…

I appreciate that you are one that can recognize the beauty of originalism. There is something to be said for first principles, and something that we can all learn by doing what we can to abide by the idea that every piece of knowledge that is taught is done so not only by design but with our best interests at heart.

Needless to say, I want to share a little piece of code I wrote that uses first principles in terms of data structures, and is perhaps my magnum opus. It's not sophisticated, but it does work, and it works because I refined it again, and again, and again. And I think that is the gist of this article. Refinement reduces cognitive load more than any other technique (in my perhaps not so humble opinion..haha).

If you'd like to look at my code, please go to github.com and search for justSomeGuyWhoLearnedToCode. The Trust repository has the code that I wrote as a trust fund for some very good friends of mine, but as I cannot seem to get in touch with them, I am sharing it with the world.

It requires some compiling, but man when that thing cooks, it cooks with gas, mi amicis.

I'm working on a sequel using NLP that I am going to add to the repo on Monday, so keep your eyes and ears open for that too.

And if you fret about how well you write code, just remember, the mere fact that you are writing code speaks to your tenacity as a problems solver and your participation in the process is well being commendable if and when you step back from your "self" and look at all of the progress you have made. Don't write functional code, or perfectly simplisitic code, or code that sparkles when you're done, instead write code that reads like poetry. Write your life into it. Write your heart into it. Write your soul into that logic, because that code is forever. It is your statement to the world that you are an artist, and your art is the marriage of logic and beauty, of solutions to probelsm so large we harness the power that binds the atoms together, and have machines building machines building machines to lithograph the transistors that can fit (like so many angels) a thousand on the head a pin.

Bless serendipity, and bless the dudes at Bell labs, Alan Turing, Charles Babbage, Rosy the fucking Riveter, and everyone else who made the computer possible. We are on the cusp of a new age, and quantum computers will revolutionize (a word I almost never use) the way we make medicine, and the way to outer space then become much, much easier and the world that we live in will become much happier as we share our progress with the less fortunate. Get ready, folks, because the whole shmear is waiting just around the next bend.

And for you "older" fogies, check out the Win 10 default wallpaper, and think of the line: "You are in a room, and you see a window".

Peace is God

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

#107

Post by Ace17 » Wed, Mar 08, 2017, 5:56 AM UTC

haswell wrote: post #16

sdegutis wrote: post #9

Earlier quoted context omitted.

The article says: // This was useful in C to avoid accidentally // typing variable = null. These days it will // confuse most people, with little benefit. The use of "was" and "these days" in the link shows that the author of this piece is in a tiny little bubble of development, and is far from being able to give general advice for programming. C is not past-tense. C, C++, Objective-C, these are all still widely used…

He follows this up with: > Don’t code “your way”. Just follow the coding standards. This stuff is already figured out. Make your code predictable and easy to read by coding the way people expect. I'm not a C dev, but is "(null != thing)" still a convention? (Based on your comment it sounds like yes). If yes, it seems to me like he's saying: keep doing that! Nowhere does he claim that his advice about this convention…

> I'm not a C dev, but is "(null != thing)" still a convention? (Based on your comment it sounds like yes)

I'd rather call it a trend than a convention.

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

#108

Post by lacampbell » Wed, Mar 08, 2017, 5:58 AM UTC

pmarreck wrote: post #102

The largest improvement you can make to reduce the cognitive load of your code is to move to a functional language with immutable data and optionally static typing. Empirical data about bug tendencies by language http://macbeth.cs.ucdavis.edu/lang_study.pdf is IMHO indirect evidence of cognitive load issues.

I'm a big fan of immutable objects. Best of both worlds in my opinion.

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

#109

Post by Ace17 » Wed, Mar 08, 2017, 6:08 AM UTC

flohofwoe wrote: post #12

kccqzy wrote: post #2

I 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…

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.

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

#110

Post by [deleted] » Wed, Mar 08, 2017, 6:09 AM UTC

Jach wrote: post #45

At the risk of making too much over the section (and ranting risks in general :)) I get the sense that "Keep your personal quirks out of it" strays dangerously close to "don't learn anything new, don't encourage the team to do it either". Of course I agree with not being clever for the sake of clverness, and not going against the overall style of the team with your preferred style. But the article goes on: "The probl…

[deleted]