3 ms·

> of an awful function with multiple screenfuls of code If you've got that, you will have deeper and more abundant problems to solve than will be helped by eas

> of an awful function with multiple screenfuls of code If you've got that, you will have deeper and more abundant problems to solve than will be helped by easily matching up braces.

deckard1 6y ago
heh. That reminds me of JavaScript recently. We have optional chaining now, which quite a few developers absolutely love. Diving deep into data structures is such a code smell, and yet so many people just want to spray the equivalent of Febreze over it. "Maybe with the right syntax for doing this ugly thing people won't notice how ugly this thing I'm doing actually is!"
bigbubba 6y ago
Expecting syntax to solve all your problems probably isn't very realistic. But at least as far as facilitating editor movement goes, matching braces work really well.
- throwaway_pdp09 6y ago
  'All?' I never said 'all'. Why assume something I didn't say. I have worked with codebases that have long functions and they bury bugs because long funcs tend to = copy/pasted code.
  - bigbubba 6y ago
    Your objection doesn't make much sense to me. I made it clear that obscene long functions are not something you want to have. That doesn't detract from the value of braces, since braces become an aid when remedying such a situation. They don't solve it, but they help you solve it. So your objection seems to be that they don't solve the sort of problem that you wouldn't expect syntactical forms to solve.
fiddlerwoaroof 6y ago
So, what about the claims in Code Complete that codebases with larger functions and methods tended to have lower defect rates? I’m not sure that the prevalent bias in favor of lots of small functions is born out empirically.
- throwaway_pdp09 6y ago
  I'm unaware of this, I don't have the book, do you have any other references? This genuinely interests me. TIA
  - discreteevent 6y ago
    There is a similar concept in "A Philosophy of Software Design" by John Ousterhout. Large/deep modules with simple interfaces lead to less complexity than small modules with complex interfaces. It's a bit radical because it conflicts with the obsession we have for low level re-use and composability.

> of an awful function with multiple screenfuls of code If you've got that, you will have deeper and more abundant problems to solve than will be helped by easily matching up braces.

deckard1 6y ago

heh. That reminds me of JavaScript recently. We have optional chaining now, which quite a few developers absolutely love. Diving deep into data structures is such a code smell, and yet so many people just want to spray the equivalent of Febreze over it. "Maybe with the right syntax for doing this ugly thing people won't notice how ugly this thing I'm doing actually is!"

bigbubba 6y ago

Expecting syntax to solve all your problems probably isn't very realistic. But at least as far as facilitating editor movement goes, matching braces work really well.

throwaway_pdp09 6y ago
'All?' I never said 'all'. Why assume something I didn't say. I have worked with codebases that have long functions and they bury bugs because long funcs tend to = copy/pasted code.
- bigbubba 6y ago
  Your objection doesn't make much sense to me. I made it clear that obscene long functions are not something you want to have. That doesn't detract from the value of braces, since braces become an aid when remedying such a situation. They don't solve it, but they help you solve it. So your objection seems to be that they don't solve the sort of problem that you wouldn't expect syntactical forms to solve.

fiddlerwoaroof 6y ago

So, what about the claims in Code Complete that codebases with larger functions and methods tended to have lower defect rates? I’m not sure that the prevalent bias in favor of lots of small functions is born out empirically.

throwaway_pdp09 6y ago
I'm unaware of this, I don't have the book, do you have any other references? This genuinely interests me. TIA
- discreteevent 6y ago
  There is a similar concept in "A Philosophy of Software Design" by John Ousterhout. Large/deep modules with simple interfaces lead to less complexity than small modules with complex interfaces. It's a bit radical because it conflicts with the obsession we have for low level re-use and composability.