Avoid Indirection in Code
matthewrocklin.com
Avoid Indirection in Code
1–10 of 220 posts
Re: Avoid Indirection in Code
#2That'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 forgot that it's about telling the computer to do something, as clearly as possible.
Re: Avoid Indirection in Code
#3I don't think the author made a very good case for this. The case made on readability. But indirection is very common that if you can't read a piece of code without having to drill into the implementation of every function, lifes going to be quite painful. Depending on your language and editor / IDE, seeing implementation is often trivial. The only case, I see, for inlinig is where the pieces of code are very cohesive and tied together and will only be used as a single unit. Maybe that's what the author was trying to get at, don't break atomic units of code up.
Re: Avoid Indirection in Code
#4Reminds me of my first day of python performance analysis, which led to this fix.
https://web.archive.org/web/20130227000541/http://defect.ope... https://github.com/oracle/solaris-ips/commit/53bb14f750dd111...
Re: Avoid Indirection in Code
#5I don't think the author made a very good case for this. The case made on readability. But indirection is very common that if you can't read a piece of code without having to drill into the implementation of every function, lifes going to be quite painful. Depending on your language and editor / IDE, seeing implementation is often trivial. The only case, I see, for inlinig is where the pieces of code are very cohesiv…
I agree. The author actually makes a decent case for using this pattern though. I think it comes down to the skill and clarity of thought of the developer. If this pattern is used judiciously and the methods are named well then it adds very little cognitive overhead.
Also, it is very refreshing to read about and discuss actual development.
Re: Avoid Indirection in Code
#6Abstraction isn't the same as indirection. A facade layer isn't an abstraction. A double dispatch isn't an abstraction. An abstraction is a layer minus a detail that can be expressed in several different ways by components in that layer. The components act as translators that map their expression of the detail to the detail below them.
Abstraction has a very specific implementation, usually polymorphism and a very specific intent. It's not just a synonym for nested function calls or helper functions or one stop shop facade or whatever.
Re: Avoid Indirection in Code
#7I don't think the author made a very good case for this. The case made on readability. But indirection is very common that if you can't read a piece of code without having to drill into the implementation of every function, lifes going to be quite painful. Depending on your language and editor / IDE, seeing implementation is often trivial. The only case, I see, for inlinig is where the pieces of code are very cohesiv…
I agree. The author actually makes a decent case for using this pattern though. I think it comes down to the skill and clarity of thought of the developer. If this pattern is used judiciously and the methods are named well then it adds very little cognitive overhead. Also, it is very refreshing to read about and discuss actual development.
For sure, the pattern is good, having atomic units of code fragmented into pieces is not nice. This is essentially part of the Single Responsibility Principle, if things are together to suppport a single responsibility, don't fragment them. The trick is knowing "what IS the responsibility of this thing?" and not over doing it.
Re: Avoid Indirection in Code
#8That'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…
The onion is useful when thinking through a problem while writing code (add an abstraction layer as you try to eliminate pieces of complexity in layers), it usually doesn’t appear for aesthetic reasons. As understanding solidifies, the layers should probably be eliminated, and all that complexity should be smashed into one layer...or maybe not.
Re: Avoid Indirection in Code
#9That'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).
Re: Avoid Indirection in Code
#10This could easily be remedied by our editors offering a keystroke to inline the function definition in a smaller font and different colour so that we may read it, in order, as though it were one big file. Once the gist of the function has been understood, another keypress could take it away.
Visual Studio has this and it's called "Peek at function".