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

Re: How to reduce the cognitive load of your code

#81

Post by mikekchar » Tue, Mar 29, 2016, 3:19 PM UTC

carussell wrote: post #60

seanmcdirmid wrote: post #26

Earlier quoted context omitted.

Typography is much more than that, of course, but with fixed width plain text, you don't have many options...so ascii art it is. I'm pondering a language that includes formatting abstractions so that you can prepare code for reading along with its functionality (sort of like literate programming, but still starting from code). I would love to see comments in a side bar, long monotonous calls organized into tables, pr…

> I would love to see comments in a side bar This is brilliant. A neat way to bootstrap getting this sort of thing implemented in most code editors would be to write a plugin that can do this for existing code and make it good enough to turn heads. It would extract documentation blocks to be presented as prose in a vertically split pane to the right and present the file itself with those blocks hidden—as if automatic…

There is a tool for literate coffeescript that formats the output in a similar way - you have the english text in a pane on the left and the code in a pane on the right. I quite like the effect -- especially since there are potentially no comments in the code at all, which I often want if I'm just trying to read it quickly.

Unfortunately, literate coffeescript is not really mature enough to be used in a large project, IMHO. However, I hope that more people think about separating human language commentary from computer code. I think the idea behind literate programming is a good one and I hope that it gains some traction some day.

Re: How to reduce the cognitive load of your code

#82

Post by hire_charts » Tue, Mar 29, 2016, 3:22 PM UTC

eterm wrote: post #47

igl wrote: post #21

No one ever mentions formatting. I really like aligning multiline blocks, adding whitespace and useless braces here an there. e.g: Having just a single space between function name and arguments makes it look less like a call. Yet almost all lint presets/defaults forbid this. Typography is all about the whitespace between letters forming easily recognizable shapes.

All this is solved by a linter though, there's no point even trying to remember this, just define your linter rules and let it deal with it. It might not be the default linter styles, but set up your linter for your project and give your mind more important things to focus on.

A linter is also a great way to jump start learning a new language. If you encounter a warning that doesn't make sense to you, look it up. You'll start to get familiar with common language pitfalls without actually getting burned by any of them.

Re: How to reduce the cognitive load of your code

#83

Post by zwieback » Tue, Mar 29, 2016, 3:25 PM UTC

Some good tips in this article but for me the problems usually start when I have to tie two or three APIs with different coding conventions together.

Re: How to reduce the cognitive load of your code

#84

Post by Freaky » Tue, Mar 29, 2016, 3:26 PM UTC

bnegreve wrote: post #49

hyperhopper wrote: post #34

Even the first example is a bit silly. Nobody is going to not understand that (null == foo) is the same as (foo == null).

It does increase the cognitive load for no particular reason. Which is what the author is trying to avoid.

It's the difference between, say, length(foo) and foo.length() - any difference in cognitive load should be lost in the noise next to "this variable can be null".

And given most languages in use today use = to mean assignment instead of equality, it's hardly "no reason".

Re: How to reduce the cognitive load of your code

#85

Post by hire_charts » Tue, Mar 29, 2016, 3:28 PM UTC

hyperhopper wrote: post #34

Even the first example is a bit silly. Nobody is going to not understand that (null == foo) is the same as (foo == null).

It's easy to call out trivial examples because they're trivial, but you're missing the forest for the trees. His point is that the cognitive load adds up. One (null == foo) probably won't slow you down noticeably, but the more of these tricks and workarounds are scattered throughout, the more time you'll need to spend reading and understanding the code.

Sometimes the workarounds are necessary for performance reasons, or they're just good practice to avoid common pitfalls. But in a lot of languages they aren't, so unless you have a good reason for increasing the overhead, it's better to lean towards readability.

Edit: Also, for this particular example, a good linter is all you need to warn you about an accidental assignment. If you don't have a linter, sure, then put null first, but it's important to recognize that this sacrifices a small amount of future scannability for the more immediate avoidance of a bug.

