9 ms·

Some counterpoints: Your auto formatter can’t figure out where you missed braces either. Missing brackets in languages where they are optional for single stat

Some counterpoints: Your auto formatter can’t figure out where you missed braces either. Missing brackets in languages where they are optional for single statements (C) has been a source of serious bugs. Also, in Vim, indenting/dedenting a block is just highlighting the lines and using > or <.

GoblinSlayer 5y ago
A botched merge conflict resolution can repeat a block statement just fine, it will have the same effect. And repeating a statement inside a block isn't necessarily better.
bobbylarrybobby 5y ago
Practically speaking, it’s almost impossible to miss braces. If you’re copying and pasting, you can place your cursor anywhere inside the desired pair of braces, paste, and the autoformatter will figure it out. Ideally an autoformatter would also add braces around a one-line if statement as well.
- je42 5y ago
  it is very possible... I often paste parts of some code into a lambda and missing a brace here and there.
ImprobableTruth 5y ago
>Your auto formatter can’t figure out where you missed braces either. I mean, it kinda does? You get a result that's wrongly indented if you miss a brace.
- aEverr 5y ago
  well yeah, then what? where would the missing brace be? you can't really tell since now the formatter clobbered your indentation, unless you remember, of course
  - fanf2 5y ago
    When this happens to me with `cargo fmt` I don’t need to remember, I can just revert the formatting changes using undo in Emacs.
mumblemumble 5y ago
> Missing brackets in languages where they are optional for single statements (C) has been a source of serious bugs. This is why, in languages where they are optional, a good autoformatter will automatically insert them. If you've got it set to run every time you save the file or run tests, it's likely to do so long before you have a chance to produce the next Heartbleed. It's not perfect, of course, but it's as good a protection against this sort of thing as I've ever seen. > Also, in Vim, indenting/dedenting a block is just highlighting the lines and using > or <. But, excluding plugins (which aren't available/consistent across all the editors where I use a vim editing mode), I don't know of a quick vim command that lets me quickly select, delete, replace, yank, or change the full contents of a scope in a whitespace-sensitive language. Or quickly jump to the beginning or end of the current scope. Stuff like that. Versus, with curly brace languages, vanilla vim gives me an experience that approaches the ease of paredit.
- hadem 5y ago
  > I don't know of a quick vim command that lets me quickly select, delete, replace, yank, or change the full contents of a scope in a whitespace-sensitive language. I'm sure there are better ways, but you could v9G$ to select from the current line to the end of line nine. Or v9j select the next nine lines, v9k previous nine, etc.
  - mumblemumble 5y ago
    But compare the ergonomics of: 1. yi{ To: 1. Find line number of start of scope. 2. Decide on easiest way to get there, and either: - kk - 5k - 37G 3. Find the end of the scope. 4. Decide how to grab it. Then: - y9G$ - y3j - V, jjj, y I hope maybe I've made my case that it's more awkward, right? That is not to say that I don't know how to do it. It's just that, in the one case, I can do the job in one thoughtless action that lives so deeply in my muscle memory that I barely even consciously remember what the actual keystrokes involved are. By contrast, in the other, it takes several steps, some of which are likely to be small pauses to decide how to do the next step.
    - 5y ago
TheCoelacanth 5y ago
> Your auto formatter can’t figure out where you missed braces either. Correct, but I will notice the braces are wrong when the auto-formatter indents things differently than I expect.
- xigoi 5y ago
  And I'll notice the indentation is wrong when the indentation is different than I expect.
secondcoming 5y ago
How does significant whitespace save you from bugs? if expr: doA() doB() Is doB at the correct level? Having text that's invisible change the flow of your program is crazy IMO.
- feffe 5y ago
  I don't care that much in my own side projects but when working with others and resolving merge conflicts your example is my nightmare. It's so much easier to have brackets denote scope as you don't have to get the indentation right when actually resolving merge conflicts. It's easy to fix it up afterwards by automatic indentation in the editor. Significant white space is a mistake IMHO :-)
- akubera 5y ago
  The bugs being referred to are from optional brackets in C: void foo() { ... if (expr) doA(); doB(); ... } which is unambiguous to the compiler, but could (and I expect would, especially when glancing through a lot of code) cause misinterpretation by a human reader. We can more easily hallucinate the brackets than the indentation. I disagree with the idea that indentation spaces are invisible; rather they are much more visible than a pair of brackets. This actually becomes a problem when you embed/indent too much and 70% of the line is spaces. It's all you see!
  - secondcoming 5y ago
    Yes, but pretty much every coding standard I've seen mandates the use of braces always. You do it without even thinking. Your example wouldn't pass code review.
