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

171–180 of 187 posts

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

#171

Post by colefichter »

TeMPOraL wrote: post #145
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 comprehens…

> programming is a profession

We like to think that, but it's not really true. Professions tend to include some kind of guild, union, or association to represent the interests of practitioners and require/evaluate formal ongoing education (reading blogs doesn't count). There are typically barriers to entry. There's usually a licensing process as well as a disciplinary process that may revoke one's right to practice.

Programming has none of those things.

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

#172

Post by coldtea »

andrewprock wrote: post #170
jmcomets wrote: post #46

Earlier quoted context omitted.

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

"filter" has to be the worst library name. I have no clue what it's doing unless I read the documentation. On the other hand "append" feels like a much more conventional and comprehensible name.

>"filter" has to be the worst library name. I have no clue what it's doing unless I read the documentation

It, I dunno, FILTERS a collection keeping only certain elements (those that match the filter)? What else would it possibly do? Besides a standard CS term, it's also a concept from real life...

To me the name is crystal clear.

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

#173

Post by jxy »

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

I always like comparing coding with writing. Depending on your proficiency, you might want to write a pulp fiction, a news article, a PhD thesis, or Shakespeare. You might write in English, American English, Chinese, classical Chinese, Japanese, or Farsi.

Maintainability or the cognitive load of the reader or writer completely depends on the proficiency of the reader or writer.

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

#174

Post by sirmoveon »

The day the cognitive load is at an ideal point is the day you will lose your relevance to society, because it will be easily automated. I know that day will come; but I'm in no hurry given the current state of affairs with capitalism and a global oligarchy trying to enslave the rest of the specie.

Meanwhile, I'll be happy writing obscure and complicated code that I won't have to maintain. Giving the industry leverage for the near future.

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

#176

Post by andrewprock »

coldtea wrote: post #172
andrewprock wrote: post #170

Earlier quoted context omitted.

"filter" has to be the worst library name. I have no clue what it's doing unless I read the documentation. On the other hand "append" feels like a much more conventional and comprehensible name.

> "filter" has to be the worst library name. I have no clue what it's doing unless I read the documentation It, I dunno, FILTERS a collection keeping only certain elements (those that match the filter)? What else would it possibly do? Besides a standard CS term, it's also a concept from real life... To me the name is crystal clear.

A filter creates two sets, one with the thing, and the other without. When you filter something, you might be interested in what is filtered in, or what is filtered out.

Ponder for a second the phrases, "filtered water", "coffee filter", "camera filter", etc. In all of those cases, you are interested in the set without the filtered thing, not with.

Compare this to "select" which is a much clearer name.

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

#177

Post by crpatino »

userbinator wrote: post #155
crpatino wrote: post #119

Earlier quoted context omitted.

> If you can train yourself to put the constant first, you can train yourself to use the right operator. Right... that's assuming you work solo. In that case, you might as well be using some higher level language and sidestep the whole issue. Most C programmers out there work in teams, in long lived projects... that means teams with rotation of personnel. This is a fuckup waiting to happen. I get you guys do not like…

The argument applies just as well to each member of a team.

The argument applies just as well to each member of society. Imagine the savings in law enforcement if every one of us just followed the rules all the time!!!

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

#178

Post by lacampbell »

pmarreck wrote: post #163
lacampbell wrote: post #108

Earlier quoted context omitted.

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

Well, there's somewhat of an argument to be made that immutable data structures are a bit less performant than mutable ones... but it still seems to be the way forward, especially when you take any sort of concurrency into account

The real distinction I am trying to make is that objects are a higher level, cleaner and more composable way of organising code - much more so than the "module and record" nonsense most FP people seem to push.

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

#179

Post by mywittyname »

> Actual code from a makefile I wrote. Junior devs can’t handle overuse of new tech.

Most devs can't handle overuse of new tech. It seems like the junior qualifier was put into place in order to get away with this bit of hypocrisy.

The introduction of new tools will absolutely lead to increased cognitive load until the entire team is familiar with it.

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

#180

Post by taurath »

btschaegg wrote: post #141
hvidgaard wrote: post #120

Earlier quoted context omitted.

"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 w…

Big difference between intentional and unintentional technical debt. If you as the programmer are taking on intentional technical debt but the people making resource decisions don't know about it, it is in fact unintentional technical debt.
Post reply on HN