Avoid Indirection in Code • Hacker News Board

Re: Avoid Indirection in Code

#21

Post by james_s_tayler » Mon, Jun 24, 2019, 4:50 AM UTC

justasitsounds wrote: post #17

james_s_tayler wrote: post #12

TL;DR - don't pointlessly wrap functions from the standard library in methods with non-standard names. Yes. Please. Stop. Doing. That.

In this case the desired functionality can be encompassed in a single standard library method. However, the author of the code may have started with a much more complex implementation but still feels like `is_foolike()` is better at describing the _intention_ of the method than the eventual implementation. Replacing the descriptive method name with the actual implementation may mean the author now feels that they hav…

You know how many times I've seen that exact scenario in code bases? Plenty. Some developers just do really pointless shit and then name is terribly to add insult to injury.

Re: Avoid Indirection in Code

#22

Post by enedil » Mon, Jun 24, 2019, 4:52 AM UTC

sudhirj wrote: post #13

The argument in the post is a bit of a strawman - for really simple examples like that indirection makes no sense. Saying "is_something_like" as an alias for "starts_with" is an unnecessary alias that does nothing for the readability or duplication of the code. Indirection really isn't necessary in this case, even if you use "starts_with" in a thousand places. It might make sense if you're trying to do a comparator,…

In Python it's json.load(file), so no indirection needed whatsoever.

Re: Avoid Indirection in Code

#23

Post by kenhwang » Mon, Jun 24, 2019, 4:52 AM UTC

tsumnia wrote: post #11

keyle wrote: post #2

That's a pet peeve of mine; I see it all the time when I work with lesser experienced developers, only I didn't know how to call it. I call it onion skin development, where the developer keeps hiding stuff in more layers of the onion, making my eyes water as I have to dig deeper and deeper to essentially find `a.foo(b)` under 12 layers of abstraction. They're so focussed on making everything look so purrty, they forg…

While I can agree with the sentiment, when is indirection okay vs. when does it become spaghetti code? Given [1], there needs to be a happy medium between 12 layers and all in a single method. I think with less experienced developers, the issue is diving too deep because they think they need to prove they aren't novices. However, its still a learning period for them where they just need a good mentor to tell them the…

My rule of thumb is 3 times. Whatever is abstracted away must be used at least 3 times. It's amazing how much preemptive prettification by abstraction it prevents.

Re: Avoid Indirection in Code

#25

Post by wawhal » Mon, Jun 24, 2019, 4:59 AM UTC

I slightly disagree because I prefer the code to be consistent all across my codebase.

Sure it is some effort to backtrack to the util functions, but I think the effort is worth it because I would rather have a developer spend multiple hours debugging and figuring out the code than having something that is a nightmare to iterate upon.

Re: Avoid Indirection in Code

#26

Post by sesteel » Mon, Jun 24, 2019, 4:59 AM UTC

a_t48 wrote: post #16

I really disagree with just the toy example. If it's just in one place, fine, but when you need to change the example to also do something else like check the end of the string `return x.startswith("foo") && !x.endswith("bar");` this style will end up biting you. Yeah, your IDE has tools that can help, but you might not catch all examples, especially in other branches.

Yes! I understand that it feels inconvenient to read, but what is REALLY inconvenient is hunting down all occurrences of a magic string comparison that is poorly defined.

Re: Avoid Indirection in Code

#27

Post by sbov » Mon, Jun 24, 2019, 5:00 AM UTC

didericis wrote: post #20

sudhirj wrote: post #13

The argument in the post is a bit of a strawman - for really simple examples like that indirection makes no sense. Saying "is_something_like" as an alias for "starts_with" is an unnecessary alias that does nothing for the readability or duplication of the code. Indirection really isn't necessary in this case, even if you use "starts_with" in a thousand places. It might make sense if you're trying to do a comparator,…

I’d hesitate to call the good abstractions you describe indirection. The term is most appropriate when describing opaque abstractions that force you into their inner workings in order to understand their purpose. In the original example, what exactly it means to be “foo like” is not obvious. You need to bounce into the other file/method in order to understand it’s purpose. In good abstractions, like the ones you desc…

It doesn't matter how good your abstraction is, if someone needs to know the details it is at that point indirection. And there will always be some cases where someone needs to know the details. The better your abstraction, the less often. But someone, sometime, will still need to look at them.

Re: Avoid Indirection in Code

#28

Post by keyle » Mon, Jun 24, 2019, 5:02 AM UTC

KayEss wrote: post #9

keyle wrote: post #2

That's a pet peeve of mine; I see it all the time when I work with lesser experienced developers, only I didn't know how to call it. I call it onion skin development, where the developer keeps hiding stuff in more layers of the onion, making my eyes water as I have to dig deeper and deeper to essentially find `a.foo(b)` under 12 layers of abstraction. They're so focussed on making everything look so purrty, they forg…

> they forgot that it's about telling the computer to do something, as clearly as possible Or alternatively, it's to explain to the next reader of the code, as clearly as possible, how the problem was solved (in such a way that it can also be executed by the computer).

Yes I meant "as clearly as possible" .

Re: Avoid Indirection in Code

#29

Post by keyle » Mon, Jun 24, 2019, 5:03 AM UTC

tsumnia wrote: post #11

keyle wrote: post #2

That's a pet peeve of mine; I see it all the time when I work with lesser experienced developers, only I didn't know how to call it. I call it onion skin development, where the developer keeps hiding stuff in more layers of the onion, making my eyes water as I have to dig deeper and deeper to essentially find `a.foo(b)` under 12 layers of abstraction. They're so focussed on making everything look so purrty, they forg…

While I can agree with the sentiment, when is indirection okay vs. when does it become spaghetti code? Given [1], there needs to be a happy medium between 12 layers and all in a single method. I think with less experienced developers, the issue is diving too deep because they think they need to prove they aren't novices. However, its still a learning period for them where they just need a good mentor to tell them the…

Agreed, I don't preach writing code like a caveman either!

Re: Avoid Indirection in Code

#30

Post by fenomas » Mon, Jun 24, 2019, 5:05 AM UTC

sudhirj wrote: post #13

The argument in the post is a bit of a strawman - for really simple examples like that indirection makes no sense. Saying "is_something_like" as an alias for "starts_with" is an unnecessary alias that does nothing for the readability or duplication of the code. Indirection really isn't necessary in this case, even if you use "starts_with" in a thousand places. It might make sense if you're trying to do a comparator,…

I think the idea here is that "foolike" is some kind of meaningful characteristic that happens to be testable by looking at a string prefix - not that the author is just making a helper to test string prefixes.

E.g.:

    function isActiveCustomer(status) {
        return status.startsWith("active")
    }

is, I presume, the sort of thing the author means to suggest.