Should i use tabs

Below are just some of the errors you need to steer clear of during the app coding process. One of the biggest mistakes you need to avoid when developing a new program is reusing old code. While your client may request this to save time and money, you need to do all you can to talk them out of it.

Unless the code in question was specifically designed to be reused, you will end up basically rewriting it anyway. This is why starting with a fresh batch of coding is a must when trying to have success. As a programmer, your main goal should be providing your clients with the bug-free code they need.

The only way to ensure the code you have written is correct is by testing it at every phase of development. Getting in too big of a hurry will lead to big mistakes and may cause app crashes in the future.

While utilizing the power of space and indentation in your code will take some practice, it will be worth the effort. Finding a more experienced programmer to mentor you on this practice is a great idea that will help you progress at a rapid pace.

The Need For Indentation. Credits: ZombieMann, devRant. Other Best Practices to Follow When Writing Code While indentation is paramount when attempting to write readable and appealing code, there are a number of other best practices you should follow.

Documentation and Commenting With the technological advancements in the world of integrated development environments, commenting on the code is more useful than ever. Read also: 10 Essential Tips for Vetting a Software Development Agency Focus on Architecture First While meeting deadlines is one of the things you will have to focus on to become a great programmer, you need to avoid skipping vital steps.

Keep It Simple Writing code that is overly-complex can cause major problems when it comes to the functionality of a program. Please explain the answer you give. A tab could be a different number of columns depending on your environment, but a space is always one column. In terms of how many spaces or tabs constitutes indentation, it's more important to be consistent throughout your code than to use any specific tab stop value.

Now, of course, consistency matters more than either one, and a good IDE makes the differences negligible. That said, the point of this thread is to be a holy war, so:. Use tabs to indent the start of the line, one tab per indent level, and let everyone pick how wide they want that to be.

Use spaces if you're lining up characters within a line, so they always line up regardless of tab size. And find and punch all the early software authors who let this stupid thing become an issue in the first place. Seriously, why is this even something that's discussed? Next you'll be telling me you also want to use multiple characters for line breaks! Even for aligning parameters and comments, tabs still work better. Yes, with tabs you can decide your indentation level.

And yes, you can use a combination of tabs and spaces to align things. And in an ideal world it would. In reality, you can't see the difference between spaces and tabs, they always seem to get mixed up when moving code around, and viewing the code in another program that has tabs set to 8 columns is a nuisance. I used to use tabs. Then I started to work as part of a team and share code. I quickly became a proponent of spaces. So while I can sympathize with the utopia of tabs, I can't imagine not using spaces.

Mainly because I'm tired of navigating my code with a keyboard and having to constantly hit left left left left to go over one indentation. I had so many issues when people would only use 3 when I had used 4 everywhere else among other things. The other reason is that the tab character exist specifically for indentation , and was only later adopted for navigation.

Why are we doing space space space space when a simple tab would work? Why should IDE's have to deal with spaced code and format correctly when a simple tab and a preference option would work? I personally like to use tabs in everything, since each developer can control the amount of indentation per tab.

That way you get flexibility in display. That being said, I usually mimic whatever coding style is in the file to start with since I spend a lot of time doing maintenance work. Personally I like four spaces. They enable me to read code much faster and they look same in every editor - even Vi. Spaces, because when you align comments to the right of code, or function parameter lists, or complex multiline expressions, or things of that nature, you want your beautiful work to appear right for everyone.

If you use tabs and allow people to set their tabstops differently, they will break alignment for all but the simplest cases of code indenting. Besides, it's blatantly obvious that everyone in the world should be using vim, which makes it trivial to indent, unindent, and navigate through "tab stops" even in space-indented files. If you're sharing code with other developers, you need to standardize, and since that's impossible koff koff , you need to make everyone do four spaces.

Then you need an editor that's smart enough not to be stupid about that, to know that it should treat a line with four spaces at the front of it like it's indented. Any modern IDE or programmers' editor can auto-flow code with spaces instead of tabs.

