Spaces vs. Tabs in Eclipse

I admit: I’m a ‘space’ person. What I mean is that I prefer ‘spaces’ over ‘tabs’ in my source code. Why? Because I don’t want to relay on the tab width, and I prefer to use ‘two spaces for an intention level’.

I would assume that maybe half of the world is for spaces, and half of the world is for tabs. I don’t want to cause a religious war here. I’m for freedom of choice, and this is what Eclipse and CodeWarrior for MCU (which is Eclipse based) offers. Now as I have outed myself as a ‘spacer’, and given the fact that CodeWarrior comes as ‘tabser’ by default, this is something I have to change as a setting for my workspace. Here is what I do….

Show White-Space Characters

A useful thing is to show tabs and spaces in the source view. For this I use this toolbar button:

Show White-Space Characters Toolbar Button

Show White-Space Characters Toolbar Button

If it is not present, that button is added with the menu Window > Customize Perspective:

Adding Toolbar Button

Adding Toolbar Button

That button makes the tabs and spaces visible in the source view:

Tab and Spaces in Source

Tab and Spaces in Source

Tabs for Spaces

Being a ‘spacer’, I want to use tabs to insert spaces. For this there is a preference under the menu Window > Preferences > General > Editors > Text Editors:

Text Editor Preferences

Text Editor Preferences

The next thing to do is to define my own Code Style. For this go the Preferences and go into C/C++ > Code Style and press Edit:

Editing the Code Style

Editing the Code Style

This offers a dialog where I can specify the Tab policy and the Intention size:

Tab Policy Settings

Tab Policy Settings

As noted in the bottom of above dialog: I have modified a built-in profile, and I’m not allowed to change it. So I specify my Coding Style Profile and Press OK:

My Own Coding Style Profile

My Own Coding Style Profile

Now the Editor is using spaces instead of tabs, with the given intention level (number of spaces for tabs).

This of course will only apply to new source changes. Existing tabs are not affected. But there is an easy way to convert tabs into spaces (with the right plugin).

AnyEdit Tools and Plugin

For any advanced manipulation of spaces and tabs, I recommend the AnyEdit Tools which offers really cool features. It offers a powerful automatic conversion of tabs and spaces:

AnyEdit Conversion Features

AnyEdit Conversion Features

Summary

If you are a ‘spacer’ or a ‘tabser’: it does not matter, Eclipse is a perfect choice for both worlds. And allows you to easily switch sources from one world to another. And don’t worry that you have to apply settings for every workspace: see Copy My Workspace Settings which helps to apply them to multiple workspaces.

Happy Spacing 🙂

8 thoughts on “Spaces vs. Tabs in Eclipse

  1. I have thought about this some more. I think that your suggested strategy is to generally use Workspace settings and to export / import these across workspaces.

    I want to share settings across a development team and would prefer not to rely on the team remembering to import when creating a new workspace.

    Therefore, I think it is best for us to use Project Specific Settings, which get stored in ‘.settings’ and can be stored in a version control system with the project files. Project Specific Settings include coding style.

    Like

  2. Pingback: Top 10 Customization of Eclipse Settings | MCU on Eclipse

  3. For a while I also recommended this setting to GNU ARM Eclipse users, but recently I ran into problems while editing some files, like Make files, which require the tabs to be there.

    Since I had no idea how to enter Tabs when the global setting was set to replace them with spaces, I had to revert to the original setting. However, I kept the formatter configured with spaces, so it doesn’t matter if I enter tabs or spaces, I always reformat my own sources and get rid of tabs.

    Like

  4. > it is best for us to use Project Specific Settings, which get stored in ‘.settings’ and can be stored in a version control system

    Generally speaking, .settings may be full of non-portable definitions, like local paths and such things, so storing them in VCS is not recommended.

    For some files it might not be dangerous, but for other files it might simply damage projects and break the builds.

    Like

What do you think?

This site uses Akismet to reduce spam. Learn how your comment data is processed.