We have some grumpy developers in the office, and like the perrenial bikeshed, everyone wants to have their say.
Some languages do try to mandate one style over the other (python), others are just free form.
I'm having a hard time getting consensus here, and people are doing spurious edits on the codebase.
Is there some sort of technical solution I can do to force people to commit in one style ?
Is there a project manager or team lead? This would be a perfect decision for them to make.
I recommend forcing everyone to tabs since they can always be adjusted to any number of spaces in the programmers' text editors of choice.
I don't know, but while you are doing this, you might like to look into resolving these issues as well:
Perl vs. Python
K&R style vs. Allman
GNU/Linux vs. Linux
Sunny side up vs. Sunny side down
(In case you didn't get it, I think the whole question is pointless. You should spend your time on productive pursuits rather than trying to bondage and discipline your programming team into agreeing on the minutia of coding detail).
The only real solution is to, in the language spec, ban all unneeded whitespace (tabs, spaces, newlines, etc) this will make the situation so bad that everyone will be forced to use a live, on-the-fly-reformatter. Then everyone is "happy"
(that's tongue-in-check :)
Is there some sort of technical solution I can do to force people to commit in one style ?
It depends on what language you use etc, but there are things such as CheckStyle that will do that for you.
Make a code beautifier part of the build process, and run a diff between their code and the beautifier.
If they don't match, then mark their module as "Does not compile" and don't include it in the next build and/or email them or however you currently notify coders of bad code.
This will enforce your style requirements.
By default, tabs in our IDE (for C++) get expanded to 4 spaces.
Other than that, some of us also use Haskell, and since it is whitespace sensitive, tabs vs whitespace is a pain. The official policy is never to use tabs (however, this is not yet enforced by scripts or anything).
Doing maintenance on Haskell code that uses tabs is a nightmare: you copy and paste, not knowing that you selection includes tabs, and then the code ceases to compile with not-so-easy to get error messages...
Choose one, write it down in some official coding standards document, and get on with your life, messing with whitespace is not productive work.
And if someone just doesn't agree to work with the selected style just remind him (or her) that he is programming as a profession not as an hobby (and if someone has so much problems with whitespace what will happen if he has to work with a technology he doesn't like? see http://www.ericsink.com/entries/No_Great_Hackers.html )
Since you asked about a technical solution, you could set up your source control system to prevent commits that didn't follow a particular style.
I set something similar up using Checkstyle (for Java) and CVS.
If it's not compliant, it doesn't get committed.
Of course, you really should have a consensus of opinion first or it could get nasty. :-)
Check out Jamie Zawinski's “Tabs versus Spaces: An Eternal Holy War”. Bottom line: there's no reason to put tab characters in your files. Any decent editor can be configured to make them go away. Agree on a standard indentation increment across your team and stick to it.
The issue really comes down to establishing code standards and enforcing them. The question of tabs vs. spaces is one of those "holy war" type debates where everyone things their side is right.
Tabs have the benefit of allowing people the flexibility to establish their own tab size, which allows them to view the code "thier own way" while spaces ensure that everyone sees the code the same way. If this is actually a concern the only real approach is to establish the standard and try to enforce it, which best comes from a mangement level.
I wouldn't enforce this through check-in scripts that actually change the source content on check-in as you will end up in situations where what actually gets checked in isn't what you thought it was and doesn't necessarily match what you have locally on disk. Using check-in scripts to prevent a check-in if the code doesn't use tabs or spaces would probably be OK. Keep in mind that not all source control systems provide these hooks, so this may not be a viable option.
We use 3 spaces which was a compromise between 4 and 2 spaces. At least the company's code is kind of unique. ;)
Just let the IDE format code to your personal tastes is what i say.
I'm a bit surprised by the support for tabs.
It was mandated on our projects not to use tabs, largely because it caused problems between editors. Instead we all used the standard of four spaces. I would do the same again.