Neither tabs or spaces are good. The correct way is to leave no whitespace in the code at all. It’s unnecessary and adds to processing time.
Everyone should aim for 1LOC per commit
“Error: syntax error on line 1”
…shit
Great, no scrolling through thousands of lines to find the right one!
Scrolling to a line number seems inefficient.
My program, written in the whitespace language, ruined.
CURSE YOU PERRY THE PLATYPUS!
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.
I wish every language had a gofmt, this is such a non-debate (tabs are indentation, spaces are alignment)
The argument for having tabs adjust depending on your ide sounds better than it is in practice. Someone formatting code to look nice with width 4 will look horrendous for someone who uses width 8.
Spaces makes it uniform and captures the exact style the original dev intended
If you have your tab width set on 8, that is on you. You will also set your IDE to insert 8 spaces when you press TAB and I will cry when I have to give you a code review.
When I indent my code, I am indicating that I am in a nested block. I don’t care if, on your screen, that indent is 2, 3, or 4 characters.
Anarchist: tab with set to 1
That’s fine, when I view it I will get my preferred tab width. This situation is only anarchist with spaces, with tabs they are just a masochist.
If the original dev intended to make their code less accessible and their project less inclusive in favor of eye candy, they should rethink their priorities.
Tabs let you define how big you want each indent to be
…except when they don’t. Many common environments have a hardcoded tab size of 8, which is insanely big for using it for indentation.
Because other people might have restricted environment which might not suit their preference is not a good reason to level it down IMO.
Also, I think 9 is the best size for indent (matter of preference), do you think I should switch to space so everyone can enjoy this wonderful view I have ?
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.
What’s your point ? You can use vim on termux and set the tabsize to whatever you want for example.
Also
:exorciseis only a quickpluginstallaway, anyway. /sYes, but if you use something like
cat,head,less, etc. to view code, or the Python REPL, you’re still going to see the default tab size.You can set the tabstop with
less -x*n*. But ok I see what you mean. I still stand by my point though. If termux doesn’t support setting tabstops and it’s an issue, then it’s a bug in termux, not a reason to level down your formatting standard.
Ah, the best kind of indent. A tab and a space.
Or just set tabsize to 9, that’s the point :)
Where’s the fun in that?
Why would you ever need 9 other than trolling people on the internet?
Straight on point!
What environment are you using that has a hardcoded tab size? I haven’t seen this since typewriters.
Some projects just use tabs as a compressed form of 8 spaces. But that is a sin. Use tab to mean “one indent level” and align with spaces if you need to. (the occasional ASCII art diagram)
Github uses 8 as a default. It’s configurable though.
What environment are you using that has a hardcoded tab size?
- Termux
- SourceHut
- “View page source” in the browser
Termux
I think running
tabs -N(whereNis you preferred tab size) in the terminal should work. This is what I use in my zshrc on desktop.SourceHut
Yup, they seem to be pretty opinionated here. If you look at the source there is just an inlined style with a single rule
pre { tab-size: 8 }. I guess that is what you get when you use opinionated tools. The user’s browser isn’t right, my preference is right!“View page source” in the browser
On Firefox this uses my default tab size of 4. But I guess changing this default isn’t user-friendly.
You can’t count it as good when it is unconfigurable when it happens to use your preference when the whole selling point of tabs is that they’re configurable.
I don’t understand what you are trying to say. I agree that SourceHut forcing their preference isn’t good. The other two are configurable and I have configured them to my preference on my machines.
You made it sound like Firefox wasn’t configurable, my bad. I thought you were saying you didn’t care that it wasn’t configurable because you liked the width they chose.
Oh no. It is configurable, although it requires editing
userContent.css. So barely configurable. I think it defaults to 8 but I reduce it to 4.
What environment are you using that has a hardcoded tab size?
Microsoft Windows’ Notepad. I have sometimes used that when on a public computer.
This is the biggest problem with tabs. Too many tools don’t let you adjust the size (or make it very difficult). This is the only reason I usually prefer spaces (only very slightly).
My dream solution is elastic tabstops and I’ve posted about it here before a few months ago. The problem with wanting elastic tabstops is that it seriously compounds the issue of “editors don’t properly support it”
As an embedded software developer that does linux kernel drivers I’ve come to love the tab size 8 indentation level.
I’m paraphrasing: “if your indentation level gets too deep, it’s time to rethink/refactor your function.”
And with tab 8 you’ll notice it rather quick if your function does too much/unrelated stuff.
A function should be short and do one thing only, if possible. It also makes unit testing easier if that’s a requirement.
When you’re operating on such a low level of abstraction, it’s no wonder you don’t need deep nesting.
Oh, I’ve done my fair share of C++ and Python as well. But you got to agree with me that when you are on your fourth indented “if case” it’s time to step back and think about what you are trying to achieve. I mean it’s probably going to work, but probably also very hard to maintain that type of code.
How would you implement, for example, Gaussian elimination with at most 3 levels of nesting?
Abstraction.
The solution for all levels of nesting.
Be specific. Which exact part would you abstract away and how?
There a many ways to implement abstractions, but it’s highly dependent on the language in question. You could simply refactor each level of nesting into its own function, with all dependents provided as parameters instead of scoped variables. You could then flatMap to avoid a bunch of nested looping, favoring a linear approach that’s often easier to reason about. You could go all out and refactor all your conditional statements away, in favor of the Either monad. You’d then have a number of functions, each doing one thing (including no nesting), and a main function gluing it all together, linearly. That is a pattern you can always apply; there’s nothing controversial about it, and on a similar note there’s nothing particularly challenging about Gaussian elimination.
Years ago there was no way to share IDE settings between developers.
You ended up with some developers choosing a tab width of 2 spaces, some choosing 4 spaces and as there was no linting enforcement some people using 2-4 spaces depending on their IDE settings.
This resulted in an unreadable mess as stuff was idented to all sorts of random levels.
It doesn’t matter if you use tabs or spaces as long as only one type is consistently used within a project.
Spaces tends to win because inevitably there are times you need to use spaces and so its difficult to ensure a project only uses tabs for identation.
IDE’s support converting tabs into spaces based on tab width and code formatting will ensure correct indentation. You can now have centralised IDE settings so everyone gets the same setup.
Honestly 99% of people don’t care about formatting (they only care when consistency isn’t enforced and code is hard to read), there is always one person who wants a 60 charracter line width or only tabs or double new lined parathensis. Who then sucks up huge amounts of the team time arguing their thing is a must while they code in emacs, unlike the rest of the team using an actual ide.
deleted by creator
I’ve always wondered why some people tout “forcing a consistent appearance across environments” as a pro for spaces. That’s a bad thing.
To be honest I’m surprised code format converters aren’t ubiquitous. Let the repo have it’s master format, enforced on commit. Then converters translate into each developer’s preferred standard dialect on checkout and back again on commit.
Tabs for indent, spaces for alignment. This is the way, I can’t believe people are still fighting that ?
Then you lose the benefit of tabs: you can’t adjust the tab width without destroying alignment. So you end up with a confusing mix of characters for no benefit.
Mixing them is the worst option.
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.
I am not, it’s easy to find examples where tabs first then spaces breaks down.
That example is using tabs for both indentation and alignment. The article you linked even says not using tabs for alignment is a solution.
- Do not use tabs for alignment. In such case given example should look like:
fun foo x = --->let val abs = if x > 0 ---> then x ---> else -x --->in --->--->(* ... *) --->end
Anything for indent (barely matters, as long as the editor forces it to stay consistent), and fuck alignment, just put things on a new line.
struct Ident arr = [ { .id = 0, .name = "Bob", .pubkey = "", .privkey = "" }, { .id = 1, .name = "Alice", .pubkey = "", .privkey = "" } ];Not like that, lol
Just saying, instead of this monstrosity
CreateOrderRequest(user, productDetails, pricingCalculator, order => order.internalNumber)Just use
CreateOrderRequest( user, ...Putting the first argument on a separate line.
Same if you have an
ifusing a bunch ofand(one condition per line, first one on a new line instead of same line as theif) and similar situations.When I talk about alignment it’s not about function arguments, but values, “=” signs and such. You simply cannot use tabs for that because alignment must be fixed and indentation independent:
CreateOrderRequest( user, productDetails => order.detail, pricingCalculator => DEFAULT_CALCULATOR, order => order.internalNumber)
seconded on not aligning things. its the whole source of the problem in the first place and doesnt even serve a purpose
It does help with reducing thrashing between edits in git diffs. Or rather, opinionated autoformatters do, which is the only reason I bother with alignment.
Original poster is right by all accounts, of course. Now, let’s come up with exotic significant indentations.
function xyz(a, b): | var x = 2 | if true: | | do_something() | else: | | do_something_else() | anyway()Pro: Your editor no longer needs to implement indentation hints.
Con: Looks obstructive if not highlighted like an indentation hint.
Your turn.
Right, that is another item I wished more editors would have picked up. Besides - say - nested language modes.
That’s all well and good if everyone uses editors you can configure to a certain standard all the time. Then tabs all the way.
Unfortunately that’s not reality for everyone.
Everyone should use a better editor.
Interesting take. I prefer spaces because each piece of code that I see with tabs has an implicit tabsize you really need to have if you don’t want the code to look ugly - especially if the person has been mixing tabs and spaces - and they usually do. Sometimes unadvertently.
When you remove all tabs at least everyone is on the same page.
To the actual problem raised by the article:
I have ADHD. Two spaces per indent makes it damn near impossible for me to scan code. My brain gets too distracted by the visual noise. Someone who’s visually impaired might bump their font size up really large, and need to scale up or down the amount of space per indent. Someone might just prefer it because…
I wonder if it could be possible to adjust the “indent number of spaces you see” in code editors. Code editors are able to figure out what are indents and what are not, so in theory it should be possible. Perhaps that would be an idea for a new feature?
I think calling one way better than the other is flawed. The reason the title is saying that tabs are objectively better is because they are used in addition to where spaces are used elsewhere. You could make the same argument in favor spaces due to keeping things simpler.
The argument of having variable indent size for tabs so viewers can decide how big they are is imho legitimate but also not the goal as it’s addressing something that teams generally agree on. There is max characters per line, brace placement, general code style and rules. Yes we can eject the indentation from the rules that are agreed on but once again simplicity over complexity has an equal say.
In the end it doesn’t matter that much, a good programmer will be able to work in either setting, the Editor will do most of the work anyways.
With all that said, spaces all the way!
Another accessibility reason for tabs: when using a braille display, each space takes up one character cell, so indenting with four spaces eats up four cells. Indenting three times with four spaces each eats up 12 characters already. Tabs only take one character cell each, so three indents = three character cells used.
The fact that there (I assume?) isn’t a braille oriented text editor that can handle space-based indentation in a smarter way is a bit depressing. Maybe the solution should be better tools based around accessibility rather than convincing everyone to switch to tabs, which is a project that will just never succeed.
So your fix is “convince all the people that want/need the better handling to use a specific editor?” - perhaps it’s a smaller number of people, but do you not see the irony there?
I honestly don’t care about tabs vs. spaces, but if there’s a low cost change in my setup that makes it easier on others, why not?
rather than convincing everyone to switch to tabs, which is a project that will just never succeed.
Few years back, Coraline Ada Ehmke went on a one person crusade opening a pull request on every major Github repository to adopt a code of conduct for the project, detailing the complex rules of how the humans in that microcosm of a project should interact with one another. Today, it’s the norm.
Arguing that it’s invincible to convince people at large to adopt tabs over spaces with good arguments is a ridiculous statement. All you are doing is making up excuses for not having to care.
I consider tabs for indentation a failed concept.
The idea is good, but it evidently failed. Most guidelines and newer Tools recommend or require or use spaces for indent. They have their reasons too.
The prevalence of spaces makes it hard to make a contrary argument for tabs. By now, I don’t think it’s worth even if it had reasonable advantages.
Editors/IDEs that parse syntax can adjust space indent too. A mixture for indent and alignment is not obvious for everyone (I always display whitespace in my editors and am deliberate and consistent, but many people and editor defaults won’t be). Some defaults of four or eight space-width tab display is atrociously wasteful and inaccessible.
Spaces are a good enough baseline. It works well enough. And most importantly it works consistently. That’s why it won in prevalence and use.
Yesterday, I shared some spicy takes. A few were particularly controversial—most notably, that I correct Gif the correct way (with a soft G)
And I stopped reading there.
