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

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

chrismm.com

Post reply on HN
Print view View original

141–150 of 187 posts

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

#141

Post by btschaegg »

hvidgaard wrote: post #120
mikekchar wrote: post #79

Earlier quoted context omitted.

We've been refactoring and decoupling code for decades in imperative coding styles. I think one of the problems we have as a community of programmers is the concept that it must end up in a ball of mud. Almost all of our extant systems are developed in imperative style. The system I work on today is many orders of magnitude larger than the systems I first learned on and yet it is dramatically easier to write useful c…

"If you don't have time to get it right the first time, how on earth will you have time to do it again?" I like that quote, but to be honeste. Some times you have to get it out of the door, and time is of the essence. And you can go back and fix it. That is okay, as long as you understand that shortcutting now, will cost time tomorrow (i.e. technical debt).

Yeah, the problem appears if your superiors don't understand that. It'll be a "quick fix", when you want to clean it up after the crunch the comments will be "nah, we don't have time for that right now" (non-coders never seem to understand that messy code is a liability - thus cleaning up code seems like a waste of time).

And a couple of months later, it comes back biting you in the behinds. At which point, someone will tell you or some other unfortunate colleague to "just fix it quickly".

In such an environment "quick and dirty" only works if it is kept locally, i.e. the author is the only one that uses the code. Hence Uncle Bob's insistence that a good developer must say "NO!" from time to time[1].

[1]: https://sites.google.com/site/unclebobconsultingllc/blogs-by...

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

#142

Post by fauigerzigerk »

mybrid wrote: post #122
agentultra wrote: post #34

Whenever I read articles like this and the ensuing discussion that follows, I'm reminded of this quote from Dijkstra: Don't blame me for the fact that competent programming, as I view it as an intellectual possibility, will be too difficult for "the average programmer" — you must not fall into the trap of rejecting a surgical technique because it is beyond the capabilities of the barber in his shop around the corner.…

Functional programming is inscrutable by most. Berkeley uses LISP as a flunk out class to weed out freshman. I find it odd that given in the physical world people require different shoe sizes for different feet that in the intellectual world people believe one size fits all, or that there is ultimately a single style of code that is comprehensible. Do you really believe our brains are all the same? The functional pro…

>Do you really believe our brains are all the same?

One thing that all brains have in common is that they can learn. One thing that all feet have in common is that they can not learn. That's why your analogy doesn't work here.

>Functional programming is inscrutable by most.

As is musical notation, maths, foreign languages, CAD drawings and everything else that has to be learned before use.

I am not a huge proponent of FP as I'm not entirely convinced that the benefits of immutability always justify the restrictions imposed on algorithm and data structure design, both in terms of simplicity and performance.

But one thing I am convinced of is that whatever newbies may find inscrutable is entirely irrelevant unless you plan to cut costs by having interns write all your code for free before replacing them.

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

#143

Post by TeMPOraL »

pugworthy wrote: post #22
gravity13 wrote: post #19

Earlier quoted context omitted.

Everything is unclear until you become used to it, though. I mean, used to it, as in, you can read it without stepping yourself through the steps manually. And to a novice programmer, pretty much everything they come up against represents this. Turning five lines into one line with a reduce function sounds like a normal thing to do for experienced programmers, but to a beginner, they'll think you're a genius for poin…

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.

Experienced programmers will strive to write the code in a way that best communicates its intent and scope of effect. Sometimes that involves turning 5 lines into 1, sometimes the other way around.

Honestly, when I see people complaining that the code is "too clever", my default reaction is: programming is a profession, you're supposed to learn new stuff and get better, not complain that something is beyond what they taught you in Programming 101.

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

#144

Post by TeMPOraL »

TallGuyShort wrote: post #23
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…

One of the most valuable things I got from university was my professor's saying, "When somebody tells you your code is clever or interesting, that's an insult."

And in my experience, like most insults, this usually says more about the person saying it than about your code.

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

#145

