5 ms·

I love matching braces, if for no other reason than because they make transversing code easier. If you ever find yourself at the bottom of an awful function wi

I love matching braces, if for no other reason than because they make transversing code easier. If you ever find yourself at the bottom of an awful function with multiple screenfuls of code, matching braces makes it trivial to jump to the top if that function even when your editor has no special knowledge of that language. No LSP/etc needed. Barebones vanilla Vi is actually a viable editor for Lisp because of this, relative to Vi with languages like Python.

ywei3410 6y ago
This is one of the reasons that many Lisp developers like Lisp code - local structured editing is trivial because if the braces match, then most of the parser doesn't need to deal with the rest of the file.
throwaway_pdp09 6y ago
> 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.

ywei3410 6y ago

This is one of the reasons that many Lisp developers like Lisp code - local structured editing is trivial because if the braces match, then most of the parser doesn't need to deal with the rest of the file.

throwaway_pdp09 6y ago

> 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.