Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Simple Ways of Reducing the Cognitive Load in Code

chrismm.com

Post reply on HN
Print view View original

61–70 of 203 posts

Re: Simple Ways of Reducing the Cognitive Load in Code

#61

Post by joshmarlow »

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…

I'll second Sindisil's comment about nested functions.

I still often do the paragraph approach, but the thing about that is you rely on the comments to stay up to date to describe that paragraph.

I prefer to instead move that paragraph into a small nested function and name it to reflect what would be in that comment. I feel function names are easier to keep up to date than comments (ie, programmers don't just read past the function names like they do comments).

Re: Simple Ways of Reducing the Cognitive Load in Code

#62

Post by ViktorasM »

Stopped reading at "Place models, views and controllers in their own folders". No worse way to organize your code than classify by behavior type. "Here are all the daos", "here is all business logic", "here are all the controllers". You add a feature as small as resource CRUD and scatter it's pieces across the whole code base.

No.

Re: Simple Ways of Reducing the Cognitive Load in Code

#63

Post by mattmanser »

indubitably wrote: post #45

Keep your personal quirks out of it Don’t personalize your work in ways that would require explanations. I like taking advantage of variables to compartmentalize logic.

Not the same thing.

Randomly I'm working on some fairly awful code today that has the one redeeming feature that it divided and conquered as described in the article.

It made it fairly trivial to find the exact spot the problem was happening.

At no point reading the code did I think that assigning key values into variables along the way that were named to describe exactly what they represented and then all added up at the end was a personal quirk of the code.

That's a world of difference compared to using the fairly odd:

    if(null != thing)

Re: Simple Ways of Reducing the Cognitive Load in Code

#64

Post by msluyter »

delecti wrote: post #31
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…

I recently got a code review that in several places suggested I switch to the new Java 8 stream API [1]. I just flatly responded that it was far less readable, even if I could condense a half-dozen lines of code down to one. Where I can quickly scan over a foreach loop to get the jist of what it's doing, I have to closely examine each call in the new approach to have any idea what it's doing. [1] http://www.oracle.co…

I suppose to some extent this is a matter of taste, but I've usually found the streams api to be clearer and easier to understand, although perhaps there's a bit of a learning curve. I think the win is especially large in cases where you replace an anonymous inner class with a lambda, imho. At my previous job, we had all gotten quite familiar with Apache's CollectionUtils, but java8 almost obviates the need for that entirely.

Re: Simple Ways of Reducing the Cognitive Load in Code

#65

Post by emillon »

rakpol wrote: post #47
escherize wrote: post #3

I'd like to add one: let your tools do the work for you. It may seem like a pain to learn the tooling behind what you do, but once you internalize it, it becomes a superpower. An example is that I use Clojure Refactor Mode (with CIDER) for emacs. A trick (and treat) that a lot of Clojure code uses is the arrow macros: -> and ->>. Clojure Refactor Mode has thread-first, thread-first-all, thread-last, thread-last-all a…

That's like the function composition operator [1] in Haskell, right? Very neat :D I wonder if there's an equivalent macro in Scala ... [1]: http://lambda.jstolarek.com/2012/03/function-composition-and...

It's more like the pipe operator in ocaml (http://blog.shaynefletcher.org/2013/12/pipelining-with-opera...). The lisp version has the extra advantage that you don't have to repeat it between all the intermediate functions. ((->> 2 (* 100) str count) vs 2 |> (* 100) |> str |> count).

Re: Simple Ways of Reducing the Cognitive Load in Code

#66

Post by phamilton »

delecti wrote: post #31
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…

I recently got a code review that in several places suggested I switch to the new Java 8 stream API [1]. I just flatly responded that it was far less readable, even if I could condense a half-dozen lines of code down to one. Where I can quickly scan over a foreach loop to get the jist of what it's doing, I have to closely examine each call in the new approach to have any idea what it's doing. [1] http://www.oracle.co…

As a functional programmer (Haskell, Erlang) I can honestly say that after years of FP I think differently about how to describe the intent of my code. It's more difficult for me to understand a foreach loop with mutable state than a foldLeft.

Re: Simple Ways of Reducing the Cognitive Load in Code

#69

Post by TickleSteve »

phaed wrote: post #57
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.

no... nothing to do with that...

This is about visually grouping related things together, not decomposition of functions.

Re: Simple Ways of Reducing the Cognitive Load in Code

#70

Post by JohnL4 »

deepaksurti wrote: post #27
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.

And that applies irrespective of a newcomer is junior or senior. There is hardly a substitute for a fresh pair of eyes t to reveal what one thinks is cool design, code et al is not so cool after all.

We need to distinguish between "I don't understand this and I'm not going to bother to try before I start criticizing" and "Ok, I understand why you did this, but have you considered this alternate approach?" (and maybe "I don't understand this, and I think we need better docs here.", but that's already been covered).

(Some) new devs seem to classify themselves into "I'm just a clueless noob" and "I'm the new hotness".

Post reply on HN