6 ms·

A bigger question is whether anyone would pay attention if it turns out some method has a notable improvement. I remember reading a bunch of code quality studi

A bigger question is whether anyone would pay attention if it turns out some method has a notable improvement. I remember reading a bunch of code quality studies a few years back. A bunch of them were DoD studies from the 1980/1990's, and the one thing that stuck out were a couple of studies that looked at style issues with ada/c and noted that the matched brace style significantly lowered a couple different defect types. Yet today, particularly in the opensource world matched brace style is almost completely non-existant, since its a religious war thing, and some of the early opensource projects were run by people who didn't like it.

bigbubba 6y ago
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.
klenwell 6y ago
On that question, I've quoted this here on HN before. From Donald G Reinertsen's Principles of Product Development Flow: I used to think that sensible and compelling new ideas would be adopted quickly. Today, I believe this view is hopelessly naive. After all, it took 40 years before we recognized the power of the Toyota Production System. I read this book on the strength of some recommendation here on Hacker News. It is quite relevant to this general topic: https://www.goodreads.com/book/show/6278270-the-principles-of-product-development-flow https://www.goodreads.com/book/show/6278270-the-principles-o...
- mattmanser 6y ago
  I know 40 years seems long, but that's just one generation. Looking at it from another perspective, that's incredibly quick for a useful idea to spread through the whole human race. And some of that time is basically pre-internet, or at least widely accessible internet.
- kqr 6y ago
  Thank you for that book recommendation. Over the last year or two, I have independently started to piece together many of the things Reinertsen has collected in that book. Except, of course, Reinertsen has done a much more thorough job and the book points out some glaring holes in my understanding of the topic. I suspect this will be one I'll devour over the next few days. Brilliant stuff. Thanks again.
joshlemer 6y ago
By "matched brace style" do you mean: while(true) { println("hi") }

bigbubba 6y ago

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.

klenwell 6y ago

On that question, I've quoted this here on HN before. From Donald G Reinertsen's Principles of Product Development Flow: I used to think that sensible and compelling new ideas would be adopted quickly. Today, I believe this view is hopelessly naive. After all, it took 40 years before we recognized the power of the Toyota Production System. I read this book on the strength of some recommendation here on Hacker News. It is quite relevant to this general topic: https://www.goodreads.com/book/show/6278270-the-principles-of-product-development-flow https://www.goodreads.com/book/show/6278270-the-principles-o...

mattmanser 6y ago
I know 40 years seems long, but that's just one generation. Looking at it from another perspective, that's incredibly quick for a useful idea to spread through the whole human race. And some of that time is basically pre-internet, or at least widely accessible internet.
kqr 6y ago
Thank you for that book recommendation. Over the last year or two, I have independently started to piece together many of the things Reinertsen has collected in that book. Except, of course, Reinertsen has done a much more thorough job and the book points out some glaring holes in my understanding of the topic. I suspect this will be one I'll devour over the next few days. Brilliant stuff. Thanks again.

joshlemer 6y ago

By "matched brace style" do you mean: while(true) { println("hi") }