Spaces or Tabs - What Atwood really says is pick one thing and be consistent in your project. The only holy grail of code formatting is to make certain that its consistent so that the psychopath who maintains your code after you doesn't feel compelled to remedy the situation permanently.

That said, if you're working in Python or any other language where whitespace is an actual programming construct I can't imagine using tabs. However I do everything else using Emacs and always use tabs because my tabs go exactly where I want them to go. The answer is that there can be no single proper indentation character for every situation. Formatting using characters is inflexible and can cause conflict when different styles are used within a team. The only method to format code flawlessly and flexibly with different formatting styles is to do it virtually, that is, without any indentation characters.

The only code editor I know that supports this though is the one used in the sample below:. Every character in the XSLT has been highlighted in yellow, for illustrative purposes, to allow the only tab or space characters in the content to be seen clearly.

The code indentation is handled by the editor's rendering system adjusting the left margin which has a white background. The only leading space characters precede the Books lines, because this is literal text content, not code, these space characters must be preserved.

With virtual formatting you choose the indentation width to suit the environment and indentation style without affecting any characters in the source file. You can even set the indentation width to 0, if you need a flattened view of the code as shown below:. To contrast this with space character formatting, the same XSLT opened in an editor without virtual formatting is transformed by that editor's auto-formatter to this:. The larger blank yellow blocks in the screenshot above clearly show the space characters added by the formatter of the conventional editor.

Unfortunately, these now can't be distinguished from real content so the XSLT would have to be modified to correct this issue. XSLT is possibly an extreme case, but this principle holds true for many programming languages: Characters should be used for content and an alternative method sought when it comes to formatting.

Not mentioned until now: There are languages Python, Haskell where indentation matters. But 1 character counts as 1 character, be it a space or a tab so the indentation seen by the compiler may not be the same one you see on the screen if you use tabs. Therefore, in languages like Haskell, spaces are a must. In all others, it's a matter of personal taste and nowadays not a great deal - every decent editor has a " leading tabs to spaces" and " leading spaces to tabs" command.

I used to use spaces, but I've been using tabs lately purely because that's what Eclipse was set to when I finally noticed. All of the other developers on my team use Eclipse, so it made sense to standardise on tabs when we realised we'd already been using them for ages and there was no reason to bother changing to spaces. I've been surprised by how much of a non-issue it has been. Setting the displayed tab size to 3 or 5 characters in your IDE greatly simplifies distinguishing between code sections that are indented by spaces almost always 4 these days and those that are indented by tab.

Plenty of arguments have been given already, but nobody mentioned where we could be headed in the future. Ideally code should be considered data, and not be stored in any specific text formatting.

Highlights from GitOpsCon Trajectory Day One Recap. Comcast Outage Analysis — Nov. Why automated testing is the fastest and safest path to digital transformation. Announcing 2nd Edition of Chaos Carnival. Welcome Wednesday: Michael Moser. Change Happens - Get Alerted. Xen Orchestra 5. Monokle 1. Portworx Enterprise 2. Join us at our new blog home. Suppose you are using a 4-space indentation, then the total size of the file added by your indent chars will be 4 times more than using tab indents.

Now, in a complex program indents can easily go up to 5 levels. Yes, obviously the real numbers for the industry would be different than this. And this comes at absolutely no cost. Yes, I have seen code examples like this in the wild. A better example using tabs would be -.

So these are my pro-Tabs reasons. The only pro-Space argument I see is the very first code example in this article. I hope this article will get programmers aware of why they should use tabs or spaces, whatever they feel like. This might not be the case with everyone. If this article triggered a change in your coding habit, do let me know in the comments. Also if you have a feedback about the article or would like to add to it, just throw in a comment.

I am always ready to have a discussion on this topic on Twitter. First posted on Avi's personal blog. They are valid points, but the time concern raised is irrelevant and super ugly, well, is just opinionated. Albeit a space guy myself, I think much more important battle is consistency, and not a file level consistency or a project level consistency, an organizational consistency.