Hacker News Reader

Comment by praptak | Hacker News Reader

I kind of like to think code itself could use this analogy.

If a piece of code combines data from three systems, then maybe first fetch it from each one (maybe in parallel), then "wash" it (check preconditions, normalize, etc.)

Then you hopefully have data which is ready for doing the core work without the code being muddled with fetching missing stuff and cleaning it.

I can obviously find counterexamples when it is not so easy but I think I can also find functions which unnecessarily mix fetching stuff, checking it and the core logic.

View on HN

I tend to prefer the approach of

  fetch A
  wash A
  fetch B
  wash B

in terms of being easier to read. Of course sometimes there are performance benefits to firing off all the requests right at the start.

Anyway I definitely agree that not separating the core logic out from the data fetching/cleaning is a bad idea.

The issue is if you need A, B, and C to do a task and your function fails if it doesn’t retrieve it, won’t it waste time cleaning ingredients for a dish you can’t make? I don’t think it’s less readable than

carrot = fetch carrot

onion = fetch onion

celery = fetch celery

clean(carrot)

clean(onion)

clean(celery)

cook(carrot, onion, celery)

This is absolutely true. But if cleaning your data takes barely any compute and only fails less than 1% of the time, it’s splitting hairs.

The way I think about it is, how would I write it if performance didn’t matter? And then from that point I think about what compromises I can make that improve performance at the expense of something else (readability, etc)

Disclaimer: I’m not trying to argue that my preference is _better_.

Yeah that's fair! This is one of those times when coding is similar to writing and mostly personal aesthetics.

Reply on news.ycombinator.com