5 ms·

> One long, yet simple function has less cognitive overhead than spreading the function across multiple classes or functions or call hierarchies Not if you are

> One long, yet simple function has less cognitive overhead than spreading the function across multiple classes or functions or call hierarchies Not if you are encapsulating and naming effectively... Why read 100 lines when you can read 20 and find concerns in one routine you are concerned with? Function calls can be expensive. However, optimization can come whenever you need it, and if what you need is one call vs 5, it is trivial to move that code back into a single routine.

thorncorona 3y ago
I like long simple functions because it makes them easy to reason about when debugging. Rarely does having more functions solve “does this do what I expect.”
- bobmaxup 3y ago
  Maybe it boils down to how well you are able to navigate a code base. With a full-featured language specific IDE, it is very easy to navigate through even complicated spaghetti. It makes debugging call traces simple, with a GUI. However, many other file viewers and editors make this much more complicated, and it can be frustrating to follow code that is making heavy use of modularization. If you are grepping your way through a deeply modular code base it can quickly become difficult to keep track of anything.
  - phkahler 3y ago
    >> With a full-featured language specific IDE, it is very easy to navigate through even complicated spaghetti. If you need a fancy IDE to navigate around code in order to understand it, that might be crappy or poorly organized code. Not a dig at nice IDEs, just code that requires one to navigate and understand.
    - chongli 3y ago
      Yeah. This is one of those hammer cases. If you’ve got a fancy IDE then the temptation is to use it. Similar to the issue of game programmers being given top of the line gaming PCs with frequent upgrades. They then struggle to understand why the game they just released runs like crap on most people’s modest computers.
    - bobmaxup 3y ago
      Not many people can understand a very large code base without taking notes, using an IDE, or similar tooling. > Not a dig at nice IDEs, just code that requires one to navigate and understand A nice IDE helps you reason about code, no matter what the underlying architecture is. That is why there is a market for them.
oivey 3y ago
> Not if you are encapsulating and naming effectively... No, and this is one of the reasons inheritance has lost popularity. Splitting some functionality across many files adds significantly to the cognitive load of figuring out what code is actually even running. After you trace that information out, you need to keep it all straight in your head while debugging whatever you’re working on. That’s even more problematic when you’re debugging, which implies you already don’t really understand what the program is doing. And that’s in the case where things are named well. When they’re inevitably accidentally named in confusing or incorrect ways that can contribute to the bug itself and cause the code to be even more confusing. Extreme levels of encapsulation has its own issues when, actually, the original author is wrong and you really do need some public access to some member. No one writing code is clairvoyant, so excessive encapsulation is common.
- rileymat2 3y ago
  > Splitting some functionality across many files adds significantly to the cognitive load of figuring out what code is actually even running. This is the crux, if your goal is to figure out what code is running, if you can keep the program in your head, if you have small simple programs splitting things up is harmful. But there is this murky line, different for everyone, and even different for the same person from day to day, where even with the best intent, no matter how good you are, you can't keep the program in your head. At that point, you need to give up the idea that you can. Then you change perspective and see things in chunks, split up, divide and conquer, treat portions as black boxes. Trust the documentation's, pre and post conditions. Debugging becomes verifying those inputs and returns; only diving into the code of that next level when those expectations are violated.
  - Xeamek 3y ago
    But at some point you HAVE to be able to look at the program from above. If you abandon the hope of understanding the code in the bigger scope, how can you ever meaningfully modify it? (Ie add a big feature and not just tweak some small parameters)
    - 3y ago
chongli 3y ago
Not if you are encapsulating and naming effectively... Encapsulation is hard and a lot of what people call encapsulation isn’t. For example, taking a global variable and moving it to a class is not encapsulation. You have to actually do the hard work of removing the dependency on global shared state. Just changing everything to mutate the new global through an accessor to a “god” object that gets passed everywhere is accomplishing nothing at all. Worse than nothing, you’re complexifying without fixing the root problem: global mutable state.
- whstl 3y ago
  It's funny how Singletons became such a meme pattern, and how about 80% of people in interviews only know about it when asked about patterns. A cleverly-named way of disguising global mutable state does not make it better.
