After 20+ years of listening to the tabs-vs-spaces debate and considering all the legitimate points that both sides have, many have made the following observation and it's what resonates with me the most:
In an ideal perfect world, _all_ of programmers and _all_ text editor tools would use tabs specifically for indentation and spaces specifically for alignment. But, we don't live in that perfectly coordinated world so spaces maintains the most fidelity -- at the expense of programmers not being able to instantly customize the indentation from widths of 2,4,6,8.
Therefore, the slight edge goes to spaces even though I find tabs extremely attractive. (That conclusion is in the context of a team of multiple programmers, using multiple languages, multiple text editors. If you're solo and can maintain "tabs discipline", that's a different scenario.)
While I see what you're getting at, I actually prefer indentation in this case as well. Something like:
var some_call_result = some_object.a_method(
with,
quite_long,
list_of,
parameters
)
Alignment adds inconsistent negative space to the code which I find breaks the flow and makes it hard to read because lines start at arbitrary columns. If your method name grows or shrinks, the alignment in your example needs to be fixed whereas with simple indentation there's no such need.
What you presented indeed has no alignment spaces, so all-tabs approach works.
The thing is, there are codebases that use "my" line breaking, and with no
editor that handles that case correctly, tabs are just no-go.
> If your method name grows or shrinks, the alignment in your example needs to be fixed whereas with simple indentation there's no such need.
I gladly accept this drawback, for the sake of situations when a linebreak is
necessary, but the argument list is just too short to be split it into
separate lines like in your example. (The necessity is a matter of taste,
obviously.)
I admit, these situations are rare, but they happen from time to time, so
I simply don't use tabs.
That's what code formatting tools (cncrustify, clang-format, etc) were built to fix - let the computer have perfect and consistent formatting, you just need to record your intention.
I came to this conclusion too after at least 20 years of using tabs; but mostly it was because of moving to white-space significant languages like Haskell, F#, etc. It was just too painful getting everything lined up with tabs and I needed the fidelity of spaces.
Previous to that with C/C++/C# the alignment usually took care of itself through the closing brace and IDE auto-formatting. So tabs was the natural unit of currency there.
Fact? My team is using Atom, VS code, IntelliJ and vim-go for Go. There has never been a problem with tabs vs spaces. On save gofmt converts all spaces to tabs and when I open Go files in vim-go it converts them to spaces according to my settings. Same for all other editors, whether you like tabs or 7-space indent.
Python doesn't care either way as long as indentation is consistent (though there's a common misunderstanding that Python cares). However PEP-8 specifies that code should be indented using 4 spaces and editors should be configured to render tabs as 8 spaces (likely to make mixed tabs & spaces really obvious). But PEP-8 also specifies that code should follow whatever is the coding standard in a given project.
IOW, Python is actually far more pragmatic than most people (including most Python programmers) think. It just has a culture that strongly advocates following the rules (i.e. PEP-8 and PEP-20).
Python treats a tab character as the amount of spaces needed to go into the nearest multiple of 8 column. With py2 ability to mix different indentation as far as it amounts to the same column, you can format your code in pretty interesting ways.
Well, python most certainly do care in the case when tabs and spaces are used inconsistently. In python2 you could even redefine tab width inline like https://gist.github.com/yxhuvud/2006599 .
I also like a rule that states that you either put all the parameters on one line, or each one on its own separate line, but never something in between.
I don't think blindly following any convention is good. Sometimes it makes sense to group a few parameters, take this toy example for instance:
void drawrect(
Surface *surf,
int x, int y,
int width, int height,
uint32_t color);
Grouping relevant arguments just makes it a bit more legible. It's even more useful when calling the said function (assuming function with a lot of parameters, say XCreateWindow).
While I quite like that style, now you have to convince people to never align, before you can convince them to use tabs.
I've not seen any large public code-bases uses this style, so it's hard to know how well it works in practice. Do you know of any major projects with a 'no alignment' requirement?
The number of readers of any document will normally be greater than the number of authors. We should give a slight preference for readability and ease of comprehension over writeability, and should certainly not require that our readers adjust their editor settings for each document that they peruse.
In addition, it is useful to use vertical alignment to group related content that spans multiple lines. Although this at least partly an aesthetic choice, and not without drawbacks, I believe that the benefits outweigh the costs.
I believe that it looks neater, improves readability and also makes some errors "pop" out in a way that they don't in unaligned content. I find the ability to visually group related terms and expressions particularly useful.
The downside is that you have to "tidy up" after using refactoring tools or after doing a search-and-replace operation.
However, I believe that this downside is mitigated due to the fact that the very tidying up that is required is a good way of eyeballing the changes and checking to make sure that they are OK.
That stuff's ridiculous. Styleguides are meant to make the code more readable and maintainable - this is neither. Method calls can be defined just like arrays, where the first argument goes on a newline with a single added indent. No need to align anything.
- Finally, alignment breaks with proportional fonts. This is something someone else brought up on HN in another topic and I think it's a really good point; proportional fonts, like tabs, are an accessibility feature.
I've been learning Go in my spare time. One of the things that I've found really refreshing is how the enforced conventions largely eliminate contentious discussions like tabs vs spaces.
For those unfamiliar with Go, the gofmt tool[1] converts indentation to tabs, standardizes brace positioning, etc. Most editors have a plugin that will automatically run the tool on save. An option for programmers using other languages is EditorConfig[2].
Some IDEs will convert tabs to spaces when saving and the other way around when editing, so, while your approach is interesting, not really a proof of a majority choice.
Also my beef is specially with people who don't use tabs in files like fstab, like beasts.
For standard levels of indentation, I get that tabs may be useful, but in /etc/fstab, I absolutely hate them – how many do you put if the individual elements vary in size? Always just one, resulting in e.g.
I've never really understood why you would use several characters (=spaces) for something that is semantically one indent. Can someone enlighten me? What are the advantages of spaces over tabs?
Not all editors are smart about tabs and spaces, and when the two start to mix things get really funky if everyone doesn't have the same "1 tab = x spaces" value set on their editor.
Say that this is supposed to be at one indent level. The beginning of both of those lines should contain only one tab, and the spacing that positions the second argument from the indent should be only spaces:
If the text looked like above (each 'S' is a space), then one's editor could easily change whether or not a <tab> was displayed as 8 spaces or as 4 spaces, and the display wouldn't be affected. Many editors, however, consider all spacing at the start of the line to be indentation. If you were using one of those editors with tabs set to (e.g.) 4 spaces, the code might look something like this:
Now the code only looks the way it was meant to look if you have you <tab> = X spaces value set to 4. If you set it to something else, the code looks like a mess.
Right, not now you're dictating coding style to work around the warts associated with using tabs. If you use spaces there are no such issues because spaces don't change widths between editors.
The kind of formatting you suggest - aligning with spaces to get beautiful indenting - is a royal pain in the ass to edit. You change the function name to something a few characters shorter and now you have to change all the lines. It's prettier than the alternative, though (I still don't use it).
I wish the pioneers of programming languages would have had the foresight to provide an automatic formatting tool and standardize on a canonical layout. So much time and effort would have been saved.
Further, I think code guideline documents and discussions without an accompanying config file for astyle or clang-format are pretty useless.
Some languages do have more-or-less canonical formatting styles. The Lisp family comes to mind, as do ML and Haskell. You see far fewer arguments about formatting there, partly because there's very widely-accepted style, and partly because nobody cares to argue about the few things that don't have established canon.
Editor is one thing and most fully featured editors probably have an indent mode like this. Then there's all the other tools, like diff/merge tools, automatic refactoring scripts, etc which don't work as well.
I'm not a fan of Python's significant whitespace or PEP-8 in the first place. It puts too much emphasis on aesthetics at the cost of practicality. Writing a parser or any tooling for that is just a pain in the ass. I do use Python occasionally but for very different reasons than aesthetics.
I disagree. I moved form Perl to Python and disliked the whitespace to begin with. It does solve a couple of problems - it forces inexperienced coders to indent properly (I had one colleague who didn't when she used Perl). It also solves the missing brace problem when moving blocks of code around, which for me makes it worthwhile. It does make moving blocks around and commenting sections out a bit more effort, but way less effort than trying to work out where the brace has gone.
Things that are supposed to be lined up stay lined up even if they aren't at the start of a line - even if you:
* Use different tools - IDE, command line, version control tool, code review tool, e-mail client.
* Have code that follows with different conventions - because you participate in several projects, or because you've imported third party code that follows a different convention, or because the code is written in different languages.
* Have co-workers with different opinions about what tab width should be set to.
Personally I don't think there's that much value in vertically aligning things, except in lookup tables. Usually it's a sign you've adopted line-length rules that don't reflect modern monitor sizes, or that your methods have too many parameters. But some people seem to think it's valuable.
People always talk about consistent display of spaces whereas tabs might be shown as 4 spaces or even 8. Of course that means you can usually customize how tabs are rendered unless you code in Notepad or something crazy.
On vim (I am sure as hell you can do this on Emacs) you can always define your tabs to be spaces and you can specify exactly how much. So this is really not a big problem.
The big advantage, as other people discuss, that that different editors display tabs as 2,4 or 8 spaces, and I've never worked on a codebase which used tabs, and where viewing the code in different tab sizes didn't break the layout somehow.
If you use spaces, you can format code, knowing it will look right on other people's machines. Perhaps a sufficiently organised bunch of programmers could edit a large code base such that it viewed fine with 2,4 or 8 character tabs, but is it worth the pain?
Semantically, the TAB character means something like "insert a pseudo-random number of spaces here" with that number often defaulting to some ridiculous value like 8.
I keep my programs less than 80 character wide for accessibility purposes but if I use tabs then the width is unpredictable.
Also, spaces are universal and trivial whereas the TAB button in many editors has strange behavior.
It's not that hard. Alignment is generally harmful - it's a maintenance burden which adds whitespace noise on diffs, which means more noise in code reviews. Not to mention how atrociously ugly it is when long variables/method names lead to 5+ lines with 60+ characters of indent for a single variable name per line.
Most diff programs have an "ignore whitespace" option. "whitespace noise on diffs" is pretty much a solved problem. You can even add '?w=1' to a Github URL to turn on the feature.
1. That's a band-aid. The characters have still been changed - the diff still "exists".
2. Those options are not perfect, they don't always work as expected
3. Those options are not turned on by default (because that would be INSANE)
4. Git's not the only VCS, much as I wish it were
5. Github's not the only Git web UI; that option is not available everywhere.
It's not a "solved problem". It's an artificial problem, that gets solved when you start consistently stripping trailing whitespaces on save and not realigning everything all the time.
> It's an artificial problem, that gets solved when you start consistently stripping trailing whitespaces on save and not realigning everything all the time.
This is mostly solved via coding standards. If there are no coding standards people will "refactor" the coding style when they touch various pieces of code. If people were following a consistent style, then the alignment wouldn't be changing all of the time.
Although I strongly agree with the trailing whitespace sentiment. The most egregious offender that I've found is Eclipse putting trailing spaces on blank lines to bring them to the indent level of the non-blank lines. Ugh.
Now if you're writing like this, what happens when you introduce "EXCEPTIONAL = 4"? You change 3 other unrelated lines. This is something that alignment causes, regardless of "coding standards". Hell, gofmt does that... It looks pretty (to some extent - with long names and lots of members it gets unreadable), but creates so much noise.
The longer I've been programming, the more I think that alignment is ideally a presentational feature that a syntax-aware editor should do, not something that should be reflected in the source.
If you use the mouse then you want the cursor to appear exactly where you clicked. It's just a UX problem, similar with clicking past the last line of a file, even if it's nothing there, the editor should append new lines until the place that you clicked becomes part of the file.
I hereby declare end of discussion (at least for me), spaces because most other programmers use spaces. Unless you are joining the project that consistently uses tabs, then use tabs. Otherwise spaces.
Yeah, but since in this case it doesn't really matter it's better to just do what most people are doing. There are no serious advantages to either one.
I couldn't care less about this, and I generally feel out of place when other programmers ask me about my preferences on this topic. I have written code in different programming languages, and just naming Go and PHP where Tabs and Spaces are the standard respectively — PHP mostly because of PSR — I simply don't pay attention to the character(s) used for the indentation, the tooling already does that for me, being gofmt for Go and PHPCS for PHP, and there is probably the same tools in other languages [1]. I never understood why people complained about this more than other (more important?) things in the code like the position of braces which is also a flame war between developers but it makes more sense than caring about Tabs vs. Spaces.
[1] I say "probably" because even when I have written in Vala, C++, Ruby, Python, JavaScript, I have always relied on the IDE to automatically select the most common indentation in the project, so I never realize if I am using Tabs or Spaces since hitting the Tabulator key while using spaces will simply translate them to the correct indentation.
Completely unrelated. Noticed you use Vala. Just curious, how do you find it? Do you just use it for GNOME related things (GUI building) or for other cases as well?
Remember being interested in it a few years back. It seemed to be popular, but haven't followed it since.
Vala was my first introduction to OOP and since I was always working in a Unix environment C# was not an option for me. The bindings to develop GTK-based applications were good enough but still today I believe that using tools like Glade writing a GTK-based app in any other language is as easy as it is with Vala, the only advantage is that I can compile to C without having to write C all the time.
It has worked well for me, and was able to create corporate applications in the past. I don't use it with the same frequency now because of my current job, but it is still in my list of programming languages that I want to use for personal projects along with C++ and (recently) Go.
For people interested in the language I suggest them to take a look at Elementary OS documentation, they are one of the most popular projects using Vala in production and I am sure they will appreciate any contribution from beginners and experience developers: https://elementary.io/developer — https://github.com/trending/vala
Thanks. Didn't know about Elementary OS and was surprised there is a good number of Vala projects on GH.
Yeah there is something appealing about compiling to C. It is a relatively easier target than LLVM or assembly. Nim is in that space, is making progress but it still suffers from a small community of developers.
The biggest problem with the spaces vs tabs debate is that editor presentation is still tightly coupled to file persistence. Imagine an abstraction layer created so that developers might choose to see what they wished, yet have files saved in a standard format it might negate some of the issues people have.
Some perl projects carried by teams, use perltidy as pre-commit hook.
It's not as cool as talk about newer languages, but it handles all you may need about code indenting and alignment. And about tabs and about spaces.
Today somebody was asking in planet Debian, about Haskell vertical code alignment... well, again, perltidy has an option to enable/disable that.
I've developed many years without using it... recently I discovered it in first person, now I cannot live without it :) has options even for vertical alignment of indented comments.
I enjoy seeing it in action, after an hour or two of coding $anything. It finds always more inconsistencies than I did expect. And I really _try_ to be consistent.
Parsing files might not be the best way to measure programmer preferences, because in big projects programmer's preferences will be squelched by the coding standard and/or tab/space cargo culting.
I wish he'd have also counted the files that use only spaces or only tabs compared to a mixture of both in the indentation.
My reason for being against tabs is that unless you have something like gofmt, somebody will inevitably screw up and put in indentation that mixes tabs and spaces.
The second thing to check would be tabs that aren't in the initial indentation whitespace of the line. The other inevitable screw-up is using tabs to do some kind of vertical layout that shows up right with exactly one tab stop size.
Well, one correlation is that Google's coding style for C++ uses spaces and the .cc extension. It stands to reason that some fraction of Google alumni would continue to use both practices in their own work. I don't know if its enough to push a 36% tab usage to 7%, but might account for a solid fraction thereof.
I've worked for 10+ years in the games industry, ranging from 10 a man 'indie' studio to 400 people (large for the games sector) studios. I am struggling to think of any project I have worked on that hasn't used tabs (including a huge Python project). This maybe a completely irrelevant data point, but I wondered if there is a chance the games industry has a natural preference for tabs?
Am I the only one that finds DATA interesting here? Has anyone actually posted the terabyte over BitTorrent or something so I could play with it while avoiding the "Don’t analyze the main [bigquery-public-data:github_repos.contents] table — at 1.5 TB, it will instantly consume your monthly free terabyte."?
I have, I mentioned it in my comment above [1]. It's not too long, so I'll paste it again:
"I came to this conclusion too after at least 20 years of using tabs; but mostly it was because of moving to white-space significant languages like Haskell, F#, etc. It was just too painful getting everything lined up with tabs and I needed the fidelity of spaces.
Previous to that with C/C++/C# the alignment usually took care of itself through the closing brace and IDE auto-formatting. So tabs was the natural unit of currency there."
I have switched from tabs to spaces. I have always thought that tabs were the more straightforward representation- if we're in the spirit of separating presentation from semantics, we might as well use the character that means "indent this thing". But the majority of people think otherwise, and that's probably never going to change.
In unrelated news, I like the Dymaxion projection and think that tau makes more sense than pi, but every last one of my precious ships has sailed. tear
I just recently switched from tabs to spaces. I always used spaces for alignment and tabs for indentation. It was working very well within my company as all my colleagues were using 2sp tabs and I was on 4 space tabs. But now, we've decided to upgrade our codebase and make it PSR compliant (PHP).. which meant switching from tabs to spaces.
To be honest.. it's no biggie after a few weeks you get used to it.
Back in the very early 90s, I went through my company's codebase and replaced the mixed indentation with tabs. This was purely to save a space (small company, limited disk space). I probably preferred tabs at the time. Some time in the late 90s, though, I started to prefer the predictab ility and granularity of spaces.
They could just as easily have posted a study of who uses emacs vs. vim. Well, maybe not as easily, and we'd all sit here debating the pros and cons of either.
Tools like gofmt will, over time, make these discussions moot.
Or people who use a "mixed tabs and spaces" indentation, e.g. size 8 tabs with 4 characters wide indentation, and spaces for uneven indentations. (Which IMHO is broken because it leads to unreadable code when you don't have the same settings as the person who wrote the code).
Also, I guess C-style block comments could cause an over-counting of spaces (but looking at the numbers, it seems that either the query takes this into account, or C code simply has a poor comment-to-code ratio)
I'm curious, what's going on with C? I was surprised to see it as the only language other than Go (where tabs are enforced by gofmt) to dissent from the spaces majority.
Why no Objective-C? I'd bet it'd be either heavy on the space side or such a horrible mix of both that the analysis program would become self-aware and kill itself.
In an ideal perfect world, _all_ of programmers and _all_ text editor tools would use tabs specifically for indentation and spaces specifically for alignment. But, we don't live in that perfectly coordinated world so spaces maintains the most fidelity -- at the expense of programmers not being able to instantly customize the indentation from widths of 2,4,6,8.
Therefore, the slight edge goes to spaces even though I find tabs extremely attractive. (That conclusion is in the context of a team of multiple programmers, using multiple languages, multiple text editors. If you're solo and can maintain "tabs discipline", that's a different scenario.)