3

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.

qodeninja
  • 532
  • 6
  • 11
  • 1
    Why not agree on using the same code editor with the same formatting settings? Is this not the obvious solution? – Bernard Dec 15 '11 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 Dec 15 '11 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 Dec 15 '11 at 21:30
  • @Coder: Understood, but then it will be hard to always get the same output using different editors. – Bernard Dec 15 '11 at 21:45
  • Why is this causing problems with SVN/Diff? Doesn't it have an option to ignore white space? – Chance Dec 16 '11 at 00:14
  • Unfortunately for you, UltraEdit is one of the few arguments able to bring peace between emacs and vi. – mouviciel Dec 16 '11 at 08:44
  • @Chance - Ignoring white-space in your diff tool doesn't help when you are committing changes to revision control, especially if you end up with commits that only consist of changes in white-space. `svn` diffs don't ignore white-space and `hg` or `git` hashes will still change when only white-space changes. Ultimately, editors should not change the formatting of the existing white-space and your editor should be set up to use the same tab conventions as everyone else editing these files. – Mark Booth Dec 16 '11 at 13:27
  • @MarkBooth, I agree. It doesn't tackle the main problem. I know some diff tools, like kdiff3, allows you to choose the white space from 1 file among 2 or 3. – Chance Dec 16 '11 at 15:47
  • In the long run, we need to STOP SAVING CODE TO TEXT FILES. It's a very highly-structured thing, source code; writing it as text is just silly. [Some people get it](http://www.jetbrains.com/mps/), although unfortunately they failed to make the display settings configurable per-user, which would have solved the "newline before brace?" issue once and for all... – Roman Starkov Dec 16 '11 at 16:10
  • 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). – Martin York Dec 16 '11 at 16:23
  • @romkyns I dont understand what you mean when you say 'stop saving code to text files', arent all non-binary files just text files, ultimately? – qodeninja Dec 19 '11 at 04:59
  • Seems to me like the line ends are not the problem, its more likely to be something like embedded tabs. Once upon a time, when disk drives of 90K were large, converting multiple spaces to tabs was important. Now it is not. Make sure you don't have any embedded tabs IN BOTH EDITORS. Life will suddenly get a lot less painful. In SVN check your end of line settings and make sure they are sane (usually this means "NATIVE" but if using a mix of windows and unix, things will get much more interesting). – quickly_now Dec 19 '11 at 11:40

6 Answers6

13

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

David Brown
  • 276
  • 1
  • 9
  • 1
    everyone seems to agree that having a standard is the way to go. – qodeninja Dec 19 '11 at 05:00
  • Yeah, if your editor is good enough to code it will have all the configurable settings you need. – Carra Dec 19 '11 at 08: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... – Dimitrios Mistriotis Dec 19 '11 at 11:16
  • The link to the C style guide is broken – Ferrybig Jun 23 '17 at 20:25
4

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.

Timo Geusch
  • 2,773
  • 21
  • 15
2

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.

KeithS
  • 21,994
  • 6
  • 52
  • 79
  • 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 Dec 16 '11 at 00:15
2

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)

mattnz
  • 21,315
  • 5
  • 54
  • 83
  • 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 Dec 16 '11 at 03:17
  • This is a good example where using the [boyscout rule](http://programmer.97things.oreilly.com/wiki/index.php/The_Boy_Scout_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 Dec 16 '11 at 13:33
1

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.

Coder
  • 6,958
  • 5
  • 37
  • 49
  • 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. – Spencer Rathbun Dec 15 '11 at 21:37
  • 3
    I think you mean `replace tabs with spaces` – Daenyth Dec 15 '11 at 21:59
  • @Daenyth: That's a religious debate and not worth getting into. – Martin York Dec 15 '11 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 a few times more. Tabs on the other hand ... – Rook Dec 16 '11 at 02:09
  • @LokiAstari - I agree that space vs tabs is a religious debate. But when it comes to consistency among various editors and various editor configurations, space is the winner. – mouviciel Dec 16 '11 at 08:47
  • 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. – Martin York Dec 16 '11 at 14:42
1

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.

Chance
  • 511
  • 3
  • 8