Item — HN Reader

> The problem with a long function is not if it has N or N+1 lines of code, it's that length code with many branching conditions is prone to be untestable and introduce non trivial bugs. Once you start to refactor, not only is it easier to parse but harder to break. This fact is known for decades now.

A function with too many lines is, most likely, doing more than one thing. Functions should do one thing, be easy to test (with few or no external dependencies whenever possible), be deterministic (unless required not to be), and so on. Excessive mocking is another code smell I look for - it often betrays poorly designed functions that can't be easily tested.

1 comments

I once saw a professional software engineer try to refactor the spaghetti code in a complex bioinfomactics project written in python.

It was a complete failure. That branch was abandoned and development continued off the spaghetti.

There is a reason bioinformatics has its own set of viz charts that only they use.

That's my anecdote anyway, it led me to the conclusion that sometimes things are continuous spaghetti and other than some small organizational changes, attempts to exhaustively discretize the code are a fools errand.

The biggest benefits most projects like that are likely to see are performance and debugging improvements accomplished by factoring out recursion.

Mapping to terrain is always the real effort in my opinion.

> It was a complete failure. That branch was abandoned and development continued off the spaghetti.

It was considered too hard, most likely because the present state of the code already degenerated beyond recovery. It might be difficult, but it's never impossible.

> Mapping to terrain is always the real effort in my opinion.

Yes. The domain might be complex, and it might be possible that there are no simple ways to work within that domain. Irreducible complexity is, after all, a thing.