- xigoi 5y ago
  if (expr) { doA() doB() } Is doB at the correct level? It's the same thing.

GoblinSlayer 5y ago

A botched merge conflict resolution can repeat a block statement just fine, it will have the same effect. And repeating a statement inside a block isn't necessarily better.

bobbylarrybobby 5y ago

Practically speaking, it’s almost impossible to miss braces. If you’re copying and pasting, you can place your cursor anywhere inside the desired pair of braces, paste, and the autoformatter will figure it out. Ideally an autoformatter would also add braces around a one-line if statement as well.

je42 5y ago
it is very possible... I often paste parts of some code into a lambda and missing a brace here and there.

ImprobableTruth 5y ago

>Your auto formatter can’t figure out where you missed braces either. I mean, it kinda does? You get a result that's wrongly indented if you miss a brace.

aEverr 5y ago
well yeah, then what? where would the missing brace be? you can't really tell since now the formatter clobbered your indentation, unless you remember, of course
- fanf2 5y ago
  When this happens to me with `cargo fmt` I don’t need to remember, I can just revert the formatting changes using undo in Emacs.

mumblemumble 5y ago

> Missing brackets in languages where they are optional for single statements (C) has been a source of serious bugs. This is why, in languages where they are optional, a good autoformatter will automatically insert them. If you've got it set to run every time you save the file or run tests, it's likely to do so long before you have a chance to produce the next Heartbleed. It's not perfect, of course, but it's as good a protection against this sort of thing as I've ever seen. > Also, in Vim, indenting/dedenting a block is just highlighting the lines and using > or <. But, excluding plugins (which aren't available/consistent across all the editors where I use a vim editing mode), I don't know of a quick vim command that lets me quickly select, delete, replace, yank, or change the full contents of a scope in a whitespace-sensitive language. Or quickly jump to the beginning or end of the current scope. Stuff like that. Versus, with curly brace languages, vanilla vim gives me an experience that approaches the ease of paredit.

hadem 5y ago
> I don't know of a quick vim command that lets me quickly select, delete, replace, yank, or change the full contents of a scope in a whitespace-sensitive language. I'm sure there are better ways, but you could v9G$ to select from the current line to the end of line nine. Or v9j select the next nine lines, v9k previous nine, etc.
- mumblemumble 5y ago
  But compare the ergonomics of: 1. yi{ To: 1. Find line number of start of scope. 2. Decide on easiest way to get there, and either: - kk - 5k - 37G 3. Find the end of the scope. 4. Decide how to grab it. Then: - y9G$ - y3j - V, jjj, y I hope maybe I've made my case that it's more awkward, right? That is not to say that I don't know how to do it. It's just that, in the one case, I can do the job in one thoughtless action that lives so deeply in my muscle memory that I barely even consciously remember what the actual keystrokes involved are. By contrast, in the other, it takes several steps, some of which are likely to be small pauses to decide how to do the next step.
  - 5y ago

TheCoelacanth 5y ago

> Your auto formatter can’t figure out where you missed braces either. Correct, but I will notice the braces are wrong when the auto-formatter indents things differently than I expect.

xigoi 5y ago
And I'll notice the indentation is wrong when the indentation is different than I expect.

secondcoming 5y ago

How does significant whitespace save you from bugs? if expr: doA() doB() Is doB at the correct level? Having text that's invisible change the flow of your program is crazy IMO.

feffe 5y ago
I don't care that much in my own side projects but when working with others and resolving merge conflicts your example is my nightmare. It's so much easier to have brackets denote scope as you don't have to get the indentation right when actually resolving merge conflicts. It's easy to fix it up afterwards by automatic indentation in the editor. Significant white space is a mistake IMHO :-)
akubera 5y ago
The bugs being referred to are from optional brackets in C: void foo() { ... if (expr) doA(); doB(); ... } which is unambiguous to the compiler, but could (and I expect would, especially when glancing through a lot of code) cause misinterpretation by a human reader. We can more easily hallucinate the brackets than the indentation. I disagree with the idea that indentation spaces are invisible; rather they are much more visible than a pair of brackets. This actually becomes a problem when you embed/indent too much and 70% of the line is spaces. It's all you see!
- secondcoming 5y ago
  Yes, but pretty much every coding standard I've seen mandates the use of braces always. You do it without even thinking. Your example wouldn't pass code review.
xigoi 5y ago
if (expr) { doA() doB() } Is doB at the correct level? It's the same thing.