Re: How to reduce the cognitive load of your code

#86

Post by freekh » Tue, Mar 29, 2016, 3:30 PM UTC

Not sure I can say I always write clean code but when I do, in non-trivial cases, I often start to write a comment, delete it and replace the code I wrote with something that does not need a comment... I suppose it only works for people who (think they) know(s) what good code looks like, but (I think) it works as a good guiding principle (for me).

Re: How to reduce the cognitive load of your code

#87

Post by bpchaps » Tue, Mar 29, 2016, 3:30 PM UTC

jt2190 wrote: post #51

HerpDerpLerp wrote: post #31

Earlier quoted context omitted.

Yeh I don't like abbreviations in code so would have unsafeName = Request("name") etc etc which does not have that problem... unless 'unsafe' is a thing in your business domain then things could get complex :) The article goes on to advocate prefixing the methods that return safe and unsafe strings with 's' or 'us' I would hate that! I can easily see you ending up with string methods like safePadLeft and unsafePadLef…

I can easily see you ending up with string methods like safePadLeft and unsafePadLeft that do exactly the same thing but are named for where in the code they are used... I don't follow. Since the argument type to either method would be the same (a string), why are two methods necessary? Or are you inferring that we define subtypes of String: SafeString and UnsafeString? And wouldn't subtypes inherit behavior from the…

Last time I inherited a project that used prefixes like this extensively, it was the most frustrating and productivity draining coding time of my life. Sure, it could work, I guess. If there was actually any consistency to it. So many hours lost trying to find out why a prefix was defined in two different ways....

Advocating for prefixes like this is just going to result in badly obfuscated code where we get the exact opposite of, "JavaBeanFactoryConstructorXML_dom_to_json".

Re: How to reduce the cognitive load of your code

#88

Post by msluyter » Tue, Mar 29, 2016, 3:33 PM UTC

jimbokun wrote: post #72

"Avoid using language extensions and libraries that do not play well with your IDE. The impact they will have on your productivity will far outweigh the small benefit of easier configuration or saving a few keystrokes with more terse syntax." This is the main reason to avoid Spring. Having so much critical code in XML and properties configuration files, annotations, and magical interfaces that somehow sprout implemen…

Interesting. Are you familiar with IntelliJ? My experience has been that its Spring integration provides most of what you're asking for.

Re: How to reduce the cognitive load of your code

#89

Post by jpfed » Tue, Mar 29, 2016, 3:34 PM UTC

njharman wrote: post #63

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…

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

I am not sure, but here's my guess.

If I say (A != B), people may think of this as being equivalent to saying that there's a property we care about- being not equal to B- and we are checking whether A has that property.

If I say (Joe != null), then we are saying that there is a property "being not null" and we are checking whether Joe has that property. Feels pretty natural.

If I say (null != Joe), then we are saying that there is a property "being not Joe" and we are checking whether null has that property. This is pretty amusing way to think. In the lines after one says something like

    if (null == myArgument) throw new ArgumentNullException("myArgument")

one may proceed with assurance that some properties of null must hold :-)

The distinction between null and not-null is so generally useful that I could imagine making a partially-applied function like NotNull, and applying that to Joe (and many other objects). Would NotJoe get much use other than applying it to null? Probably not.

Re: How to reduce the cognitive load of your code

#90

Post by ap22213 » Tue, Mar 29, 2016, 3:37 PM UTC

naringas wrote: post #11

I used to think that a lot of bad code out there was made by lazy, incompetent programmers... But then, after a certain job, I realized that this is probably not the case. Now I belive that most bad code out thare is made by overworked and tired programmers in a rush to deliver something that works.

I've seen code readability decrease linearly since the 90s. This makes sense since there were around 3-4 developers to do the work of every 1 today.

But, I think this is just a symptom of a lack of capacity and resource management.

Contrary to popular belief, it was actually possible to do iterative and incremental 'agile' development prior to 1999. Most engineers back then used the term 'waterfall' to describe a well-known anti-pattern.