Tabs vs. Spaces. Take 100500

Holivar about “Tabs vs. Spaces” is as old as the world, however, as it seemed to me, no one put a final point on this issue.



According to Github statistics, spaces are the most popular. Moreover, there is even statistics according to which allegedly programmers using spaces earn more.



I’ll make a reservation right away - until recently, I myself was an ardent supporter of gaps. However, everything has changed with learning the Go language. Very clever guys wrote it and I have a rather high credit for them. Therefore, any solution that did not fit into my worldview, at first I carefully examined and tried to understand before shouting that this was all wrong. The same thing happened with tabs.



To begin with, I recall once again the main arguments of each side of this ancient dispute. More precisely, the arguments to which these disputes most often boiled down in my practice:



Spaces:

• Everyone is equally visible, i.e. formatting is the same for everyone regardless of the IDE settings and other things

Especially suitable for block leveling, as then changing the length of the tab will not knock her

var i uint64 = 10 var name uint64 = 20
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Tabs:

• Everyone can adjust the indentation for themselves without interfering with others in the project. In this case, the code will be the same for all
• Smaller files

Both sides only equally understand that it is IMPOSSIBLE to interfere with both styles in one project. Though we converge here.



If suddenly someone does not know - in Go the creators of the language saw a whole package of convenient utilities for developing “out of the box”. Here you have a compiler, a tester, a documentation generator, and much, much more. But the most interesting is the gofmt utility, which provides code formatting. And thanks to this part of the Go package, the formatting of the code is the same for everyone, and holivars are inappropriate here. Actually, that was the idea of ​​the creators - to kill holivars in the bud. But even more interesting is the choice of the character to align. In Go, this is a tab.



At first, it was very embarrassing for me, because I had long been an adherent of spaces and did not expect that the people who created C, Unix, and Go could make such a decision. But as I have already said, the credit of trust in them is large, and this is precisely what helped me to step over confirmation bias , to which I, like many, are exposed to holistic issues. The problem is that when you have already taken a side, especially in the holivar, then you listen to the arguments of the second side but don’t hear. Well, you don’t turn on your head.



So, when you turn on your head, the decision turns out to be so simple and obvious that it’s even hard to understand how it had never occurred to you before. And the whole problem is in the same rule: “it is impossible to interfere”. So it is so, only when they say this they mean indentation, not alignment. In English, there are two different words for this, but in our country most often this and that is called “alignment” (although indention is “indentation”, it is often called “alignment”).



Here's what Go does. For indention - tabs and only tabs are used. Example:

 func main() { var i = 1 }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

But for alignment - spaces:

 var i uint64 = 10 var name uint64 = 20
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

No matter how I thought, I could not come up with a single significant minus in this approach. But the pluses are saved from both sides:

• Block alignment is still retained by everyone regardless of the IDE settings
• Everyone makes his own indentation as he likes, without disturbing others
• Smaller Sources

For me personally, this once and for all is closed by this one of the oldest holivars of the IT world.



However, maybe I don’t notice something?



UPD: I really didn’t notice (or rather forgot) a couple of points, for which I always preferred spaces. In the comments, they safely pointed out to me:

1. In this approach, you cannot make a beautiful alignment of the wrapping of long lines

For example, in a SQL query:

 SELECT CASE WHEN val < 0 THEN 'Negative' WHEN val > 0 THEN 'Positive' ELSE 'NULL or zero' END AS field_sign, ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Or, in transferring arguments to a function call in a long line:

  if (object.drawRect(rectangle.x, rectangle.y, rectangle.width, rectangle.height)) { }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2. Displaying the code in places where we do not control the size of the tabstop (Github, git diff, email, diff, slack, habr, etc.)

In such cases, the size of the tabstop will depend on the settings of a particular environment, and often there will be 8 characters, breaking the beauty of the display



PS I confess, I was naive in deciding that Go put an end to the holivar with an extremely simple and extremely obvious (and often used) solution. That's why they are holivars ...