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 ?
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?
Try it and you'll see
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 :exorcise is only a quick pluginstall away, anyway. /s
Yes, 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.
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)
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 (where N is 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.
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.
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"
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?
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.
There’s a difference between doing something that’s “easier” and what’s right.
Whether there is more legacy code with spaces or tabs is irrelevant. Most of the code that will be written hasn’t been written yet.
I disagree with you on “micromanagement” of spaces vs. tabs, that is nonsense. Set up a formatter for commits and set your IDE to display how you want.
The pragmatic view on one or the other is that for a one group of people, using tabs appears to be significantly better, and for everyone else, it barely matters at all, except as personal preference.
That being said, I’m not vision impaired, so I don’t know what the preference would be.
The reason we’re even talking about it is that someone that has studied it from an accessibility perspective has asserted that tabs would be preferred.
There’s a difference between doing something that’s “easier” and what’s right.
The way I see it, there are two competing strategies for improving the experience for braille screen users: making tabs more widely used and improving braille oriented editors. Without knowing for sure, my guess is that improving editors is a better strategy and this is in part because it is easier.
As a matter of principle it might be "more right" for people without visual disabilities to adjust themselves to people with visual disabilities than vice versa, but I also think that it's important to care about what is actually likely to improve braille screen users experience and not default to the more principled goal without any consideration for how realistic it is.
(Of course, I might be overestimating how easy it is to get better braille oriented editors, but since you referred to this as the "easy" solution it doesn't sound like you're disputing this specifically.)
Of course, I might be overestimating how easy it is to get better braille oriented editors
A braille display traditionally is a personal, almost handfitted (estimated by price) device controlled by its screen reader software. Not the editor. This has some unfortunate implications:
There is no (standardized) API to control your braille device directly. You could hand your screenreader filtered data, but that would be read as well. At best, you might be able to script your screen reader software to a varying degree of success. However:
Every aspect about this is extremely abysmal in every possible way, so it will likely require you to fork over some biiiiig amount of cash to one of the vendors to provide a brittle plugin. In particular if we are talking about JAWS. Think of extremely unstandardized COBOL dev with less stability and more price gauging involved.
As far as free readers are involved, only the proprietary and licensing aspect go away. Still, developing extensions is terrible in many ways. For example, for ORCA, I was able to find out that you can extend it somehow. Alledgedly. NVDA on the other hand has better documentation. That is to say, it has documentation. Now, you might recall that NVDA is written mostly in Python, and its devs rightly don't even pretend that one could develop stable software in Python, so APIs might change. However, I wasn't able to find a Filter function specific to braille output. That's likely because
From my superficial experience, developers of screen readers think of braille displays mostly as an alternative to speech. It even took them quite a while to be smart about not displaying redundant, long lines of text.
So yes, you might be overestimating how easy that is, compared to telling some diva asswipe chucklefuck to use that formatter or work at McDolans.
Thank you for the insight, didn't expect it to be that dire. Tabs and spaces nonwithstanding, hope that the screen reader/braille display tooling situation improves in the future, sounds like it is sorely needed.
I sure hope so, but I'm not overly optimistic tbh. The market is basically considered medical, therapeutic devices. It is as you imagine, probably worse. It isn't easy to find prices directly, but the only way this range of vendors continues to exist in this niche market is to sell devices with the complexity of a keyboard for four to five digits. There is no competition worth talking about happening.
So unless very specific regulation takes place, I don't see standardized access to braille displays happening.
Let’s agree that we aren’t going to affect this change in this comment thread, so which one is more “pragmatic” is beside the point.
What does matter is whether we decide to have an inclusive view on this issue, and are willing to make extremely minor modifications to our settings and workflows to be more accommodating for others.
I am encountering more and more cases where people behave in inexplicably selfish ways, and this just feels like another one. It’s low/no-cost to do, yet could yield benefits to others. Low cost/risk, high potential reward.
Starting with “we’re not going to even consider raising awareness and let the market decide” is just a very cynical way to approach the world, and I’d argue is even actively harmful to the people that hold that view.
Do you think it matters if getting a large number of people to switch to tabs is an achievable project at all? Maybe I am a bit cynical but this seems to me like something that is actually very difficult to do.
When faced with a problem like this I think it makes more sense to approach it from a perspective of what would be a practical way to actually address it and refusing to do that does I think in its own way betray a different kind of cynicism.
For the record what I'm saying isn't that I wouldn't switch to tabs for the sake of people with various disabilities, I'm saying that spaces are slightly better than tabs if you don't have any relevant disabilities so if there is a way to have the cake and eat it to that would be a nice bonus, but that's honestly besides the point.
You are treating this as a binary/zero-sum game. Will we get to 100% use of tabs (or spaces)? No. Will we get a "perfect" viewer made and then adopted by all visually-impaired people? No. Making people aware that a fairly mundane choice has a negative impact on others might change their behavior, or at least challenge it.
Change like this is incremental, so just having the conversation, and asking you to consider that making a small change to your config might help some people down stream is something. Asking you to bring this point to the next conversation about tabs vs. spaces, is helpful.
I’m saying that spaces are slightly better than tabs if you don’t have any relevant disabilities
This is my fundamental issue with your original statements, and this thread: It's a subjective choice that you think is slightly better than removing a barrier/major annoyance for an entire group of people that may want or need to interact with your code. It's closing the door on possibility for a minor personal preference.
I think that there might be a fundamental missunderstanding here: I'm not saying that we shouldn't use tabs to accomodate people with disabilities, I'm saying that better editor features seems like a better "solution" to the problem.
In the abscence of editor improvements I agree that it makes sense to use tabs to accomodate disabilities, I just don't think that it will catch on that mutch. I don't think that spaces (imo) being slightly better is a good reason to not accomodate dissabilities by using tabs right now, but I do hope there is a more editor oriented solution some day because I think it would propably be better both for people with visual disabilities and without.
Being in a slightly argumentative mood might have led me down towards validating this false dicotomy between editors and tabs, and I apologize for wasting both our time because of this.
You do have a point that I personally might have more influence over if a given project has spaces or tabs than if better editor features are made, but I think that there can be a point to having the poor support for programming that is apparently offered by screen readers to take some place in the discussion as well since that is a potentially more important piece of the puzzle.
I can't imagine that there is much of a point to keep replying after this so I think I'll leave it here.
I wish every language had a gofmt, this is such a non-debate (tabs are indentation, spaces are alignment)
rustfmt
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.
The absence of settings in gofmt is a feature. The kind of basic formatting it handles is not worth having opinions about.
Yet, I do. So, I like to enforce it.
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.
Code formatter and run auto format
Holy wars are fun, but this is the answer.
At least this way the holy war takes place in commits to change the formatting file.
Unless go, in which case the holy war is now everyone who hates go format rewriting the code in a different language.
CreateOrderRequest(user,
productDetails,
pricingCalculator,
order => order.internalNumber)
Just use
CreateOrderRequest(
user,
...
Putting the first argument on a separate line.
Same if you have an if using a bunch of and (one condition per line, first one on a new line instead of same line as the if) and similar situations.
People seem to have a real issue with using new lines and I've never quite understod why.
It feels like a lot of those people are using notepad like applications instead of coding focused ones with collapsible regions etc.
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:
It seems like this basic guideline, tabs to indent and spaces to align, solves the problem for everyone. It doesn’t matter what your tab width is, it’ll look “right” regardless.
This kind of "manual" alignment should be avoided for many reasons including the fact that adding/removing/changing of one parameter here may force you to modify multiple lines which on it's own is annoying but this will also show up in the diff during review making it harder to grep what was actually changed.
I personally favor code readability over patch readability. But I reckon this is a matter of preference so I can understand how you might not like that.
Yeah I agree I don’t find alignment very useful. It’s more work for dubious benefit, and god forbid you change one of the lines.
The way god indented.
I almost scrolled past this one
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.
I used to think this way, at least when writing C++. But it's objectively harder to do and convince other people to follow, especially if they can't be bothered to change their environment to display tabs and spaces differently. It's a losing battle so now I just do spaces when working with other people
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.
you can never trust how someone else has their tab configured
Why on earth would I care how someone else has their editor configured? It's none of my business, and none of yours either.
Because other people are fucking morons and their editor doesn't have visible whitespace enabled - or it does but they don't give a shit.
Therefore these fucking morons have anywhere between 2 and 8 spaces-per-tab configured and will happily mash the tab key however many times is convenient for them to align their code or comments because they don't understand shit about fuck when it comes to alignement (or they don't care). Now I open their file and everything is predictably misaligned. Spaces and tabs are mixed from one line to the next, and in particularly egregious cases no tab width I can locally set on the file will make it readable because multiple different morons used different tab widths to align with tabs - sometimes within the same goddamn function or comment.
Have you ever tried to read an important technical diagram in ASCII art aligned with tabs by different people with different IDE settings? Because I have. Emphasis on tried.
Spaces and tabs are mixed from one line to the next
This is a solved problem: Enforce linting before committing using something like Git Hooks / Husky.
Have you ever tried to read an important technical diagram in ASCII art aligned with tabs by different people with different IDE settings?
No, because we live in the present and use proper tools for diagrams. SVG diagrams tend to be common nowadays. I'm aware you can't read them raw, but realistically the intersection between people who need to read important technical diagrams and people who don't have access to a web browser is vanishingly small (dare I say nonexistent?)
Tell me you develop with modern languages without telling me you develop with modern languages.
Try linting perl, or bash.
Like yeah if you work on a modern JS/Python/C# project, whatever, whitespace is going to be autoformatted, so the tabs vs spaces debate does not matter AT ALL.
Tell me you develop with modern languages without telling me you develop with modern languages.
You say this like it's a bad thing?
Try linting perl, or bash.
If you're already writing Perl/Bash scripts then it would probably not take you long to write a git hook to check the beginning of each line of source to check if there's a space or a tab character and preventing the commit if the wrong one is found. Crude and far from perfect, but still better than nothing.
if you work on a modern JS/Python/C# project, whatever, whitespace is going to be autoformatted, so the tabs vs spaces debate does not matter AT ALL.
It does though. If you read the original article then you'd know that the advantage of tabs is that everyone can choose exactly how deep their tabstops are, which is an objective benefit over spaces.
It's not wrong to work with modern languages, but don't pretend that you have the answer to the debate if you don't work in a field where it applies.
Linting bash/perl is a TERRIBLE idea. Consider the following, extremely common piece of code (perl has equivalent syntax as well):
(lol lemmy bug found, can't write the actual "left angled bracket - left angled bracket" syntax, it somehow truncates the comment)
OTOH if you use a modern auto-formattable language, then you can auto-format to tabs with a git hook or IDE plugin (and back for committing) if you want, so the debate doesn't matter in that case. It goes both ways.
I've yet to find tooling that supports this. Clang format has a setting that looks like it does it, but actually does something else. If I have to press the spacebar a bunch of times each time I add an argument to a function, that's a pain, and it's a bigger pain to convince the people I'm working with that that pain's less bad than using spaces everywhere and having the IDE deal with it.
Until the people making editors and auto formatters acknowledge that the obvious most sensible whitespace style is even a thing, I'm forced to do something else and be really grumpy about it.
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).
It's hard to do this consistently (especially in a team) because people might (and statistically in a large enough project, will) use the tab key for alignment since it's faster than pressing space, or just be confused about what whitespace is tabs and what is space. Just using space everywhere is idiot proof and requires no work to micromanage. The only way to use tabs is to not align at all.
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.
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.
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 can preserve alignment in a mixed context, but it complicates things.
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) :
As you can see, everything will stay correctly aligned as long as it's within the same block.
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
Yes, but keep reading. That strategy is a pain to maintain especially across editors.
Many styles are difficult to maintain, I'm not saying it is or isn't. I'm saying that using only spaces for alignment will not let your alignment get messed up with various tabstops settings.
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.
inevitably there are times you need to use spaces
When? You indent with tabs then add any spaces you want for precise alignment. When would you need to use spaces to indent?
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.
What did you mean by "inevitably there are times you need to use spaces", then?
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.
The consistent appearance thing is probably more about how mixing tabs (for indentation) and spaces (for alignment, eg in multi-line function definitions of calls) looks like complete crap if you change the tab width.
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)
How does that work, and with which editor settings? If you simply set the tab width (tabstop) in vim, things go south.
Say you have a function definition one indent level in, then 22 characters of text. You more want to align the next line to that. How does that work in practice with tabs?
The obvious way with tabs and ts=4 would be 6 tabs and two spaces(one tab for the initial indent, the rest to match 22 characters). But then someone with ts=2 comes along and barely gets half way there, or someone with ts=8 who overshoots by a lot.
That's not how you should mix tabs and spaces for alignment. You use the same number of tabs as the previous line, and then fill the remaining width with spaces. That way, when you change tab width, the alignment spaces will always start in the same column as the line they're aligning to, regardless of the tab width.
Do most editors do that by default? If so, that's great -- if not, it's just a downside for tabs, if you need to hit enter, backspace out the automatic indents and then press space 30 times rather than just hit enter and have it aligned automatically.
vim seems to auto-insert tabs when you hit enter mid-function definition, at least with standard settings.
That seems like a problem with Vim, then... Typically I don't align at all, so I'm not familiar with editor behavior for alignment; I prefer to just indent one level deeper.
Setting tabstop and shiftwidth differently is basically legacy braindead behaviour. It is going back to the logic of tab is just a way to compress spaces. If you are doing that then you have all of the problems of both tabs and spaces.
As for alignment the easy answer is don't use tabs for alignment. Use tabs for indentation, if you want to align something use spaces for the alignment past the indentation. Lemmy seems to be breaking code snippets right now but I have a really old blog post about this.
The post is a little out of date when referencing the style of my blog but the C example shows alignment. If you can resize the browser you can see that the indention changes from 4 to 2 as the screen gets narrower without breaking the alignment.
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);
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.
Tabs for indentation/increased scope, spaces for alignment. The best answer.
Soft tabs are superior.
press tab-> get 4 spaces.
…did you not read the article?
In come my idiotic colleagues:
"buT w3 lIke 2 SpACe5!"
fuck with the linter
I use a product that has a homegrown scripting language that enforces two space tabs and will crash with anything else.
My main issue is that they keep changing format all the time and making merge requests unnecessarily difficult. Wanna use two? I hate it but fine. But let's agree on this and change our formatter all at once.
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.
If I could only get everyone who works on the thing I work on to use a whitespace visualizer, it would be enough. We can fight about tabs or spaces after we get rid of all the unnecessary trailing ones.
I'm glad someone linked this. Should be further up in this thread.
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.
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.
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!
Tabs take less space (space as in space in storage, like free as in freedom) tbh.
My disk is almost full! Better switch to tabs for indentation!
Happened to me quite a few times, relatable situation.
Seems there's not much else going on
laughs in lisp
Nah, I'll keep on sticking with spaces or whatever the language's formatter uses. Ain't no way am I mixing tabs and spaces, will just stick with spaces.
I used to be a tabs guy, somepoint over time, especially when I realized some of the edge cases I have in formatting only remain consistent when using spaces, I switched.
Looks like you missed the point. This is about indentation, not formatting.
Use tabs to indent your lines, but if you want to align a parameter with the parenthesis on the line above or something like that, you add spaces after the indentation tabs.
That way if someone wants to they can configure their tab length to 20 spaces and the indentation will remain consistent and the code will remain aligned.
My point was that it's pretty much impossible to indent with tabs in lisp. It'll be harder to read and scan for everyone else who has a different tab with. How you indent and what you want to indent to is very different compared to a c-style language.
why don't we store code unformatted and have everybody's IDE display it with their preferred format applied? it would make everything easier and stop people bickering over pointless things.
That's what tabs are for. 1 tab, to an ide, means "you choose how many spaces this tab is, and when we commit it back to git it won't fuck the history up."
I guess they were referring to formatting other than tabs, like place of brackets and line length, which sounds like a neat idea
...until you start using languages where whitespace is the only way to distinguish code blocks. (Most notably Python.)
It was harder to explain why picking on Python for this is dumb, before gotofail... (Not saying that's what you're doing, but it feels close, so this is relevant.)
For whitespace, my rule is this: If any level of indentation depends on the length of any word or name, you're doing it wrong. If using a more descriptive name causes indentation where previously there was none, that's fine, but if moving the opening parens causes the interior to be indented more, less so. (Yes, Golang's structs)
Storing an AST would be interesting, but it'd require the IDE to support parsing each specific language, so you'd probably want something like an LSP but for just parsing to handle that.
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?
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.
Well written code doesn't have an implicit tab size. You should be using a tab to mean "one indent" and if you need to align something an exact number of characters then use spaces.
This is the downside to tabs, they are easier to use correctly. With spaces if it looks right in your editor it probably looks half decent everywhere else. Tabs have a worse behaviour if they are misused, but if used well then every viewer can view and edit with their preferred indent size.
I wonder if it could be possible to adjust the “indent number of spaces you see” in code editors.
You could potentially do a good job with a full parser for the language in question to determine the indent level and separate indent from alignment. But I’d rather not rely on this when we have a perfectly simple and semantic character for indicating what is an indent and what is an alignment.
Maybe this could be a useful linter though. That way mistakes are caught but not every editor needs a perfect parser of every language.
The thing is - I have probably seen hundreds of projects that use tabs for indentation ... and I've never seen a single one without tab errors. And that ignoring e.g. the fact that tabs break diffs or who knows how many other things.
Using spaces doesn't automatically mean a lack of errors but it's clearly easy enough that it's commonly achieved. The most common argument against spaces seems to boil down to "my editor inserts hard tabs and I don't know how to configure it".
Yes. That's what tabs are for. You can choose the width of the tab. It can be small for people with small screens. It can be big for this guy or people with 600 inch ultrawides.
Tabs are objectively superior because they are exactly what everyone wants at all times, and the git commit history does not get polluted.
I thought it was a non-issue that tooling should take care of anyway until stackoverflow published this:
Honestly, my editor (Neovim) just picks between tabs and spaces for me, so I just end up using whatever's already there. The only language where I'll explicitly use one is Haskell, just because spaces there allow me to keep everything nice and lined up.
I'm tinkering with a whitespace language and prefer using 1-space rather than 2. I don't really like the double character for 1 level. Is that weird?
Tabs are forbidden though I could use tabs with a (1-line) per-file code filter for the compiler to turn 1 tab into 2 spaces, and that might be easier when working with others (though I don't know how it would be seen, especially needing to change editor tab behavior).
Tabs let you define how big you want each indent to be, and spaces do not.
Spaces can too: Simply use more or less of them, to taste.
I have ADHD. Two spaces per indent makes it damn near impossible for me to scan code.
Then use four, or six, or eight, or 20. Hell, most code I've seen uses four spaces per indent anyway.
[Re: braille]
Surely there's an editor out there that will automatically display indent spaces as a tab character. Or failing that it seems like it would be rather trivial create a program to convert n spaces to tabs, and vice versa.
Spaces do not allow the viewer of code to choose how wide the indents are, this is dictated by the developer.
Most IDEs allow users to customise how many spaces to display tab indents as. Doing so the other way around may cause issues with languages based on whitespaces such as python.
You are missing the point. Lots of code has multiple authors. There is offer no space indention that works for all authors. With tabs each author or reader can use the width that works for them.
automatically display indent spaces as a tab character
You can't really do this reliably. The problem is that spaces may be used in other places for alignment where the width shouldn't be dynamic. If you do a simple s/ /\t/g you will have funny results where code was aligned carefully using spaces. (The reverse does work though if you want to go from tabs to spaces, because tabs contain more information.)
You could potentially do a good job with a full parser for the language in question to determine the indent level and separate indent from alignment. But I'd rather not rely on this for no reason. Sometimes I don't have a full parser available for every language I want to edit.
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.
Honestly, what fucking editor are you using that doesn't allow you to configure tab length? Wordpad?
I’m hopping between shells using whatever is installed.
Vim has it, even Nano has it. It's one setting away, set it once and forget it. If you use throwaway containers it would be hassle but I don't understand why you would need to view code inside the container in that case.
…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 ?
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?
Try it and you'll see
It's not just “might”. Termux is pretty much the only good choice for programming on Android.
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.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)
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.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!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.Github uses 8 as a default. It's configurable though.
Microsoft Windows' Notepad. I have sometimes used that when on a public computer.
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.
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"
https://nickgravgaard.com/elastic-tabstops/
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?
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.
There’s a difference between doing something that’s “easier” and what’s right.
Whether there is more legacy code with spaces or tabs is irrelevant. Most of the code that will be written hasn’t been written yet.
I disagree with you on “micromanagement” of spaces vs. tabs, that is nonsense. Set up a formatter for commits and set your IDE to display how you want.
The pragmatic view on one or the other is that for a one group of people, using tabs appears to be significantly better, and for everyone else, it barely matters at all, except as personal preference.
That being said, I’m not vision impaired, so I don’t know what the preference would be.
The reason we’re even talking about it is that someone that has studied it from an accessibility perspective has asserted that tabs would be preferred.
The way I see it, there are two competing strategies for improving the experience for braille screen users: making tabs more widely used and improving braille oriented editors. Without knowing for sure, my guess is that improving editors is a better strategy and this is in part because it is easier.
As a matter of principle it might be "more right" for people without visual disabilities to adjust themselves to people with visual disabilities than vice versa, but I also think that it's important to care about what is actually likely to improve braille screen users experience and not default to the more principled goal without any consideration for how realistic it is.
(Of course, I might be overestimating how easy it is to get better braille oriented editors, but since you referred to this as the "easy" solution it doesn't sound like you're disputing this specifically.)
A braille display traditionally is a personal, almost handfitted (estimated by price) device controlled by its screen reader software. Not the editor. This has some unfortunate implications:
So yes, you might be overestimating how easy that is, compared to telling some diva asswipe chucklefuck to use that formatter or work at McDolans.
Thank you for the insight, didn't expect it to be that dire. Tabs and spaces nonwithstanding, hope that the screen reader/braille display tooling situation improves in the future, sounds like it is sorely needed.
I sure hope so, but I'm not overly optimistic tbh. The market is basically considered medical, therapeutic devices. It is as you imagine, probably worse. It isn't easy to find prices directly, but the only way this range of vendors continues to exist in this niche market is to sell devices with the complexity of a keyboard for four to five digits. There is no competition worth talking about happening.
So unless very specific regulation takes place, I don't see standardized access to braille displays happening.
Let’s agree that we aren’t going to affect this change in this comment thread, so which one is more “pragmatic” is beside the point.
What does matter is whether we decide to have an inclusive view on this issue, and are willing to make extremely minor modifications to our settings and workflows to be more accommodating for others.
I am encountering more and more cases where people behave in inexplicably selfish ways, and this just feels like another one. It’s low/no-cost to do, yet could yield benefits to others. Low cost/risk, high potential reward.
Starting with “we’re not going to even consider raising awareness and let the market decide” is just a very cynical way to approach the world, and I’d argue is even actively harmful to the people that hold that view.
Do you think it matters if getting a large number of people to switch to tabs is an achievable project at all? Maybe I am a bit cynical but this seems to me like something that is actually very difficult to do.
When faced with a problem like this I think it makes more sense to approach it from a perspective of what would be a practical way to actually address it and refusing to do that does I think in its own way betray a different kind of cynicism.
For the record what I'm saying isn't that I wouldn't switch to tabs for the sake of people with various disabilities, I'm saying that spaces are slightly better than tabs if you don't have any relevant disabilities so if there is a way to have the cake and eat it to that would be a nice bonus, but that's honestly besides the point.
You are treating this as a binary/zero-sum game. Will we get to 100% use of tabs (or spaces)? No. Will we get a "perfect" viewer made and then adopted by all visually-impaired people? No. Making people aware that a fairly mundane choice has a negative impact on others might change their behavior, or at least challenge it.
Change like this is incremental, so just having the conversation, and asking you to consider that making a small change to your config might help some people down stream is something. Asking you to bring this point to the next conversation about tabs vs. spaces, is helpful.
This is my fundamental issue with your original statements, and this thread: It's a subjective choice that you think is slightly better than removing a barrier/major annoyance for an entire group of people that may want or need to interact with your code. It's closing the door on possibility for a minor personal preference.
I think that there might be a fundamental missunderstanding here: I'm not saying that we shouldn't use tabs to accomodate people with disabilities, I'm saying that better editor features seems like a better "solution" to the problem.
In the abscence of editor improvements I agree that it makes sense to use tabs to accomodate disabilities, I just don't think that it will catch on that mutch. I don't think that spaces (imo) being slightly better is a good reason to not accomodate dissabilities by using tabs right now, but I do hope there is a more editor oriented solution some day because I think it would propably be better both for people with visual disabilities and without.
Being in a slightly argumentative mood might have led me down towards validating this false dicotomy between editors and tabs, and I apologize for wasting both our time because of this.
You do have a point that I personally might have more influence over if a given project has spaces or tabs than if better editor features are made, but I think that there can be a point to having the poor support for programming that is apparently offered by screen readers to take some place in the discussion as well since that is a potentially more important piece of the puzzle.
I can't imagine that there is much of a point to keep replying after this so I think I'll leave it here.
Yeah. It is depressing.
I’ve always wanted an accessibility feature that uses haptic feedback to mimic braille patterns for reading purposes too.
In general a lot of creative stuff can be done if we focused on it even a tiny bit more.
I wish every language had a gofmt, this is such a non-debate (tabs are indentation, spaces are alignment)
rustfmt
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.
The absence of settings in gofmt is a feature. The kind of basic formatting it handles is not worth having opinions about.
Yet, I do. So, I like to enforce it.
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.
Code formatter and run auto format
Holy wars are fun, but this is the answer.
At least this way the holy war takes place in commits to change the formatting file.
Unless go, in which case the holy war is now everyone who hates go format rewriting the code in a different language.
Tabs for indent, spaces for alignment. This is the way, I can't believe people are still fighting that ?
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.
Not like that, lol
Just saying, instead of this monstrosity
Just use
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.People seem to have a real issue with using new lines and I've never quite understod why.
It feels like a lot of those people are using notepad like applications instead of coding focused ones with collapsible regions etc.
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:
I normally avoid that too, I find it hurts readability more than helps, plus a proper IDE will separate it with color anyway.
But yeah, the newline comment doesn't apply to this.
To each their own indeed. But my rule of thumb is: only use tabs when there's no other character before it (aka, start of line).
The emacs wiki agrees and has the correct take on this: https://www.emacswiki.org/emacs/SmartTabs
It seems like this basic guideline, tabs to indent and spaces to align, solves the problem for everyone. It doesn’t matter what your tab width is, it’ll look “right” regardless.
This kind of "manual" alignment should be avoided for many reasons including the fact that adding/removing/changing of one parameter here may force you to modify multiple lines which on it's own is annoying but this will also show up in the diff during review making it harder to grep what was actually changed.
I personally favor code readability over patch readability. But I reckon this is a matter of preference so I can understand how you might not like that.
Yeah I agree I don’t find alignment very useful. It’s more work for dubious benefit, and god forbid you change one of the lines.
The way god indented.
I almost scrolled past this one
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.
I used to think this way, at least when writing C++. But it's objectively harder to do and convince other people to follow, especially if they can't be bothered to change their environment to display tabs and spaces differently. It's a losing battle so now I just do spaces when working with other people
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.
Why on earth would I care how someone else has their editor configured? It's none of my business, and none of yours either.
Because other people are fucking morons and their editor doesn't have visible whitespace enabled - or it does but they don't give a shit.
Therefore these fucking morons have anywhere between 2 and 8 spaces-per-tab configured and will happily mash the tab key however many times is convenient for them to align their code or comments because they don't understand shit about fuck when it comes to alignement (or they don't care). Now I open their file and everything is predictably misaligned. Spaces and tabs are mixed from one line to the next, and in particularly egregious cases no tab width I can locally set on the file will make it readable because multiple different morons used different tab widths to align with tabs - sometimes within the same goddamn function or comment.
Have you ever tried to read an important technical diagram in ASCII art aligned with tabs by different people with different IDE settings? Because I have. Emphasis on tried.
This is a solved problem: Enforce linting before committing using something like Git Hooks / Husky.
No, because we live in the present and use proper tools for diagrams. SVG diagrams tend to be common nowadays. I'm aware you can't read them raw, but realistically the intersection between people who need to read important technical diagrams and people who don't have access to a web browser is vanishingly small (dare I say nonexistent?)
Tell me you develop with modern languages without telling me you develop with modern languages.
Try linting perl, or bash.
Like yeah if you work on a modern JS/Python/C# project, whatever, whitespace is going to be autoformatted, so the tabs vs spaces debate does not matter AT ALL.
You say this like it's a bad thing?
If you're already writing Perl/Bash scripts then it would probably not take you long to write a git hook to check the beginning of each line of source to check if there's a space or a tab character and preventing the commit if the wrong one is found. Crude and far from perfect, but still better than nothing.
It does though. If you read the original article then you'd know that the advantage of tabs is that everyone can choose exactly how deep their tabstops are, which is an objective benefit over spaces.
It's not wrong to work with modern languages, but don't pretend that you have the answer to the debate if you don't work in a field where it applies.
Linting bash/perl is a TERRIBLE idea. Consider the following, extremely common piece of code (perl has equivalent syntax as well):
(lol lemmy bug found, can't write the actual "left angled bracket - left angled bracket" syntax, it somehow truncates the comment)
OTOH if you use a modern auto-formattable language, then you can auto-format to tabs with a git hook or IDE plugin (and back for committing) if you want, so the debate doesn't matter in that case. It goes both ways.
I've yet to find tooling that supports this. Clang format has a setting that looks like it does it, but actually does something else. If I have to press the spacebar a bunch of times each time I add an argument to a function, that's a pain, and it's a bigger pain to convince the people I'm working with that that pain's less bad than using spaces everywhere and having the IDE deal with it.
Until the people making editors and auto formatters acknowledge that the obvious most sensible whitespace style is even a thing, I'm forced to do something else and be really grumpy about it.
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).
It's hard to do this consistently (especially in a team) because people might (and statistically in a large enough project, will) use the tab key for alignment since it's faster than pressing space, or just be confused about what whitespace is tabs and what is space. Just using space everywhere is idiot proof and requires no work to micromanage. The only way to use tabs is to not align at all.
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.
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.
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 can preserve alignment in a mixed context, but it complicates things.
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) :As you can see, everything will stay correctly aligned as long as it's within the same block.
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.
Yes, but keep reading. That strategy is a pain to maintain especially across editors.
Many styles are difficult to maintain, I'm not saying it is or isn't. I'm saying that using only spaces for alignment will not let your alignment get messed up with various tabstops settings.
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.
When? You indent with tabs then add any spaces you want for precise alignment. When would you need to use spaces to indent?
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.
What did you mean by "inevitably there are times you need to use spaces", then?
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.
The consistent appearance thing is probably more about how mixing tabs (for indentation) and spaces (for alignment, eg in multi-line function definitions of calls) looks like complete crap if you change the tab width.
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)
How does that work, and with which editor settings? If you simply set the tab width (tabstop) in vim, things go south.
Say you have a function definition one indent level in, then 22 characters of text. You more want to align the next line to that. How does that work in practice with tabs?
The obvious way with tabs and ts=4 would be 6 tabs and two spaces(one tab for the initial indent, the rest to match 22 characters). But then someone with ts=2 comes along and barely gets half way there, or someone with ts=8 who overshoots by a lot.
That's not how you should mix tabs and spaces for alignment. You use the same number of tabs as the previous line, and then fill the remaining width with spaces. That way, when you change tab width, the alignment spaces will always start in the same column as the line they're aligning to, regardless of the tab width.
Do most editors do that by default? If so, that's great -- if not, it's just a downside for tabs, if you need to hit enter, backspace out the automatic indents and then press space 30 times rather than just hit enter and have it aligned automatically.
vim seems to auto-insert tabs when you hit enter mid-function definition, at least with standard settings.
That seems like a problem with Vim, then... Typically I don't align at all, so I'm not familiar with editor behavior for alignment; I prefer to just indent one level deeper.
Setting
tabstopandshiftwidthdifferently is basically legacy braindead behaviour. It is going back to the logic of tab is just a way to compress spaces. If you are doing that then you have all of the problems of both tabs and spaces.As for alignment the easy answer is don't use tabs for alignment. Use tabs for indentation, if you want to align something use spaces for the alignment past the indentation. Lemmy seems to be breaking code snippets right now but I have a really old blog post about this.
https://kevincox.ca/2014/06/26/responsive-tabs/
The post is a little out of date when referencing the style of my blog but the C example shows alignment. If you can resize the browser you can see that the indention changes from 4 to 2 as the screen gets narrower without breaking the alignment.
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.
Observe what adjusting the tabs does,
This uses only spaces for alignment,
When converted the alignment is maintained because the tabstops aren't used for alignment, only for indentation.
And I stopped reading there.
Tabs for indentation/increased scope, spaces for alignment. The best answer.
Soft tabs are superior. press tab-> get 4 spaces.
…did you not read the article?
In come my idiotic colleagues:
"buT w3 lIke 2 SpACe5!"
fuck with the linter
I use a product that has a homegrown scripting language that enforces two space tabs and will crash with anything else.
My main issue is that they keep changing format all the time and making merge requests unnecessarily difficult. Wanna use two? I hate it but fine. But let's agree on this and change our formatter all at once.
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.
If I could only get everyone who works on the thing I work on to use a whitespace visualizer, it would be enough. We can fight about tabs or spaces after we get rid of all the unnecessary trailing ones.
You've a .editorconfig in your repo right? Right?
In case folks aren't aware, https://editorconfig.org/
I'm glad someone linked this. Should be further up in this thread.
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.
This is a holy war that I will gladly fight again and again! I can't believe that soft tabs are more popular, especially in python!
That is because they are superior.
spatium vult.
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.
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!
Tabs take less space (space as in space in storage, like free as in freedom) tbh.
My disk is almost full! Better switch to tabs for indentation!
Happened to me quite a few times, relatable situation.
Seems there's not much else going on
laughs in lisp
Nah, I'll keep on sticking with spaces or whatever the language's formatter uses. Ain't no way am I mixing tabs and spaces, will just stick with spaces.
I used to be a tabs guy, somepoint over time, especially when I realized some of the edge cases I have in formatting only remain consistent when using spaces, I switched.
Looks like you missed the point. This is about indentation, not formatting.
Use tabs to indent your lines, but if you want to align a parameter with the parenthesis on the line above or something like that, you add spaces after the indentation tabs.
That way if someone wants to they can configure their tab length to 20 spaces and the indentation will remain consistent and the code will remain aligned.
My point was that it's pretty much impossible to indent with tabs in lisp. It'll be harder to read and scan for everyone else who has a different tab with. How you indent and what you want to indent to is very different compared to a c-style language.
why don't we store code unformatted and have everybody's IDE display it with their preferred format applied? it would make everything easier and stop people bickering over pointless things.
That's what tabs are for. 1 tab, to an ide, means "you choose how many spaces this tab is, and when we commit it back to git it won't fuck the history up."
I guess they were referring to formatting other than tabs, like place of brackets and line length, which sounds like a neat idea
...until you start using languages where whitespace is the only way to distinguish code blocks. (Most notably Python.)
It was harder to explain why picking on Python for this is dumb, before gotofail... (Not saying that's what you're doing, but it feels close, so this is relevant.)
For whitespace, my rule is this: If any level of indentation depends on the length of any word or name, you're doing it wrong. If using a more descriptive name causes indentation where previously there was none, that's fine, but if moving the opening parens causes the interior to be indented more, less so. (Yes, Golang's structs)
Storing an AST would be interesting, but it'd require the IDE to support parsing each specific language, so you'd probably want something like an LSP but for just parsing to handle that.
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 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?
Well written code doesn't have an implicit tab size. You should be using a tab to mean "one indent" and if you need to align something an exact number of characters then use spaces.
This is the downside to tabs, they are easier to use correctly. With spaces if it looks right in your editor it probably looks half decent everywhere else. Tabs have a worse behaviour if they are misused, but if used well then every viewer can view and edit with their preferred indent size.
You could potentially do a good job with a full parser for the language in question to determine the indent level and separate indent from alignment. But I’d rather not rely on this when we have a perfectly simple and semantic character for indicating what is an indent and what is an alignment.
Maybe this could be a useful linter though. That way mistakes are caught but not every editor needs a perfect parser of every language.
The thing is - I have probably seen hundreds of projects that use tabs for indentation ... and I've never seen a single one without tab errors. And that ignoring e.g. the fact that tabs break diffs or who knows how many other things.
Using spaces doesn't automatically mean a lack of errors but it's clearly easy enough that it's commonly achieved. The most common argument against spaces seems to boil down to "my editor inserts hard tabs and I don't know how to configure it".
Yes. That's what tabs are for. You can choose the width of the tab. It can be small for people with small screens. It can be big for this guy or people with 600 inch ultrawides.
Tabs are objectively superior because they are exactly what everyone wants at all times, and the git commit history does not get polluted.
I thought it was a non-issue that tooling should take care of anyway until stackoverflow published this:
https://stackoverflow.blog/2017/06/15/developers-use-spaces-make-money-use-tabs/
Spaces all the way
Make sure to specify you only use spaces before asking for the raise! It works!
Ah yes I understand now!
Original poster is right by all accounts, of course. Now, let's come up with exotic significant indentations.
Pro: Your editor no longer needs to implement indentation hints.
Con: Looks obstructive if not highlighted like an indentation hint.
Your turn.
https://nickgravgaard.com/elastic-tabstops/
Right, that is another item I wished more editors would have picked up. Besides - say - nested language modes.
Wrong.
https://archive.org/details/the-butter-battle-book
Honestly, my editor (Neovim) just picks between tabs and spaces for me, so I just end up using whatever's already there. The only language where I'll explicitly use one is Haskell, just because spaces there allow me to keep everything nice and lined up.
I'm tinkering with a whitespace language and prefer using 1-space rather than 2. I don't really like the double character for 1 level. Is that weird?
Tabs are forbidden though I could use tabs with a (1-line) per-file code filter for the compiler to turn 1 tab into 2 spaces, and that might be easier when working with others (though I don't know how it would be seen, especially needing to change editor tab behavior).
Spaces can too: Simply use more or less of them, to taste.
Then use four, or six, or eight, or 20. Hell, most code I've seen uses four spaces per indent anyway.
Surely there's an editor out there that will automatically display indent spaces as a tab character. Or failing that it seems like it would be rather trivial create a program to convert n spaces to tabs, and vice versa.
Spaces do not allow the viewer of code to choose how wide the indents are, this is dictated by the developer.
Most IDEs allow users to customise how many spaces to display tab indents as. Doing so the other way around may cause issues with languages based on whitespaces such as python.
You are missing the point. Lots of code has multiple authors. There is offer no space indention that works for all authors. With tabs each author or reader can use the width that works for them.
You can't really do this reliably. The problem is that spaces may be used in other places for alignment where the width shouldn't be dynamic. If you do a simple
s/ /\t/gyou will have funny results where code was aligned carefully using spaces. (The reverse does work though if you want to go from tabs to spaces, because tabs contain more information.)You could potentially do a good job with a full parser for the language in question to determine the indent level and separate indent from alignment. But I'd rather not rely on this for no reason. Sometimes I don't have a full parser available for every language I want to edit.
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.
Honestly, what fucking editor are you using that doesn't allow you to configure tab length? Wordpad?
I’m hopping between shells using whatever is installed.
Vim has it, even Nano has it. It's one setting away, set it once and forget it. If you use throwaway containers it would be hassle but I don't understand why you would need to view code inside the container in that case.
https://editorconfig.org/ 😜