As the field of programming fluctuates between art and science, there are certain debates that have been raging on for generations. It's finally time to put these to bed.
To tab or not to tab, that is the question. And what a question it is - there has been reams of literature and debate on this very fine aspect of software engineering because it affects just about any endeavour that requires any form of code being manually written and stored. In fact, a good many projects never even saw the light of day because their co-founders were stuck in an endless recursive loop of submitting merge requests that reformatted all their code from tabs to spaces and vice-versa.
Let us dive into the debate headfirst and analyse each of the points presented from both sides:
Spacing
A space takes up 1 column whereas a tab can take up any number of columns depending upon the environment configuration. This means that spaces lead to a more consistent display of code. The counter argument to this is usually that tabs are better as they allow developers with different preferences in indentation size to change how it looks without needing to change the code itself.
Size
Using a single tab to specify 4 spaces of indentation is faster and results in a smaller file size. The counter argument to this is usually that modern day IDEs can just as easily convert all tabs to spaces on save and moreover, compiled or compressed code will already have all the fat trimmed out of it.
Well, that's about it. At the end of the day, the whole debate boils down to individual preferences regarding how one likes to read code. Given that reading code is what most software development is all about really, it is quite understandable that people get so heated up about it. Many even resort to writing blog posts 1, 2, 3 and eventually tv shows. It has even been recently surmised that developers using spaces make more money than those who use tabs.
As the data scientists themselves note, correlation is not causation and therefore no scientific conclusions can be drawn from the lack of the Tab character in source code. However despair not, dear Reader, for Software Dawg has the answer and you need not ask any more questions on Stackoverflow only to get downvoted into oblivion for having asked such an obvious duplicate.
Software Dawg's recommendation is very straightforward: since the pursuit of more money only leads to more problems, in the spirit of living frugally and earning less, the axe falls on the side of the tab 4.
Save on source code size, complete flexibility in terms of viewing and in the ideal case your code is well under the 80 character column limit. But then again, who really ssh's into production servers and fires up vim to modify the shopping cart backend so that it can accept more than one brand of toilet-paper? Those neckbeards...
This is not much of a debate when using real programming languages. Most languages require the use of a semi-colon to clearly distinguish between statements and some like Python rely exclusively on whitespace for parsing and tokenization.
Javascript thankfully never fell into this trap of requiring programmers to commit to writing consistent code. Unfortunately however, we programmers are quite a masochistic lot and therefore the need to argue about the usage of semi-colons or no semi-colons in Javascript is a no-brainer. Luckily for you, after years of wrangling with this dilemma software dawg has the answer:
The reasoning behind this is simple. The less characters you have in your source files, the less space they need. The reduced file size means lesser data sent over the pipe (which in Javascript's case is the majority form of delivery) and therefore a reduction in electricity costs which helps fighting global warming!
In fact, you should also probably only use global variables and closures to reduce the total amount of code you need to write. Also, forget about tests - rock star programmers add features directly in production using a web IDE.
This is a very interesting debate steeped in history. The initial programming languages fostered a snake_case standard which
survived well into the 21st century. However, the rise of scripting languages such as Javascript and people simply
too lazy to search for the
_ key, lead to meteoric rise in popularity of CamelCase.
In fact, there were even times where a mix of the two was employed:
@Test
void test_addUserWithoutNameThrowsException() {
...
}
Fortunately for of us, none of those developers are working on any mission critical software at the moment.
This debate is actually very easily settled because of the fact that there are no good screen readers that can reliably distinguish between cases. Therefore, in the name of accessiblity, snake_case wins this one hands down.
Well, well, well, this is a question that pops up every once in a while as people find themselves having to deal with linux servers and other real operating systems. "Which text editor should I invest time in learning? Emacs or Vim?" While this question has largely already been settled by the internet (hint: the answer is none, use pico if you must otherwise you shouldn't really be ssh'ing into anywhere really), we will include it here for completeness and also because we disagree with the opinion of a large majority of script kiddies.
There are 2 main differences between the two software programs:
So based on the differences, it is clear that one should invest time in learning Vim. It will come in handy if you ever need to edit files.
[1]
Guido van Rossum
[2]
Jamie Zawinski
[3]
Jeff Atwood
[4] Full disclosure, Software Dawg loves the $$$, so he always uses spaces.