whstl 3y ago
> "Not if you are encapsulating and naming effectively..." When you only have to superficially skim the code, that works. If there are incorrect abstractions, such as logging, transaction logic or manual error handling mixed with "well named function calls", then it is already very problematic even to skim. If you have to debug, it quickly becomes torture. Especially if state is involved and shared between multiple methods or classes. If you have to reimplement the code: you're probably fucked.

thorncorona 3y ago

I like long simple functions because it makes them easy to reason about when debugging. Rarely does having more functions solve “does this do what I expect.”

bobmaxup 3y ago
Maybe it boils down to how well you are able to navigate a code base. With a full-featured language specific IDE, it is very easy to navigate through even complicated spaghetti. It makes debugging call traces simple, with a GUI. However, many other file viewers and editors make this much more complicated, and it can be frustrating to follow code that is making heavy use of modularization. If you are grepping your way through a deeply modular code base it can quickly become difficult to keep track of anything.
- phkahler 3y ago
  >> With a full-featured language specific IDE, it is very easy to navigate through even complicated spaghetti. If you need a fancy IDE to navigate around code in order to understand it, that might be crappy or poorly organized code. Not a dig at nice IDEs, just code that requires one to navigate and understand.
  - chongli 3y ago
    Yeah. This is one of those hammer cases. If you’ve got a fancy IDE then the temptation is to use it. Similar to the issue of game programmers being given top of the line gaming PCs with frequent upgrades. They then struggle to understand why the game they just released runs like crap on most people’s modest computers.
  - bobmaxup 3y ago
    Not many people can understand a very large code base without taking notes, using an IDE, or similar tooling. > Not a dig at nice IDEs, just code that requires one to navigate and understand A nice IDE helps you reason about code, no matter what the underlying architecture is. That is why there is a market for them.

oivey 3y ago

> Not if you are encapsulating and naming effectively... No, and this is one of the reasons inheritance has lost popularity. Splitting some functionality across many files adds significantly to the cognitive load of figuring out what code is actually even running. After you trace that information out, you need to keep it all straight in your head while debugging whatever you’re working on. That’s even more problematic when you’re debugging, which implies you already don’t really understand what the program is doing. And that’s in the case where things are named well. When they’re inevitably accidentally named in confusing or incorrect ways that can contribute to the bug itself and cause the code to be even more confusing. Extreme levels of encapsulation has its own issues when, actually, the original author is wrong and you really do need some public access to some member. No one writing code is clairvoyant, so excessive encapsulation is common.

rileymat2 3y ago
> Splitting some functionality across many files adds significantly to the cognitive load of figuring out what code is actually even running. This is the crux, if your goal is to figure out what code is running, if you can keep the program in your head, if you have small simple programs splitting things up is harmful. But there is this murky line, different for everyone, and even different for the same person from day to day, where even with the best intent, no matter how good you are, you can't keep the program in your head. At that point, you need to give up the idea that you can. Then you change perspective and see things in chunks, split up, divide and conquer, treat portions as black boxes. Trust the documentation's, pre and post conditions. Debugging becomes verifying those inputs and returns; only diving into the code of that next level when those expectations are violated.
- Xeamek 3y ago
  But at some point you HAVE to be able to look at the program from above. If you abandon the hope of understanding the code in the bigger scope, how can you ever meaningfully modify it? (Ie add a big feature and not just tweak some small parameters)
  - 3y ago

chongli 3y ago

Not if you are encapsulating and naming effectively... Encapsulation is hard and a lot of what people call encapsulation isn’t. For example, taking a global variable and moving it to a class is not encapsulation. You have to actually do the hard work of removing the dependency on global shared state. Just changing everything to mutate the new global through an accessor to a “god” object that gets passed everywhere is accomplishing nothing at all. Worse than nothing, you’re complexifying without fixing the root problem: global mutable state.

whstl 3y ago
It's funny how Singletons became such a meme pattern, and how about 80% of people in interviews only know about it when asked about patterns. A cleverly-named way of disguising global mutable state does not make it better.

whstl 3y ago

> "Not if you are encapsulating and naming effectively..." When you only have to superficially skim the code, that works. If there are incorrect abstractions, such as logging, transaction logic or manual error handling mixed with "well named function calls", then it is already very problematic even to skim. If you have to debug, it quickly becomes torture. Especially if state is involved and shared between multiple methods or classes. If you have to reimplement the code: you're probably fucked.