Tabs vs spaces — a never-ending story…
Every developer, during its own lifetime, has to deal with a deeply grounded doubt; before choosing the best language or the preferred editor, (sh|h)e has to join a side… a dark or a bright one.
This tricky decision has divided entire teams, struggled bunches of brogrammers, broken couples of beloved coders, set up wrong configurations in dozens of IDEs…
It’s the unfortunate choice between SPACE and TAB to indent and align the source code; a timeless debate which, for someone, it’s a concrete war between factions!
A bit of story
The word tab derives from the word tabulate, which means “to arrange data in a tabular, or table, form.”
When a person wanted to type a table (of numbers or text) on a typewriter, there was a lot of time-consuming and repetitive use of the space bar and backspace key.
To simplify this, a horizontal bar was placed in the mechanism called the tabulator rack. Pressing the tab key would advance the carriage to the next tabulator stop. The original tabulator stops were adjustable clips that could be moved from place to place on the tabulator rack. Fredric Hillard filed a patent application for such a mechanism in 1900. — Wikipedia
Nowadays, the tab key might be often used to move the selection of UI elements avoiding to use the mouse or, yet, to auto-complete a suggested word.
So why are we using tabs while coding!?
Well… it did not totally come out of the blue. As everything, there are PROs for such a choice.
- TABs characters occupy fewer bytes
- TAB width can be easily configurable on almost all (serious) editors avoiding to physically update every single file
- TABs are easier to match (since matching spaces may select unwanted ones)
- TABs are easier to manipulate because there’s no “translation” nor interpretation
On the other side, SPACE has been always there and also in this case we have PROs for using it…
- With SPACE file is consistent across editors
- There is no messing with custom indentations due to the fact that SPACE is a single unit, which will be more precise by definition
FUN FACTS ABOUT THE NEVERENDING LAST-MAN-STANDING FILIBUSTER ARGUMENTS ABOUT CODE FORMATTING
The plots above describe an emerging phenomenon where it seems that the ones who use SPACEs tend to have a higher salary.
Want to go deep into this mystery?
Here it is the full article: https://stackoverflow.blog/2017/06/15/developers-use-spaces-make-money-use-tabs/
Code formatting anarchy is fine if you are alone on a project; it becomes an high-prio if you do work in a team and, remember, it is proportional to the number of peeps you work with.
Having a well-shaped code, with recognizable visual patterns, might boost your ability to look speedily through it.
Do format, don’t do war. When in a team, try to gently trace out and agree on common best-practices about formatting. It’s important to share IDEs configurations or to use linters during development.
Let it be a common and informed decision, not a dull coercion.
If self-management does not work, let’s think about setting up a formal role in charge of doing code revision and cleanup.
BUT… be careful; you don’t want this colleague to get the blame for mistakes made by others. If you really need such a figure in your team, pair-programming and brainstorming sessions might be better than having “nightly code reviews”.
Code is poetry, every software has its own metric and flow;
it’s fine to be creative, elegant and parsimonious but most importantly is being consistent.