3 ms·

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 la

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 they can pull back a little. Outright avoiding indirection (I don't believe) does that. [1] http://www.cs.kent.edu/~jmaletic/Prog-Comp/Papers/fix-1993.pdf http://www.cs.kent.edu/~jmaletic/Prog-Comp/Papers/fix-1993.p...

kenhwang 7y ago
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.
- Double_a_92 7y ago
  Abstraction is not mainly about avoiding repetition though. It's about (well...) creating abstraction. Imagine if you have to check permission to do something, and that check is really complex and long code. If would be better to have code like: if (hasPermissionToEdit(myUser)){ ... Than a ton of ANDs and ORs in that if, that nobody would quickly recognize as a permission check... even if it's just there once. As a minimum I'd put that in a properly named variable first, if I really wanted to avoid an extra function.
- psychoslave 7y ago
  Keeping a function at a given cyclomatic complexity generally also give a good indication whether a function should be refactored. That's not completely the point of the article, but both issue are interesting metric for deciding the level of factorization. Also one need more accurate specification when defining a call deepness alarm. Most direct call to any random API will probably already explode a limit of 3, which doesn't necessarily say that the framework is brokenly atomized.
keyle 7y ago
Agreed, I don't preach writing code like a caveman either!
ElonMuskrat 7y ago
During review and debugging I need to understand what the code is actually doing. I would prefer not to chase through a linked-list of function to uncloak something as trivial as string comparison. There seems to be this insidious notion that engineers never need to understand implementation details, and therefore should aspire to bury program semantics through layers of abstraction that [often poorly] express the author's intent. This is a recipe to write systems that are insecure, and operationally un-maintainable.

kenhwang 7y ago

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.

Double_a_92 7y ago
Abstraction is not mainly about avoiding repetition though. It's about (well...) creating abstraction. Imagine if you have to check permission to do something, and that check is really complex and long code. If would be better to have code like: if (hasPermissionToEdit(myUser)){ ... Than a ton of ANDs and ORs in that if, that nobody would quickly recognize as a permission check... even if it's just there once. As a minimum I'd put that in a properly named variable first, if I really wanted to avoid an extra function.
psychoslave 7y ago
Keeping a function at a given cyclomatic complexity generally also give a good indication whether a function should be refactored. That's not completely the point of the article, but both issue are interesting metric for deciding the level of factorization. Also one need more accurate specification when defining a call deepness alarm. Most direct call to any random API will probably already explode a limit of 3, which doesn't necessarily say that the framework is brokenly atomized.

keyle 7y ago

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

ElonMuskrat 7y ago

During review and debugging I need to understand what the code is actually doing. I would prefer not to chase through a linked-list of function to uncloak something as trivial as string comparison. There seems to be this insidious notion that engineers never need to understand implementation details, and therefore should aspire to bury program semantics through layers of abstraction that [often poorly] express the author's intent. This is a recipe to write systems that are insecure, and operationally un-maintainable.