Post by TeMPOraL »

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…

> These days I'm pretty pleased when I can say a piece of code utilises only syntax and statements taught in an introductory programming course.

This sounds like optimizing for read-time. This is subtly wrong, IMO. You should be optimizing for comprehension-time, i.e. how much time it takes for the next person to wrap their head around the (piece of) codebase. Often, you can have significant gains in code comprehensibility if you raise the minimum level of competence for the next person.

Or in other words: programming is a profession. You're not supposed to stay at the level of introductory programming course. You're supposed to be continuously learning and getting better. That applies to the next person too, so if your "clever" but clean abstraction is too hard for them, they're supposed to suck it up and open a book. They can afford the book, it's not like programmers are underpaid.

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

#146

Post by bryanrasmussen »

agentultra wrote: post #34

Whenever I read articles like this and the ensuing discussion that follows, I'm reminded of this quote from Dijkstra: Don't blame me for the fact that competent programming, as I view it as an intellectual possibility, will be too difficult for "the average programmer" — you must not fall into the trap of rejecting a surgical technique because it is beyond the capabilities of the barber in his shop around the corner.…

sometimes the surgeon is tired, and might like to have a problem phrased in a way that even the barber in the shop around the corner can understand.

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

#147

Post by aidos »

im3w1l wrote: post #99
graton wrote: post #69

Earlier quoted context omitted.

Or: validated_items = [x for x in items if is_validated(x)]

I prefer the other one, because then I don't have to consider whether there is an outer variable 'x' that is being clobbered.

In python 3, x is locally scoped to the comprehension :-)

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

#148

Post by douche »

thyrsus wrote: post #118
kennu wrote: post #73

Earlier quoted context omitted.

I would argue that by using CONSTANT == variable, you are reducing the cognitive load of the compiler, but increasing the cognitive load of the human reading the code (who has to mentally flip the expression around). I think the original article intended to say the same thing.

I don't get it. A test for (in)equality is commutative unless you're inducing side effects (i++) - and then side effects are going to be the big "cognitive load", regardless of which side of the comparison they occur. Am I dyslexic because (null != foo) is exactly as easy for me to read as (foo != null)?

It reads awkwardly for a lot of people, to the point that some call these constructs Yoda Conditionals.

I'm quite happy that all the languages I use regularly disallow assignment in ifs, at least.

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

#149

Post by ldp01 »

mybrid wrote: post #122
agentultra wrote: post #34

Whenever I read articles like this and the ensuing discussion that follows, I'm reminded of this quote from Dijkstra: Don't blame me for the fact that competent programming, as I view it as an intellectual possibility, will be too difficult for "the average programmer" — you must not fall into the trap of rejecting a surgical technique because it is beyond the capabilities of the barber in his shop around the corner.…

Functional programming is inscrutable by most. Berkeley uses LISP as a flunk out class to weed out freshman. I find it odd that given in the physical world people require different shoe sizes for different feet that in the intellectual world people believe one size fits all, or that there is ultimately a single style of code that is comprehensible. Do you really believe our brains are all the same? The functional pro…

I always thought different paradigms suited different problem domains rather than different people.

I'm not a software engineer by trade, but just for example, I've recently been mucking around making my own videogames and the object-oriented paradigm using the components pattern seems like a very natural way to conceptualise a videogame. E.g. Objects in the game (NPCs, environment) start as a basic object and are given specific behaviours by adding components.

Alternatively, I sometimes have to write R code for data analysis and in that case the style of using pipe operators to chain lots of functions together is perfect for readability and for reasoning about the code.

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

#150

Post by rimantas »

Singletoned wrote: post #114
brobinson wrote: post #105

Earlier quoted context omitted.

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?)

I don't find either of the Ruby versions clear at all. Both contain unnecessary syntax. Ruby seems to be going down the same path as Perl in trying to make all possible combinations of characters valid programs.

And if you are not programmer you can claim that == for comparison contains unnecessary syntax.
Post reply on HN