Ok, to take a real world example instead: if (url.startsWith('http://')) { vs. if (isAbsoluteUrl(url)) { If the next developer comes by in 2 months to fix the case for https:// urls (and protocol relative ones in 6 months), they'll immediately be able to spot the intention of the code and can easily fix it in the abstraction layer that's already in place. Moreover, the fix will be applied every other place this fault…
Your example works because it avoids duplication a magic string constant. If the string wasn't a constant, but another variable, thw whole argument changes.
Avoid Indirection in Code
131–140 of 220 posts
Re: Avoid Indirection in Code
#132For example, before the transformation:
function isFooLike(x) {
return x.startsWith("foo");
}
function isBarLike(x) {
return x.startsWith("bar");
}
function bigFunction(str) {
if(isFooLike(str)) {
console.log("Foo!");
}
else if(isBarLike(str)) {
console.log("Bar!");
}
else {
console.log("Unknown!");
}
}
And then: function bigFunction(str) {
if((function(x) {
return x.startsWith("foo")
})(str)) {
console.log("Foo!");
}
else if((function(x) {
return x.startsWith("bar")
})(str)) {
console.log("Bar!");
}
else {
console.log("Unknown!");
}
}Re: Avoid Indirection in Code
#133Re: Avoid Indirection in Code
#134Re: Avoid Indirection in Code
#135This made me think: is there an IDE or plugin that makes it easy to visualize the source code of a function by inlining the sources of the undercalled functions? For example, before the transformation: function isFooLike(x) { return x.startsWith("foo"); } function isBarLike(x) { return x.startsWith("bar"); } function bigFunction(str) { if(isFooLike(str)) { console.log("Foo!"); } else if(isBarLike(str)) { console.log(…
Re: Avoid Indirection in Code
#136There is a related problem that causes more trouble, but it cannot really be blamed on the initial abstraction. It goes like this: you have something, such as a foo-ness test, that is needed in several places, so you abstract it as a function for all the right reasons. Later on, one of those uses changes, and needs slightly different logic than the other cases. Instead of writing a new function (that may, as part of its implementation, call the original), the person making this change (not you, of course!) modifies the original function to handle both cases. This, by itself, makes the code more complex than necessary, and it gets worse if the criterion for which path is taken in the function is not something that has any significance for someone who arrived at this function through reading the code for one of the other cases that call it. And if the new path has a side effect, now all the other cases are also calling a function that potentially has side effects...
This is how code rots.
Re: Avoid Indirection in Code
#137One very important reason to avoid this kind of unnecessary indirection is that it wrecks locality of reference for anyone reading it. They end up spending all of their mental energy on skipping around the codebase trying to follow the thread of execution, making it very hard to assemble a coherent picture of what the code's actually trying to do.
Re: Avoid Indirection in Code
#138First of all, one of the biggest reasons to do this (and not mentioned) is unit testing. If there's several variations of input, it can simply testing because it's easier to write tests for smaller units of code (fewer or no mocks, and fewer parameters). This alone is probably enough to override any negative, in my opinion. Secondly, and in contrast to the point of the article, it can usually help readability. If you…
/* Checks if Foo */
is_foo(...)
obviously duplicates the same information.Re: Avoid Indirection in Code
#139This made me think: is there an IDE or plugin that makes it easy to visualize the source code of a function by inlining the sources of the undercalled functions? For example, before the transformation: function isFooLike(x) { return x.startsWith("foo"); } function isBarLike(x) { return x.startsWith("bar"); } function bigFunction(str) { if(isFooLike(str)) { console.log("Foo!"); } else if(isBarLike(str)) { console.log(…
While I find your inlined example very bad to read, I think there are many attemps IDEs do for this. I remember some showing the function stub of a called function when moving the mouse on the call instruction. I also know multiple editors that allow to quickly browse the source code with CTRL+Enter (or CTRL+Mouse click) in a similar fashion as we click on links in the web. I personally never found indirection to be…
Indeed, many IDEs allow you to easily display the source code of one function at a time, by navigating to the sources of the function or by displaying it in a pop-up, but the idea I had in mind is to be able to view the source code of the function with all its dependencies at a glance.
Re: Avoid Indirection in Code
#140I dont understand why there isn't a code editor that will inline functions for you?