Yes. Ruby, for example, is entirely space-based, because it encourages line breaks after the first of a list of arguments, where the second needs to be aligned with the first, but depending on the number of characters in the method being called, the first argument could be anywhere in the line.

Do you have an example? I write Ruby and switched to tabs a while ago, haven’t noticed any problems.

Ok, so first of all, I'd strongly advise you not to use tabs for Ruby, just because it's a community very heavily based on stylistic consistency, and the community is very much on the side of spaces (see https://ukupat.github.io/tabs-or-spaces/).

For one example of something that wouldn't work with tabs (although not my original point, see the whitespace between `key:` and `key,` on line 66 here: https://github.com/rails/rails/blob/main/actionmailbox/app/c...

For an example closer to my original point, see line 13 here: https://github.com/heartcombo/devise/blob/master/app/control...

> I'd strongly advise you not to use tabs for Ruby, just because it's a community very heavily based on stylistic consistency

I've published plenty of gems and open source Ruby work and I choose how I write my code, thanks, and I couldn't care less what the "community" thinks about tabs vs spaces. The "community" believes all sorts of nonsense and if they don't like my code they can fork it and "fix" the tabs. That may sound a bit combative but I don't take well to being told I'm the nail that stands up too much.

My views on tabs changed based on something I read of Samuel Williams (it could be this[1] or this[2]) that was entirely reasonable (note his far more gentle rebuttal than mine with the key phrase being evidence based), and I'd consider him one of the top ruby devs.

As to the keywords example, I use tabs all the time with that style - what problem am I supposed to encounter?

To the other example with the array constructor sugar, I tried it with tabs, I didn't see a problem:

``` helpers = %w(resource scope_name resource_name signed_in_resource resource_class resource_params devise_mapping)

helpers.each do |h| puts h end

$ ruby test.rb resource scope_name resource_name signed_in_resource resource_class resource_params devise_mapping ```

Apologies if the HN markdown sytax means this get mangled, no idea if it'll take fenced code blocks but you get my drift.

[1] https://github.com/ioquatix/universal-style-guide#indentatio...

[2] https://github.com/ioquatix/rack-freeze/issues/2#issuecommen...

Edit: It did get mangled :/ there's a newline and then plenty of tabs in there. Worked like a charm.

See also the first "good" example at https://github.com/rubocop/ruby-style-guide#no-double-indent, and the placement of 'from' in it

I read that and thought to myself "So what? " They're all perfectly readable and consider that an excellent example of bikeshedding.

Further up it suggests "Don’t use several empty lines in a row." I put two lines between every method and it makes a language where every block ends with `end` far more easy to grok just from the shape.

It seems I won't be using all of their suggestions.

Er... that's a simple, widely accepted and understood standard, with a broad set of tooling that can detect and auto-correct it. Crucially, it's something that doesn't really matter. Therefore, because it's, in Ruby world, the norm, the great thing is that we can, by default, just accept that norm, never think about it again, and get on with our day.

Bikeshedding, on the other hand, is taking a contrarian stance and deliberately arguing over stuff that really doesn't matter so that we spend time and energy arguing over that instead of over the code itself and what it's trying to achieve...

> Er... that's a simple, widely accepted and understood standard

Yes, and pointless, all the examples were readable.

> Bikeshedding, on the other hand, is taking a contrarian stance and deliberately arguing over stuff that really doesn't matter

Imagine thinking that using tabs is a contrarian stance! I remember when being a rubyist was seen as being able to think for yourself. Times have changed.

In my book the third example is also bad, only the simple indentation is good.

None of your examples pose a fundamental problem for tab-indentation; here's the basics how it should (always) be done, and works, and never breaks anything regardless of the width of the tab character as long as you don't break the gist (which is the hard part, especially with editors which sometimes work against you):

  def send_mail(source)
  TABMailer.deliver(to: 'bob@example.com',
  TAB               from: 'us@example.com',
  TAB               subject: 'Important message',
  TAB               body: source.text)
  end

Here, TAB has a width of three but of course the alignment would stay put even if it were wider or narrower.

Such a good argument against tabs. Spaces don't need all these shenanigans.

The convention in python is space-indentation.