4 ms·

>>> keep your modules (functions, classes, components) deep: small interfaces packing significant functionality. The idea here is to give users of the module th

>>> keep your modules (functions, classes, components) deep: small interfaces packing significant functionality. The idea here is to give users of the module the biggest benefit for the least learning. Great! Now I have to travel through 100 small classes spread across 1000 files in a 10000 nodes directory tree in order to understand 1 high level class. Great readability improvement!

yen223 3y ago
Maybe we interpreted the article differently, but I understood this point as favouring a few "big" classes/interfaces/functions, as opposed to a lot of "small" classes.
- akasakahakada 3y ago
  Not at all. > if you have a class that solves a difficult problem with, say, only 2 methods with no more than 3 arguments each, you’re in good shape
  - Swizec 3y ago
    Yes. The only way to solve a difficult problem with just 2 methods that take 3 arguments each is if those two methods are huge. Keep your APIs small, but poweful. This is the opposite of short function people which keep their APIs huge, but weak.
nonexistiert0 3y ago
Something is seriously wrong with your names and abstractions if you can't tell what a high level class does... at a high level? Also if you can keep that much context in your head when reading code that's great for you -- most people can't.
jonahx 3y ago
Author is arguing for the opposite. You'll see down below a case for inlining functions that are only used once, and the quote "As for one liners that are called only once, just inline them. The small functions guy can take a hike."
memefrog 3y ago
Loup Valliant's main project is monocypher. It is typically distributed as one C file and one H file. It provides a relatively small interface by being well-scoped and well-designed. Nowhere does he say that you should have 100 small classes across 1000 files. He says the opposite: your modules should have a lot of functionality but a small interface.

yen223 3y ago

Maybe we interpreted the article differently, but I understood this point as favouring a few "big" classes/interfaces/functions, as opposed to a lot of "small" classes.

akasakahakada 3y ago
Not at all. > if you have a class that solves a difficult problem with, say, only 2 methods with no more than 3 arguments each, you’re in good shape
- Swizec 3y ago
  Yes. The only way to solve a difficult problem with just 2 methods that take 3 arguments each is if those two methods are huge. Keep your APIs small, but poweful. This is the opposite of short function people which keep their APIs huge, but weak.

nonexistiert0 3y ago

Something is seriously wrong with your names and abstractions if you can't tell what a high level class does... at a high level? Also if you can keep that much context in your head when reading code that's great for you -- most people can't.

jonahx 3y ago

Author is arguing for the opposite. You'll see down below a case for inlining functions that are only used once, and the quote "As for one liners that are called only once, just inline them. The small functions guy can take a hike."

memefrog 3y ago

Loup Valliant's main project is monocypher. It is typically distributed as one C file and one H file. It provides a relatively small interface by being well-scoped and well-designed. Nowhere does he say that you should have 100 small classes across 1000 files. He says the opposite: your modules should have a lot of functionality but a small interface.