Hot discussions on Tabs vs. Spaces in Coding

For the past two days, the current topic is Tabs vs. Spaces in coding and how it might affect the development and ultimately, your hiring capability. Today we'll be covering on the following three aspects:

Pros & Cons of Tabs vs. Spaces vs. a Mix of both!
How does this affect your hiring employers?

So where did this all begin at the first place?

On defaultly-configured Unix systems, and on ancient dumb terminals and teletypes, the tradition has been for the TAB character to mean move to the right until the current column is a multiple of 8. This is also the default in the two most popular Unix editors, Emacs and vi.

There was an episode in "Silicon Valley" last year, as they built an entire episode around one of the most obscure fights in programming, which indenting technique people use - Tabs or Spaces or a mix of both. This has been a big debate in almost all the workplaces and in most of the interviews, you'll be asked about this question, at least once - Which coding style do you use? Tabs or Spaces.

Obviously, answering the question is a little tricky, because, based on what you answer, there will be a decision taken by the employer or your hiring manager, if he's a technical person or being "fed" with technical stuffs to be asked during the interview (which would make things worse, as the person will come with a preoccupied mind that he needs to hire only one type of candidate, not letting the interviewee to justify their point of view).

Talking about code, most (yes, some people do exist) people set their Integrated Development Environment (IDE) or Text Editor to use a mono-space font. And regarding my justification for the most, yes, I have seen people who use Times font for working with source code and make their as well as the developers (who help them) life in a burning hell. Coming back to the Tabs and Spaces, let's start the debate.

Pros & Cons

Spaces

Any space, let it be in any editor or environment, will take one single column. It is the developer that decides how the code should appear with the level of indentation, if the space approach is used. Let it be vim, Git Commits, Sublime Text, the code looks always the same.

But there's a downside for spaces. Since they use single column to represent only one column, things might go bad if they need to represent a full indented SLOC, where multiple spaces take up to show one single indentation.

If the developers are concerned about how the code should be indented, then spaces are the best approach to go.

Tabs

On the other hand, a Tab may be either 4 Spaces, 8 Spaces or 2 spaces. This is set by the configuration of the editor and it is not universal, although most of the editors and browsers use 4 spaces to display a tab character (8 spaces in source code of browsers). And this is changing rapidly with time. The good thing about Tabs are that they are not spaces and they are mainly used for indentation.

Having said the above, I could find only good things about using Tabs. The main reason I would find Tabs are best is that they use only a single character to represent the indentation and unlike Spaces, they save about 75% of indentation content. So, considering a source code of say, 10 lines with 3 levels of indentation would have at least 20 tabs, this would mean that either you have 20 bytes occupied by tabs or 80 bytes occupied by spaces:

HTML  
  Head
    Title
    StyleSheets
    Scripts
  Body
    Header
      Logo
      Navigation
        Links

Even with Tabs, it is easy to configure vim, Git Commits, and almost all the IDEs and Text Editor to set up the right spacing for every tab character. Summarising, I would say that it is better to use Tabs instead of Spaces because of the following:

De facto standard for indentation.
Less bytes usage.
Configurable to any number of spaces.
Better control over the indentation.
Scalable across the environments.
Allows mistakes to be noticed easily.
Doesn't have inconsistencies (you might accidentally add 3 spaces instead of 4).
Easier on keyboard (one key stroke vs. four key strokes).

Other advantages include:

Code is stored in a compact form.
Gets formatted as per the dev's preference.
Upon saving, goes back to the compact form.
Easily resizable and can be realigned according to needs.

Hey, wait. Before finishing this section, I would like to highlight the main problem faced by Tab indentation. Well, they are not particularly compatible with the source codes that span multiple lines and they are connected. Say, for example, we have variables declaration like:

var a = 10, b = 20,  
    c = "Add", d = false;

You need to use spaces in the above case to make sure it displays correctly as the Tab indentation might screw up the above structure. Well, I would argue that the above coding style is ugly and inefficient. Instead, what I would do is something similar to:

var  
  a = 10, b = 20,
  c = "Add", d = false;

And in the case of functions:

function add (int a,    // first param  
              int b) {  // second param
  return a + b;
}

Can be replaced with:

function add (  
  int a,  // first param
  int b   // second param
) {
  return a + b;
}

The above coding style not only looks good but also it is an efficient way to organise code, instead of using a huge number of spaces and wasting the code space. Using code compressors are a different story altogether, but this is pain!

Career Impact of Tabs vs. Spaces

Stack Overflow, the number one resource for developers for literally anything had recently published an article Developers Who Use Spaces Make More Money Than Those Who Use Tabs. It is really interesting to know that employers have started looking into the coding approach used by developers and made it a concern too. That's actually good for some, as it might be a seed for beginners to learn the right way.

Salaries...