Tabs or spaces – Parsing a 1B files among 14 programming languages | Hacker News Reader

Tabs or spaces – Parsing a 1B files among 14 programming languages

medium.com

70 pointsnikbackm122 comments

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.)

My other personal feeling is that it's easy to auto-check we aren't using tabs (just search for tabs, and reject if any are found).

Depending on how you choose to format, it can be arbitrarily hard to check tabs are being used correctly.

For example, many people want to do some space indenting, such as:

    <tab>void my_function(int arg1, int arg2,
    <tab>                 int arg3)
    <tab><tab>{

It's (I believe) impossible for a language-agnostic tool to know this is "correctly tabbed", but (for example)

    <tab>void my_function(int arg1, int arg2,
    <tab>                 int arg3)
    <tab>    {

Is not.

I just always enable "Show whitespaces" in any editor I use. https://i.stack.imgur.com/BP2WJ.png

This let's me know if I left any trailing tabs/spaces before committing, align code better and while writing not while "refactoring".

git commit -am 'Whitespace formatting changes only'

No.

Don't align.

    void my_function(
        int arg1, int arg2, int arg3,
        ...
    ) {

I also much prefer this way of breaking long lines. Aligning parameters always looked ugly to me, specially with long function names.

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?

MediaWiki uses tabs for indentation and discourages alignment. https://www.mediawiki.org/wiki/Manual:Coding_conventions

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).

Unless you're using golang,in which case gofmt will correct you. Hence the overwhelming consensus of the go row for tabs.

Go's adoption rate would be quadrupled if they had chosen spaces instead of tabs. It's a fact.

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.

Pretty sure it was a joke...

Right. After reading so much Go hate I'm not sure who is serious anymore.

Poe's Law strikes again...

or python, or rust.

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 .

Using Python for 10+ years, never used tabs.

Honestly I don't care either way just a long as the file doesn't mix tabs with spaces.

I hate when the code looks perfectly aligned in my editor but is completely messed up in git because git renders tabs a different with.

I personally prefer spaces on my own projects because in the early days a tab used to be fixed at 8 spaces and I though that was a bit too much.

It's adjustable now but I don't think it was then or at least I wasn't aware it was.

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.

Horses for courses I guess.

Personally, I don't find the value in alignment - indentation is all I do. I especially dislike alignment of this sort:

    var a_variable           = 1;
    var another_variable     = 2;
    var yet_another_variable = 3;

which is just too fiddlesome and in fact makes it _harder_ for me to read.

That's also hazardous when you later add an_even_longer_variable and then have to modify three extra lines to make them align.

Exactly. To be fair, I believe most popular editors have plugins/shortcuts to do this. Or at least I hope people aren't doing this manually.

But if anyone looks at a diff, it looks like all the lines have changed, instead of just one, taking just a tiny bit more cognitive overhead.

`git diff -w`

But `git blame` still sees the whitespace change, right?

Edit: turns out `git blame -w` works as expected, ignoring whitespace. The More You Know™

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.

There's different kind of alignment, the one you get from breaking too long line.

  // some code
  // ...
  var some_call_result = some_object.a_method(with, quite_long, list_of,
                                              parameters)

In the second line you get indent (up to `var' keyword level), and then alignment. The former would be fine with tabs, but the latter must be spaces.

Unfortunately there's no editor that deals with tabs in this situation correctly, which means spaces is the only way to go.

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.

I've always used spaces instead of tabs.

My rationale:

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.

http://williamtpayne.blogspot.co.uk/2012/04/spaces-over-tabs...

Hey, a rationale, something I seldom see in those debates :)

I think that if you do want to align, spaces are unavoidable. But I want to reiterate three points against alignment:

- Alignment creates a maintenance burden. It has to be updated whenever you touch unrelated lines, which creates whitespace noise.

- Some types of alignments (specifically, method parameter alignment) create extreme horizontal noise. See for yourself: https://github.com/pennersr/django-allauth/blob/c9b31ddee81d...

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.

> - Some types of alignments (specifically, method parameter alignment) create extreme horizontal noise. See for yourself: https://github.com/pennersr/django-allauth/blob/c9b31ddee81d....

The answer there would be to put the line break before the . and align the .dispatch under super.

Neither!

http://nickgravgaard.com/elastic-tabstops/

“A better way to indent and align code”

When I saw this, it was obvious to me that this was the true solution to the problem which both space and tab proponents try to solve.

Wouldn't that imply using tabs but with the added feature that tabs also allow for alignment?

Yes, this seems like the best approach. The key for this to gain support is for Github's diff system to support it.

Essentially, this is suggesting to implement in text editors what word processors have done for almost forever, with some additional automation.

It's sad that this hasn't seen any traction in the past 10(!) years. It seems so much better than the current mess.

I love this concept--I'd be using it daily, but last time I tried it the Sublime Text implementation was unusably slow.

Admittedly, I am pretty picky on what's unusable. Also, this page lists it as an "incorrect implementation".

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].

[1] https://blog.golang.org/go-fmt-your-code

[2] http://editorconfig.org/

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.

I'd bet most of the code ever written gets styled however the IDE du jour decides to by default.

If some IDEs decided to switch to tab indent by default, people would suddenly love tabs.

I think this definitely applies to xcode, I use tabs everywhere but for xcode it just prints a lot of spaces and I am used to it.

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.

    this_is_a_long_line<tab>defaults<tab>…
    short<tab>defaults<tab>…

with the following elements not aligning? Or however many are necessary to get things to align, which sort of destroys the semantic meaning?

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?

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.

Lots of people need to access files on a server via Emacs or Vim. Having to deal with tabs there can be very frustrating.

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.

I'm not an Emacs guy but it's trivial to set the tab size on vim. I would be shocked if that were not also the case for emacs.

    def doSomething( parameter1
                   , parameter2
                   , parameter3
                   ):
        pass

How would you make all the punctuation line up using tabs?

Rather (assuming you’re dealing with Python),

    def do_something(parameter_1,
                     parameter_2,
                     parameter_3):
        pass

    def do_something(
        param1, param2,
        param3, param4
    ):
        ...

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.

    enum {
        NORMAL    = 1
        ABNORMAL  = 2
        IRREGULAR = 3
    }

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.

You don't, you use tabs for indentation and spaces for alignment.

Parent, you are the devil incarnate. Grandparent, you have bigger issues to resolve.

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.

But then tabs vs. spaces isn't an issue.

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.

For example:

      function_call(really_really_really_really_really_argument1,
                    really_really_really_really_really_argument2)

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:

  <tab>function_call(really_really_really_really_really_argument1,
  <tab>SSSSSSSSSSSSSSreally_really_really_really_really_argument2)

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:

  <tab>function_call(really_really_really_really_really_argument1,
  <tab><tab><tab><tab>SSreally_really_really_really_really_argument2)

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.

Your point is valid, that's why I write

    function(
        really_really_really_really_really_long_argument1,
        really_really_really_really_really_long_argument2,
        really_really_really_really_really_long_argument3);

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.

To be honest, no, because my formatting will not be broken after refactoring changing function name length.

What workflows do you have where renaming functions happens often enough that you need to optimize for it?

I do not really measure how often this happens, just rename as soon as name does not reflect exactly what function does.

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.

That particular form of formatting is part of Python's PEP-8, which has tooling around it. Maybe not all editors have something built it, though.

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.

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.

> Many editors, however, consider all spacing at the start of the line to be indentation.

What? If your editor can't tell the difference between you hitting the tab key versus the spacebar, it's a bug in your editor.

Smart tabs - the idea you're talking about - is well-supported in just about every major editor.

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?

With spaces you can position the cursor anywhere you want, with tabs you can not position the cursor in the middle of a tab.

Why would you want to do that? In fact, isn't it much more convenient to be able to jump over one tab with a single keystroke, rather than 2, 4 or 8?

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.

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.

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.

Both: https://www.emacswiki.org/emacs/SmartTabs

(Tabs for indenting, spaces for aligning)

To me, when people say "tabs", this is what I assume they mean. Using tabs for alignment is TERRIBLE.

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.

If greater than 58% of all projects you work on mostly use tabs, then use tabs 91% of the time, in 97% of your projects.

Now, can we look at the same repositories and look at the number of bugs and correlate it with the use of spaces?

But in all seriousness, how often something is used isn't an indication of how good it is. Spaces are like cigarettes. Just don't start.

If spaces are cigarettes, then tabs are crack.

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.

That sounds like a really complex solution to a kind of non-problem.

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.

Perltidy is truly amazing. I haven't seen anything that comes close in terms of power and configurability.

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.

Obligatory clip from Silicon Valley (Season 3): Tabs vs Spaces

(Some potential storyline spoilers if you haven't seen Silicon Valley) https://youtu.be/SsoOG6ZeyUI

Wrong link :)

https://youtu.be/SsoOG6ZeyUI

Oops, thanks for the correction! Have also updated my original post with the correct link :)

A vim user who prefers spaces to tabs but doesn't know about 'set expandtab'?

On every file I've edited for the past 15 years:

  // vim:set ts=8 sw=4 sts=4 tw=80 expandtab                                     :

For gods sake man, how many spaces?

I find it interesting that C++ using the .cc extension has about 7% tabs, whereas C++ using the .cpp extension has about 36% tabs.

I wonder what else is different about these two groups.

Probably IDE defaults (i.e. there might be an IDE that defaults to .cpp extension AND tabs).

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 would like to know If they are people who have 'switched'(coded with spaces and then use tabs or revers)?

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.

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."

https://news.ycombinator.com/item?id=12398432

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.

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 used to use tabs until I opened someone else's files that had a mix and were a mess of indentation.

This is such a flamebait topic.

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.

"One vote per file: Some files use a mix of spaces or tabs. We’ll count on which side depending on which method they use more."

This makes results completely useless, as files of people who really do not care will count for one side or another randomly.

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)

This is a remake on a bigger scale of: https://news.ycombinator.com/item?id=10795745

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.

Probably related to Linux kernel coding convention: https://www.kernel.org/doc/Documentation/CodingStyle

Quoted: Tabs are 8 characters, and thus indentations are also 8 characters.

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.

$ emacs <file>

C-x h <tab>

Whatever that does, with whatever type of source file, that's what I'm using.

As for my preference, well let me just say.. screw makefile! You've got it all wrong!!

So basically unless you're using C the argument is settled in favor of spaces?

Reply on news.ycombinator.com