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

Post by dijksterhuis » Wed, Mar 12, 2025, 10:16 AM UTC

jodrellblank wrote: post #84

dijksterhuis wrote: post #7

Earlier quoted context omitted.

> [than] having a function which calls out to lots of other functions and I'm jumping around the code base, back and forward. i agree with longer functions and less jumping around, but there's also some nuance i find. I sometimes find converting a complicated multi-line condition into something like the below is much easier for me to read, so long as the function is named in a clear way and the function definition is…

> can also do it the grug-brained way This way reads like: x = 1 // set variable x equal to 1 in that gt_zero echoes what the > operator does and says nothing about intent. Comparing, e.g. gt_zero = space > 0 // there is some space I guess? space_for_logfile = space > 0 // oh, logfiles need space > 20 there's the mistake.

Post by DonHopkins » Wed, Mar 12, 2025, 10:38 AM UTC

desumeku wrote: post #228

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…

o_node := graph.GetNodeByName(name) var ret []string for _, node := range o_node.connectedNodes() { if !node.isHidden { ret = append(ret, node.name) } } return ret

Post by [deleted] » Wed, Mar 12, 2025, 10:56 AM UTC

desumeku wrote: post #291

stouset wrote: post #282

Earlier quoted context omitted.

> the only difference is whether or not it's hidden behind function calls you can't see and don't have access to. You "can't see and don't have access to" `if`, `range`, or `append` but somehow you don't find this a problem at all. I wonder why not? > You don't really think that functional languages aren't appending things, using temp vars, and using conditional logic behind the scenes, do you? By this metric all lan…

> it could build up a set internally, it could use a hashmap, or any one of a million other approaches. It can even probe the size of the array to pick the performance-optimal approach. I don't have to care. Well, this is probably why functional programming doesn't see a lot of real use in production environments. Usually, you actually do have to care. Talk about noticing a performance regression because I was simply…

Post by aquariusDue » Wed, Mar 12, 2025, 11:27 AM UTC

brabel wrote: post #308

aaronbrethorst wrote: post #183

Earlier quoted context omitted.

What is "long"?

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.

   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 lioeters » Wed, Mar 12, 2025, 11:32 AM UTC

erikerikson wrote: post #301

bogomog wrote: post #133

Earlier quoted context omitted.

function getOddness(n: number): return (n % 2 === 0) ? "Even" : "Odd"; Lowest boilerplate makes it the most readable. If working in a language with the ternary operator it ought to be easily recognized!

Since the article was in JavaScript: const getOddness = (n) => ( n % 2 ? 'Odd' : 'Even' ) Even less visual noise

    const getOddness = n => n % 2 ? 'Odd' : 'Even'