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:
If it is not present, that button is added with the menu Window > Customize Perspective:
That button makes the tabs and spaces visible in the source view:
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:
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:
This offers a dialog where I can specify the Tab policy and the Intention size:
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:
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:
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 🙂
Helpful article, thanks.
LikeLike
Thanks, that’s encouraging. I recommend the AnyEdit Plugins, as they really help me to deal with spaces and tabs in my sources.
LikeLike
Reblogged this on Sutoprise Avenue, A SutoCom Source.
LikeLike
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.
LikeLike
Yes, that topic is classical one, and in my view not solved yet. I think it would be best if there would be a text/XML file in the workspace which can be checked out from a version control system, like the projects.
Apart oft hat: there is at least a way to influence the settings for every workspace, but this requires a file/modifiation inside the eclipse installation.
See https://mcuoneclipse.com/2012/04/06/eclipse-global-preferences/ for that idea.
LikeLike
Pingback: Top 10 Customization of Eclipse Settings | MCU on Eclipse
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.
LikeLike
> 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.
LikeLike