I've used UltraEdit for years and never had a problem with sharing code with fellow developers whether they worked on Windows, Mac, Linux, Eclipse, Visual Studio -- what have you...

But now I am in an office where some developers are using emacs and they complain profusely about the white space differences my code "introduces". I have UltraEdit set to write to files as UNIX-style (no Windows returns), but it seems the whitespace renders differently for the emacs developers.

Since I don't use emacs (or vi), its a pain for me to try to figure out why this is impacting them, but I more so just want them to shuttup! lol

This is even causing problems in SVN/Diff!

Any thoughts on how to fix this?

Forget about everyone using Emacs because thats not gonna happen lol.

  • 1
    Why not agree on using the same code editor with the same formatting settings? Is this not the obvious solution?
    – Bernard
    Commented Dec 15, 2011 at 21:25
  • I've used a lot of different IDEs before settling on Ultra Edit -- which Ive used for YEARS ... in much the same way theyve probably used emacs for years. That's not gonna happen. Some people use Eclipse. I even use eclipse occasionally. If I need to edit on terminal I use nano.
    – qodeninja
    Commented Dec 15, 2011 at 21:28
  • 5
    @Bernard: Because someone might use vim and produce 50 lines per minute, while others will fight the editor all the time. Or someone is used to using autocomplete and using IDEs built in navigation tools and intellisense, while others remember function signatures by heart. None of these crowds are right, but each of them is at least 5x less productive with others tools.
    – Coder
    Commented Dec 15, 2011 at 21:30
  • @Coder: Understood, but then it will be hard to always get the same output using different editors.
    – Bernard
    Commented Dec 15, 2011 at 21:45
  • 3
    Just ask the emacs user the exact requirements for space/tab usage. Then set your editor appropriately. All modern editors are highly configurable it is just a matter of setting the options for your current project. (Then set up a project wiki page with the configuration for all editors being used on your project so the next person does not have to wade through all the settings again). Commented Dec 16, 2011 at 16:23

6 Answers 6


You fix this by creating a standard style guide for your organization's code. Everyone then configures their editors to match that style guide. For example you choose either tabs or spaces for your indentation and how wide indentations should be. This eliminates inconsistencies in and makes it so there is no arguing about code formatting, because the answer should be in the style guide. Ideally you would also have a tool that ensures code matches the style guidelines before it is checked in. For an example, see google's C++ Style Guide

  • 1
    everyone seems to agree that having a standard is the way to go.
    – qodeninja
    Commented Dec 19, 2011 at 5:00
  • Yeah, if your editor is good enough to code it will have all the configurable settings you need.
    – Carra
    Commented Dec 19, 2011 at 8:00
  • After you decide about style, you can in most editors (I have seen that in eclipse) export the settings to a file so that whenever someone new is joining the team, he can import from there. You might want to utilise some tools such as FXCop (VStudio) or PHP code sniffer, before commiting... Commented Dec 19, 2011 at 11:16
  • The link to the C style guide is broken
    – Ferrybig
    Commented Jun 23, 2017 at 20:25

At a guess - because I've been there a couple of times - I would check what settings you are using for tabs, tab width and indentation in UltraEdit.

Some editors tend to be clever and compress spaces into tabs either while editing or when saving a file. If you don't have the same settings for saving tabs/spaces and tab width as your fellow developers this can cause all sorts of funny behaviour, both when it comes to viewing the file in a different editor and in a diff tool. I've got some prime examples here in some code that was edited by someone who couldn't be bothered to turn off the space->tab conversion on save.


The tools available to you depend on the IDE you're using. VS and/or ReSharper in the .NET world can automatically enforce and convert whitespace differences or other "non-compliant" formatting, such as intercepting "tabs" and replacing them with 4 spaces, and converting existing tabs in the code. I'm sure UltraEdit has similar functionality if it is, as they claim, "the world's best hex/text editor". If it doesn't, there should be some plug-in that can normalize whitespace formatting.

And I really think Bernard's suggestion is the best solution; majority rule, choose a single development environment and standardize the set of tools.

  • I was going to give a -1 for suggesting everyone use same tool, but it does answer the question at hand, I just believe the other consequences are worse.
    – Chance
    Commented Dec 16, 2011 at 0:15

You probably have your IDE configured wrong for your work environment. Given you have no standards to work to, and anarchy reigns supreme (Implied by the existence of this question) you should configure your IDE to leave everything alone, except the lines you edit. I expect a tool such as Multiedit has this capability.

It is your responsibly not to change white space needlessly. I have learned (the hard way) this requires discipline and attention to detail, as well as an ability to leave things alone that are ugly, but not broken. It's not ideal, but without a guiding standard, all you will get into is pointless, destructive religious debate over whats right and wrong.

In the large (multi million line) code base I work on, as a rule changing code that does not need changing is wrong, and that is everything in the file - tabs, line ends, end of line spaces. The amount of merge conflicts that occur when pointless (white space, layout, comments etc) changes occur is an expensive waste of time and effort. You can, with decent tools, mitigate this to some degree, but never completely.

Ultimately, try to agree to a standard format, and also a migration part towards that standard for legacy code. Preferably use tools to support (if not enforce) the chosen standard. (We have not been able to agree to this, the money men would rather pay for the hidden costs of not doing it)

  • 2
    /Only/ configuring your editor to leave things alone results in a file with a bunch of different styles, which becomes a pain for everyone instead of one group. Agreeing upon a standard is the One True Path. :)
    – dannysauer
    Commented Dec 16, 2011 at 3:17
  • This is a good example where using the boyscout rule can make the code-base adhere to a defined standard over time. As long as you have a standard, and everyone makes sure that whenever code is touched it ends up adhering to the standard, then the whole code-base should eventually end up adhering to it.
    – Mark Booth
    Commented Dec 16, 2011 at 13:33

The best solution is to use code formatter on check in. Strip trailing blanks, replace spaces with tabs.

Ide's always wreak havoc. But not using one, IMHO, is couter-productive nowadays.

  • This should be part of your commit process. If someone uses a different tool, fine. Just make sure that the commit/script/build/formatter step can handle it. Commented Dec 15, 2011 at 21:37
  • 3
    I think you mean replace tabs with spaces
    – Daenyth
    Commented Dec 15, 2011 at 21:59
  • @Daenyth: That's a religious debate and not worth getting into. Commented Dec 15, 2011 at 22:15
  • 1
    @LokiAstari - Could be, but I believe that commiting spaces is more "safe". Spaces as such rarely cause any problems, you just <right><right><right> a few times more. Tabs on the other hand ...
    – Rook
    Commented Dec 16, 2011 at 2:09
  • 2
    @mouviciel: As with all religious debates about 40% agree with you. Another 40% think your idea is silly, and 20% don't care. And 100% of people think it is foolish to try and convince the other 40% of their foolishness because they will not be swayed by your arguments and have just as valid counter arguments. Pick a side ignore the other side and get on with your life. To think your side is better is human nature I suppose but short sighted nevertheless. Commented Dec 16, 2011 at 14:42

You may consider using emacs solely for the indentation and formatting after you have done all of your other changes. I've done this before myself, because I actually like how emacs indents. I would make all changes in my IDE (Qt Creator, Kate, or KDevelop), then I would open it up in emacs and select all and put in some command to auto-indent everything. I don't remember the commands, but if it is something you are willing to do, I'm sure your fellow emacs users would be glad to help you with the commands.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.