The biggest issue I have with Yaml is that they forbid tabs.
Their argument is that tabs are shown differently in every editor which is actually something I like. When you're looking for something deeply nested you can reduce the tab distance a bit, when that's not needed you can increase it to improve visibility of nesting levels.
And forbidding it makes a one-keystroke action a two or four one.
I really don't understand the python/Yaml hate for tabs, and as a result I don't really use either.
What is a problem is not picking one or the other. There's arguments for both sides but it is critical to just take a side. I'm sorry your side lost but it makes everything better to just go along with the consensus.
No, that's what the tabs hold-outs have morphed into. Which illustrates the problem with tabs: It's very difficult to get everyone on a team to care about tabs or not care about alignment.
Yeah, OP is not wrong. I also like neatly formatted code and is way easier to read.
I always reformat all my code before all commits. It's just good hygiene.
The funny part is the fussing and the answer they get.
I'd just autoformat the area of my patch and send in the patch that way, maybe plus some autoformatted blocks here and there, slowly fixing the stuff as I go.
If something is too bothersome, first try doing something, and figure out the rest of the process as you go.
Edit: blocks became blogs without my knowledge. Maybe I should write a blog post about it. Don't know.
Us old folks remember the days when reformatting was a computationally expensive action that required a special program to “pretty print” the code. And heaven forbid your code used some language feature your pretty printer didn’t understand and mangled the output making your code uncompilable.
Well, I'm not that of a young folk. I was playing with computers (programming, in fact) in the early 90s, and I remember when it was expensive.
However, Eclipse is formatting C++ code with a simple hotkey and without breaking it and understanding the language for the last 15 years as far as I can remember. It's instant, too.
Because of that I feel a bit surprised when younger people look it like it's black magic. It's neither new, nor unsolved in my conscious experience.
JSON formatting is less important because most apps that deal with it come with good “beautify”, “sort”, “remove all formatting white space” functions in the editor
Ouch. The only problem with the obvious sarcastic tone of that comment is that there are plenty of people that do say exactly the same thing and mean it.
For code I'd agree. However for configuration files, I find that I often need to edit them in places or environments where I don't have anything but the most bare-bones editor.
When this happens, I copy four spaces and then use Ctrl+V for Tab.
Yes, it’s not exactly the same due to alignment, and yes you have to repeat it after using the clipboard for other purposes, but it’s good enough for that occasional use.
When looking at the code, tab-containing files are the most inconsistent ones, especially when viewed via general tools (less, diff, even web viewers).
Sure, if people would only ever use tabs for indentation and spaces for alignment, things could be good. But this almost never happens, instead:
... some lines start with spaces, some with tabs. This looks fine in someone's IDE but the moment you use "diff" or "grep" which adds a prefix, things break and lines become jagged.
... one contributor uses tabs mid-line while other use spaces. It may look fine in their editor with 6 character tabs, but all the tables are misaligned when looking in app with different tab size.
Given how many corner cases tabs has, I always try to avoid them. Spaces have no corner cases whatsoever and always look nice, no matter what you use to look at the code.
(the only exceptions are formatters which enforce size-8 tabs consistently everywhere. But I have not seen those outside of golang)
> Sure, if people would only ever use tabs for indentation and spaces for alignment, things could be good. But this almost never happens, instead:
... some lines start with spaces, some with tabs.
People using tabs for alignment can happen when you've got a tab-camp-person who hasn't yet realized how they're terrible for alignment.
But "some lines start with spaces, some with tabs" happens for precisely two reasons:
* you have a codebase with contributors from both camps
* people thought in-editor tooling was the solution (now you have two problems)
> Spaces have no corner cases whatsoever
This is tooling and (as you realized) stop preference dependent.
And I've been using vim exclusively for north of fifteen years with Tab replacement, never had a problem with the editor getting confused about what happens with spaces when I hit Tab.
Some detail about the corner cases you've run into would be great, if they're happening constantly I can see how it would be a bugbear.
For example with vim (debian) defaults, if you happen to have a 2-space indented Python (the first two spaces are for HN formatting, the first if should start at zero indent):
if True:
# Two space indent
And continue to add another if block in that, the autoindent will give you four spaces:
if True:
# Two space indent
if True:
# Four space autoindent
And if you make a new line after the last row there and hit a backspace, it'll erase one space instead of four, giving an indentation of 3 (+2) spaces. And if you start a new line after that, you'll get an indentation of 8 spaces in total. Ending up with:
if True:
# Two space indent
if True:
# Four space autoindent
# Hitting backspace gives this
# Hitting a tab gives this
This is just a one case, but things like this tend to happen quite often when editing code. Even if it's been originally PEP-8 indented. Usually it's not what the Tab does, but what the Backspace or Autoindent does. I'm not exactly sure what exact Tab/Backspace/Autoindent rules underlie the behavior, but I can imagine there having to be quite a bit of hackery to support soft-tabs.
For me this kind of Tab/Autoindent/Backspace confusion is frequent enough that I'd be very surprised if others don't find themselves having to manually fix the number of spaces every now and then. And when watching over the shoulder I see others too occasionally having to micromanage space-indents (or accidentally ending up with three space indented blocks etc), also with other editors than vim.
if !exists("g:python_recommended_style") || g:python_recommended_style != 0
" As suggested by PEP8.
setlocal expandtab tabstop=4 softtabstop=4 shiftwidth=4
endif
So if you use "set sw=2" then it leaves tabstop and softtabstop at 4.
You can set that g:python_recommended_style to disable it.
Also sw=0 uses the tabstop value, and softtabstop=-1 uses the shiftwidth value.
I agree Vim's behaviour there is a bit annoying and confusing, but it doesn't really have anything to do with tabs vs. spaces. I strongly prefer tabs myself as well by the way.
Even when you DO use tabs Vim will use spaces if sw/ts/sts differ by the way. Try sw=2 and using >>, or sts=2 with noexpandtab.
As with most things in vim, it is definitely manageable in settings such as tw=2 (tab width) and sts=2 (soft tab stop). This is why a lot of older Python files, in particular, are littered with vim modelines with settings like these.
The nice modern twist is .editorconfig files and the plugins that support them including for vim. You can use those to set such standard language-specific config concerns in a general way for an entire "workspace" for every editor that supports or has a plugin that supports .editorconfig.
The defaults are either 4-space or 8-space soft tab stops. 8 spaces it the oldest soft tab behavior. 4-space soft tabs have been common for C code among other languages for nearly as many decades. It is only relatively recently that Python and JS and several Lisp-family derivatives have made 2-space tab stops much more common of a style choice. Unfortunately there is no "perfect" default as these are as aesthetic preferences as anything else.
(It is one of the arguments for using hard tabs instead of soft ones in the eternal tabs versus spaces debates because editors can show hard tabs as different space equivalents as a user "style choice" without affecting the underlying text format.)
The part where the user is on a line indented by 2, hits return, and gets a line indented by 2+4=6 doesn't sound like soft tabs at 4 to me. And I wouldn't expect hitting backspace to then only remove 1 space (if it actually removed 2 that makes more sense, but is inconsistent with what what it just added). At that point, hitting return and getting a line indented by 8 might make sense but is weird.
Another comment suggests it's using 2 and 4 for different settings and that's causing problems.
2 is the base indent of the line where the : was added. Autoindent adds 4 spaces for the current tab stop. Autoindent isn't using some counts of indents, it's taking "spaces in previous line + tab stop".
Backspace doesn't unindent in vim by default, it removes spaces one at a time. That's a difference between the ts=4 (tab stop) and sts=4 (soft tab stop) is sts also applies to backspace. But the default is that it doesn't because the out of the box default believes that backspace operates on physical characters (spaces) not soft/fake ones (tabs expanded to spaces) by default.
I don't know if that is the right default, and it is definitely a baroque exercise to get all the settings right for some languages, but there is a consistency to the defaults even if those defaults don't meet some modern expectations from newer code editors.
(Also, I just realized above I confused tw [text width] and ts [tab stop]; my vim skills are rusting a little.)
I don't want that though. Because then when editing I still have to mess around with spaces.
And the double nature of the spaces makes it hard to see when you have an odd number of spaces when you reach deep indenting levels, which counts as the lesser number of double spaces in Python.
IMO it would be ideal if tabs would be displayed as a block, and you could resize the width of that block on the fly <3
> And forbidding it makes a one-keystroke action a two or four one.
The majority of editors can be configured to use tab to insert the appropriate number of spaces. Many will automatically detect the correct configuration.
Your problem, and I mean this sincerely and respectfully, is that you're not using your text editor / IDE correctly. Adding two or four spaces of indentation is done by pressing TAB! Once. Most editors will do know how to do this out of the box, but if yours doesn't you need to change it.
You still have to mess around with a bunch of spaces when you're editing or copy/pasting, and not having exact even numbers makes for ambiguous situations.
Especially if something is 5 levels deep, it's really hard to see if you have 12 or 11 spaces (so 5 levels + 1 space or 6 levels) indentation.
My editor, I press tab once and it inserts the correct number of spaces (on a new line it also starts at the previous indentation level as appropriate). I press backspace once and it deletes the correct number of spaces.
Any editor used for programming needs to be capable of this.
I agree with you about YAML's treatment of tabs. I still use YAML because there's often no other choice.
Python is actually flexible in its acceptance of both spaces and tabs for indentation.
Maybe you were thinking of Nim or Zig? Nim apparently supports an unsightly "magic" line for this (`#? replace(sub = "\t", by = " ")`), and Zig now appears to tolerate tabs as long as you don't use `zig fmt`. I haven't used either yet because of the prejudice against tabs, but Zig is starting to look more palatable.
> I agree with you about YAML's treatment of tabs. I still use YAML because there's often no other choice.
True, I'm using it too when I have no other choice.
> Python is actually flexible in its acceptance of both spaces and tabs for indentation.
True but it does give constant warnings then which is annoying. And I was worried about it dropping support in the future so I didn't want to waste time learning it.
> forbidding it makes a one-keystroke action a two or four one.
Not if your editor can be configured to interpret a Tab keypress as the appropriate number of spaces. AFAIK all common text editors, at least in the Unix world, do this.
*> I still have to mess around with spaces when editing.
Not if your editor automatically indents and dedents with spaces. I find that to work just fine when editing Python code, for example. Tab is interpreted as "indent" and Backspace if you're at an indent stop is interpreted as "dedent".
It does not. You still have to mess around with a bunch of spaces when you're editing or copy/pasting, and not having exact even numbers makes for ambiguous situations.
I use tab and shift tab on intellij and vim on insert mode. Outside of insert mode I use "<<" and ">>". I am on vim mode on intellij too. What editor are you using?
Their argument is that tabs are shown differently in every editor which is actually something I like. When you're looking for something deeply nested you can reduce the tab distance a bit, when that's not needed you can increase it to improve visibility of nesting levels.
And forbidding it makes a one-keystroke action a two or four one.
I really don't understand the python/Yaml hate for tabs, and as a result I don't really use either.