Hacker News Reader

Comment by LandR | Hacker News Reader

> If a method is long to read from top to bottom, the answer isn't always splitting it into 5 smaller ones, sometimes life just has inherent complexity.

Yes! This.

I find it much easier to parse a long function where I can scroll down it and just read it top to bottom, then having a function which calls out to lots of other functions and I'm jumping around the code base, back and forward.

Just reading the long function top to bottom, where I can very easily just scroll up a bit is so much easier to keep in my head.

Even worse is when you go to definition on the method and you get 5 options, and you have to figure out which one would actually get called given the current path through.

View on HN

I think the issue is whether the functions that are split out are actually useful abstractions.

If they are, you should not have to jump around the code-base, you should be able to just read the invocation and know what it does, without leaving the source function.

As an example, you probably don't whip out your kernel source code when you encounter a call to write(). At least not usually. You just know what it does and can keep going.

You probably also don't look at the generated assembly code, and maybe look up the instruction reference for your favorite microprocessor when you encounter an arithmetic operator. You just assume that you know what it does, even if that may not be 100% correct in every case.

Those are good, useful abstractions.

That's what we need to strive for when we crate code.

> [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 just above the big function it gets called by (never in a different file!)

    def is_something_valid(something, foo, bar):
        return something > 0 and something != foo and something > bar

    if is_something_valid(something, foo, bar):

it's like a convenience reading shortcut so i don't have to parse the logic in my head if i don't want to. also makes the condition nice and easy to test.

then again, can also do it the grug-brained way

    gt_zero = something > 0 
    ne_foo something != foo
    gt_bar something > bar

    if gt_zero and ne_foo and gt_bar:

I think you are making a good point but if this function is only used in one place I would personally prefer to just use a variable:

    something_is_valid = something > 0 and something != foo and something > bar

    if something_is_valid:
        # do stuff

That way you can document the intention of the condition using the variable name while at the same time keeping the locality of the check.

I mostly agree, but for short one liners and where there will be no reuse elsewhere, instead of a function I prefer;

  something_is_valid = something > 0 and something != foo and something > bar
  if something_is_valid:
    # ....

It achieves the same thing without needing to scroll.

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

https://grugbrain.dev/#grug-on-expression-complexity

i skipped off the `space` in `space_gt_zero` because i was on my phone and couldn’t be bothered to type it out all the way each time.

don’t read too much into it. it was just laziness while brining up an existing concept.

100%. Worst is when the called function is in a separate file, and the most upsetting is when it's the _only_ function in the file. I really wish IDEs or tools like Sourcegraph could handle this better.

What are talking about?! That's my favourite part when reading code! :P

For longer functions vs bouncing between smaller functions my experience has been that this is one of those things where people are one way or the other. And they almost never change their preference. If your coworkers are all the same as you, that's great. If they're not, prepare for battle.

Reply on news.ycombinator.com