> 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.
> 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.
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.
My main editor is IDEA, followed by vscode and emacs. But all three are set to vim mode. Vim itself has actually never been my primary editor; I generally only use it when I'm sshed into servers.
The thing that vim mode gets me is twofold: It (mostly) unifies the editing interface among all of those editors, and it allows me to edit code more quickly.
The thing I was talking about above is not indenting - my autoformatter does that for me. The thing I was talking about is (a sort of hacky version of) syntactically aware editing that allows me to quickly do large-scale operations without having to explicitly fiddle with the cursor.
I think that by installing vim on all your editors, you are missing out on a lot of productivity.
You are basically giving precedence to text edition over code edition. When you use an IDE, you are editing code, not text, and that IDE's key bindings are optimized for that purpose.
I suggest you take the time to learn native key bindings to whatever tool you picked and see where that gets you, you'll be surprised after a few weeks.
You took the words right out of my mouth. I'm in the exact same boat. I use more than one editor but I always install the vim plugin. It provides an instant speed boost to using that editor efficiently and quickly. We don't switch editors _that_ often, but at the same time, remember trying to remember keyboard shortcuts for TextMate, then Sublime Text, the VSCode, then IDEA, etc.? With the vim plugins, editing text is now the same across all editors.
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
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.
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.
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!
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.
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.
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 <.