Ah, the best kind of indent. A tab and a space.

It’s not just “might”. Termux is pretty much the only good choice for programming on Android.

I think 9 is the best size for indent (matter of preference), do you think I should switch to space

I think you should switch to an exorcist.

Why would you ever need 9 other than trolling people on the internet?

What environment are you using that has a hardcoded tab size?

• Termux
• SourceHut
• “View page source” in the browser

Github uses 8 as a default. It’s configurable though.

What environment are you using that has a hardcoded tab size?

Microsoft Windows’ Notepad. I have sometimes used that when on a public computer.

When you’re operating on such a low level of abstraction, it’s no wonder you don’t need deep nesting.

My spontaneous reaction is that making some sort of braille oriented setting for some or hopefully most editors used by people with braille displays (I have no idea if using a “normal” editor even makes sense if you’re using a braille display) is the most pragmatic solution to their screens being taking up by spaces.

First of all, convincing everyone to use tabs is a monumental task. Convincing people with braille displays to use more convenient tools on the other hand seems pretty easy, why wouldn’t you want to use more convenient tools?

Secondly, there is a large amount of code written with spaces today, so even if people switch with tabs in the future you might still want to be able to read legacy code.

Thirdly, I don’t think that the choice of tabs vs. spaces is completely arbitrary because of alignment. Using tabs for indentation and space for alignment leads to a lot more micro management of whitespace compared to just using spaces. I would guess that alignment isn’t very braille friendly anyway, but it does make the code more readable for other people. Having a good braille editor affordance might be closer to letting us have our cake and eat it too.

Of course, I don’t know what this would look like exactly, and maybe there’s some sort of obstacle that I’m overlooking, I do want to be clear that this is just of the top of my head as someone who has never used a braille display.

This is the attitude that’s needed 👍

That reminds me of those times when back on reddit some dev showed up to present their new GUI library. Bragging about how they were better than Qt devs etc. (even though they didn’t implement the hard parts, like working text fields or tables)

After some time a bunch of people had enough and started bullying those guys into submission about accessibility. After some time, every of those toolkits had support or at least plans for supporting screenreaders. Eventually, AccessKit became a thing.

Good times.

Arguing that it’s invincible to convince people at large to adopt tabs over spaces with good arguments is a ridiculous statement

I do actually think that it is very hard to convince basically every programmer of something, no matter how good arguments you have.

Also, without knowing much about the issue, it sounds a bit like the tooling for people using braille displays isn’t very good and fixing that is maybe also worth advocating for, perhaps it’s even a strategy for advocacy that is more effective?

And over gofmt, rustfmt lets you set settings for the project. Keeps the code looking how I want, and contributers don’t have to care.

Great, no scrolling through thousands of lines to find the right one!

Now next time I read anything about why any Python libraries are named what they are named, I’m going to hear Dr Doofenschmirtz voice. Thank you for that.

What, the code is made up by the number of consecutive spaces, delineated by tabs, line feeds, carriage returns (which have different semantics from line feeds) and non-breaking spaces?

deleted by creator

struct Ident arr = [
{
.id
= 0,
.name
= "Bob",
.pubkey
= "",
.privkey
= ""
},
{
.id
= 1,
.name
= "Alice",
.pubkey
= "",
.privkey
= ""
}
];

seconded on not aligning things. its the whole source of the problem in the first place and doesnt even serve a purpose

Always do spaces, because you can never trust how someone else has their tab configured.

How is this even a debate anymore. I thought we all agreed on this years ago.

I understand your point of view. Personally I either copy the previous line and replace the arguments there, or insert X number of space using the repetition feature of my editor. It also has a feature that will align multiple cursors together with the “farthest” one using space, which is a killer feature for me! (See this presentation video @1:40).

deleted by creator

And this is why language servers and formatters are so critical.

I agree that it’s hard, but not impossible. This usually boils down to how Nazi people are when merging code. In a corporate environment, nobody gives a damn so yeah you gotta use whatever you want because there are already different indentation systems within the same file anyway :)

But hey, you gotta live by the changes you want to see happen, so I personally put a lot of effort in formatting my code regardless.

The opposite is true, though. If you use tabs for indentation and spaces for alignment, you can adjust the tab width without destroying alignment. That’s the big benefit of the tabs-for-indentation-spaces-for-alignment mix.

You can’t do that with only tab characters, you can’t even align stuff with tabs because it has variable width.

You’re confusing using tabs for indentation and spaces for alignment with using tabs and spaces for indentation. This means each line starts with tabs. Next you optionally have spaces for alignment with previous lines. Then you have content (like code or comments). Because you never have a tab following a space the alignment is never destroyed by adjusting how wide a tabstop is.

You might not understand how to do it properly so here’s the idea:

Tabs will let you reach the indentation level of the current block, then from here, you’ll use spaces to align stuff property. Here’s an example, where >••• are tabs (I’m exaggerating alignment for the sake of the example) :

>•••if (condition1 == true
>••• || condition2 != false)
>•••{
>•••>•••struct ident people[] = [
>•••>•••>•••{
>•••>•••>•••>•••.name   = "bob",
>•••>•••>•••>•••.pubkey = "value1",
>•••>•••>•••},
>•••>•••>•••{
>•••>•••>•••>•••.name   = "alice",
>•••>•••>•••>•••.pubkey = "value2",
>•••>•••>•••}
>•••>•••];
>•••>•••secureConnection(people[0].name, people[0].pubkey,
>•••>•••                 people[1].name, people[1].pubkey,
>•••>•••                 CRYPTO_ALGO_DEFAULT);
>•••}

As you can see, everything will stay correctly aligned as long as it’s within the same block.

Do not mix tabs and spaces.

Its impossible to automate checking that tabs were only used for indentation and spacing for precise alignment. So you then take on a burden of manually checking

You end up with the issue where someone didn’t realise and space idented or anouther person used tabs for precise alignment and people forget to check the whitespace characters in review and it ends up going inconsistent and becoming a huge pile of technical debt to fix.

Use only one, you can automate enforcement and ensure the code renders consistency.

I think you have it backwards. If you use tabs for indentation and spaces for alignment it works great for any tab size.

It is when you use a tab just as a compressed representation of 8 spaces and use them for alignment as well that it goes to shit. (because you have made the sin of tab == 8 spaces instead of the correct tab = 1 indent level)

Using only tabs for indentation and only spaces for alignment will never result in crap alignment when adjusting tabstops because the alignment does not use tabs.

This is using both tabs and spaces for alignment.

--->func foo(int i,
--->--->     int j);

Observe what adjusting the tabs does,

->func foo(int i,
->->     int j);

This uses only spaces for alignment,

--->func foo(int i,
--->         int j);

When converted the alignment is maintained because the tabstops aren’t used for alignment, only for indentation.

->func foo(int i,
->         int j);

…did you not read the article?

In come my idiotic colleagues:

“buT w3 lIke 2 SpACe5!”

fuck with the linter

You’ve a .editorconfig in your repo right? Right?

I created a tool for removing trailing whitespace across the whole project. After cleanup now it’s at least only a matter of pointing it out in reviews and occasionally fixing landed sources.

Do you have actual experience with it?

Some time ago I read a comment from someone with impaired eyesight who used an editor that would adjust space indent just fine.

Accessibility is a thing I always consider.

Tabs work fine, you aren’t allowed to mix, indentation must be consistent.

Anarchist: tab with set to 1

Happened to me quite a few times, relatable situation.