What makes code hard to read: Visual patterns of complexity (2023)

Post by kazinator » Wed, Mar 12, 2025, 7:17 PM UTC

davidw wrote: post #168

skydhash wrote: post #152

Earlier quoted context omitted.

Lisp code is an AST. Once that's internalized, the parenthesis fade in the background. Mentally, instead of editing code, you're just arranging the branches. So, when reading, you can usually ignore whole sections as they will evaluate to a single value (side effects are possible, but strongly discouraged)

Having 4 spaces as indentation helps people tease out where the branches even are in languages like C or Python or whatever, rather than the 1 or 2 that you see with a lot of Lisp. And those angled parents make lining things up vertically a teeny bit more difficult.

  if (proprietary(program))
    roll_on_floor_twitching(stallman);
  else
    {
      calm_down(stallman);
      make_indent_weirdly(stallman, everyone);
    }

Post by maleldil » Wed, Mar 12, 2025, 7:32 PM UTC

aquariusDue wrote: post #327

brabel wrote: post #308

Earlier quoted context omitted.

Are you really confused when people don't think 3 operations constitutes "long"? I would guess anyone with half a brain would agree 3 operations is not long, maybe 5 or 6 and you will have many people agreeing, and above that most.

Here's an abomination of my own design in Rust for example: for (index, node) in nodes .expect("Error: No blocks for the Body") .children() .expect("Error: blocks node has no children") .nodes() .iter() .enumerate() { let block = Block::new(node, index); self.blocks.push(block); }

Post by maleldil » Wed, Mar 12, 2025, 7:38 PM UTC

jacobr1 wrote: post #78

zwnow wrote: post #42

Earlier quoted context omitted.

But who talked about bad architecture? Good readable code doesn't rule out good architecture. Surely some things are complicated but even then, a dev should be able to quickly see whats going on with minimal expertise in a codebase.

The broader problem is "cognitive load to understand the code I'm looking at." There are a variety of factors that lead enabling that. This is a very limited example. function isReadyToDoThing(Foo foo) { return foo.ready } function processStuff((Foo foo) { if isReadyToDoThing(foo) { res = workflowA(foo) res2 = workflowB(foo) return res && res2 } } This might be dumb, if isReadyToDoThing is trivial, and it could be ea…

Post by daotoad » Wed, Mar 12, 2025, 8:03 PM UTC

p2edwards wrote: post #347

seeinglogic wrote: post #181

Earlier quoted context omitted.

This comment seems unnecessarily mean-spirited... perhaps I just feel that way because I'm the person on the other end of it! I agree the code you have there is very readable, but it's not really an example of what that sentence you quoted is referencing... However I didn't spell out exactly what I meant, so please allow me to clarify. For me, roughly 5 calls in a chain is where things begin to become harder to read,…

Agreed — seeinglogic's article made me think of a 3rd option: 1. Sorta long functional chain where the type changes partway through 2. Use temp variables 3. (New option) Use comments (Here's funcA from seeinglogic's article, but I added 3 comments) function funcC(graph) { return // target node graph.nodes(`node[name = ${name}]`) // neighbor nodes .connected() .nodes() // visible names .not('.hidden') .data('name'); }…

Post by disgruntledphd2 » Wed, Mar 12, 2025, 8:16 PM UTC

climb_stealth wrote: post #238

feoren wrote: post #219

Earlier quoted context omitted.

The dig on chains of map/reduce/filter was listed as a "Halstead Complexity Takeaway", and seemed to come out of the blue, unjustified by any of the points made about Halstead complexity. In fact in your later funcA vs. funcB example, funcB would seem to have higher Halstead complexity due to its additional variables (depending on whether they count as additional "operands" or not). In general, long chains of functio…

Just want to add that I both agree with you and parent. Your examples are readable and I see no issues there. It might be a language thing as well. In Python often people take list-comprehensions too far and it becomes an undecipherable mess of nested iterators, casts and lists. There are always exceptions :)